Re[2]: "extract" command enhancement (subfiles and BIFs)

[pcunnane@xxxxxxxxxxxxxx]

     Scott,
     
     First, sorry for addressing the previous mail to you directly; I meant 
     to send it to the group.  *&^$"&^ cc:Mail!!
     
     Page-at-a-time in VB: doable, but not likely.  The alternative (which 
     I have used to great effect) is to have a search-results type of list, 
     based on a subsetting entry in a textbox.  This is very effective in 
     VB, because you can wait (say) half a second after the last character 
     the user types, and then build the results based on the textbox value.
     
     List data entry in VB: Grid.  Again, not all that much fun, but 
     doable.  Like I said, I'm not going to hold VB up as a shining example 
     of all that's good in programming, but it has some features that are 
     quite neat.  Subfiles are cool, I agree, but I strongly believe that 
     they fall a long way short of perfect.
     
     My ideal subfile would:
     
     - allow loading data on demand, with callbacks to load pages;
     
     - handle position-to by defining a key (it's a subFILE after all);
     
     - handle cursor and list positioning more intuitively;
     
     - ideally, handle option processing through callbacks.
     
     I guess I would rather the system subfile handling was more proactive. 
     I would like to be able to write a SFLCTL record, and have it call a 
     procedure to request the first page of records.  As the user pages up 
     and down, positions-to, selects records etc., the subfile calls 
     procedures as required, and only returns control to the program if no 
     options are selected, or a function key is pressed.
     
     You may say I'm a dreamer...
     
     ____________
     Paul Cunnane
     The Learning Company


______________________________ Reply Separator _________________________________
Subject: Re: "extract" command enhancement (subfiles and BIFs)
Author:  "Scott Klement" <infosys@klements.com> at InterNet
Date:    23-09-99 10:27 am


pcunnane@learningco.com wrote:
>      Have I written text-based programs for PC: yes.  DDS is 
>  definitely
>      easier, there is no question.  But AS/400 programming is more 
>  akin to
>      modern visual programming, because it uses form-based displays 
>  rather
>      than those built character-by-character. 
>
>      If you look at (say) Visual Basic,* I can code a list display b 
>      dropping a ListBox onto the form.  Adding items to the list is 
>  done
>      using lstCustomers.AddItem.  Positioning the list is equally 
>  simple:
>      lstCustomers.Item(n).EnsureVisible.  And so on.  Positioning th 
>      cursor to a text field:  txtUnitPrice.SetFocus.  To protect a
>  field:
>      txtUnitPrice.Enabled = False.
     
1) Try doing a "page-at-a-time" load of your listbox in Visual Basic,
     where you handle the scrolling of the listbox in your program. 
     If you have megabytes of data to display, loading it all at 
     once isn't practical.
2) Try making something akin to a subfile in visual basic that has
     both input and output fields on the same record...  Heck, try 
     doing input in general in a scrollable, subfile-like way in 
     visual basic.
     
I've done these things, and found myself wishing I was using DDS 
and subfiles.  "The grass is always greener on the other side" 
comes to mind.
     
>
>      Compared to character-based screen coding, display files are a 
>  huge
>      improvement.  But they still leave _way_ too much work to do. 
>
>      ____________
>      Paul Cunnane
>      The Learning Company
     
The weakness of DDS for screens is more in line of not being able 
to handle mouse events, and not being able to handle fields whose 
length is unknown at compile time...   In these ways, the custom 
controls that you use in VB (or VC or Java for that matter) are 
much easier.
     
IMHO, Subfiles really are well designed.
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---