|
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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.