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

Prepare yourself for flames (well--mild disagreement although not from me.)


I agree with you, it's really useful.  Particularly now that we have array
overlays, there are all kinds  of neat tricks you can do with searching and
sorting subfiles.  

The array technique also allows you to support what if scenarios without
having to go back to the file(s).  It is the "liberal" solution, throwing
hardware at the problem (in terms of memory use), but I like it.
> -----Original Message-----
> From: Chris Bipes [mailto:ChrisB@cross-check.com]
> Sent: Friday, September 24, 1999 9:25 AM
> To: 'RPG400-L@midrange.com'
> Subject: 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
> +---
> 
+---
| 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
+---