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

Well I have Keyed my SubFiles.  I have even used more than one Key.  It is
easy, but nothing to do with SubFiles.  As you load the subfile, save your
key in an array with the index the same as the RRN#.  Do your lookup on the
array to find the index and position your subfile to the RRN#.  One index
for every key.  The key does not even have to be in the subfile record.
What else do you not like about subfiles.  I may have a work around for you.

Christopher K. Bipes    mailto:ChrisB@Cross-Check.com
Sr. Programmer/Analyst  mailto:Chris_Bipes@Yahoo.com
CrossCheck, Inc.        http://www.cross-check.com
6119 State Farm Drive   Phone: 707 586-0551 x 1102
Rohnert Park CA  94928  Fax: 707 586-1884

*Note to Recruiters
I nor anyone that I know of is interested in any new and/or exciting
positions. Please do not contact me.


-----Original Message-----
From: pcunnane@learningco.com [mailto:pcunnane@learningco.com]
Sent: Friday, September 24, 1999 9:33 AM
To: RPG400-L@midrange.com
Subject: Re[2]: "extract" command enhancement (subfiles and BIFs)
     
     My ideal subfile would:
     
     - allow loading data on demand, with callbacks to load pages;
* I use subroutine for loading and even allow rolling beyond the top of the
subfile if available in the data files.
     
     - handle position-to by defining a key (it's a subFILE after all);
* see above for how to Key a subfile
     
     - handle cursor and list positioning more intuitively;
* use above logic to position the subfile cursor,(list) and check(PC) on the
field in the record you want to position the screen cursor.
     
     - ideally, handle option processing through callbacks.
* as you read the subfile, send the rrn# and option to a keyed data queue
(Key = Option + RRN#).  Then read the data queue in keyed seq., chain to the
subfile via rrn#, call appreciate procedure, pgm, subroutine based on
option.
    
     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 can code all this in modules but you will still be calling the modules
from your application.  I guess DDS cannot handle defining modules to load
your subfiles connected to your screen.  Maybe in the future but I am not
going to hold my breath, I will just dream with you.
     
     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
+---
+---
| 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
+---