|
Ah ha! right. That'd work, but I'd add two things to your request: First would be to add a NavBar to supplement the scroll bar. The Navigation Bar would be for large subfiles and would have "beginning of file", "go back a panel", "go back a record", "go forward a record", "go forward a page", and "end of file." Navigation Bars are a standard part in most GUI suites I believe. The second would be the idea that Martin McCallion put forward of a "position to" field that isn't a "position to" field. I didn't understand what it is exactly but it sounded like a wonderful solution. It sounded like the subfile repositions with each key stroke in the field. It also sounded like it needed event-driven logic. Whatever it is, it sounded like the piece that would finish out a complementary two-view solution for the sub-file issue. Please respond to MIDRANGE-L@midrange.com Sent by: owner-midrange-l@midrange.com To: MIDRANGE-L@midrange.com cc: Subject: Re: 4 - subfiles Booth, This kinda supplements my response yesterday on what I believe would be a good enhancement to the scroll bar function. Allow page-at-a-time (sflsiz = sflpag), and specify two other fields on the SFLEND(*SCRBAR) keyword. First, the number of records that _could_ be displayed from beginning to end (in my example above, 50000), this would control the size of the scroll box in the scroll shaft (IBM's terms). Second, the position (as it relates to the number of records from the beginning of the data) of the current subfile page being displayed, i.e. if "Johnson, Dr. William" is in the current subfile page and would logically be the 25,000th record in the "virtual" subfile of 50,000 records, the scroll box would appear smack dab in the middle of the scroll shaft. The operating system would use these two values to determine the size and placement of the scroll box. Here's how I see it being implemented in DDS (not column-correct): A #PRECS 15 0P TEXT('# of Potential RECordS in virtual sfl') A @POSIT 15 0P TEXT('Position of current page in virtual sfl') A 34 SFLEND(*SCRBAR #PRECS @POSIT) Determining the value of these two program-to-system fields would be the burden of the application, which _could_ require significant background processing if not designed properly. Boy, if I had that, I'd reconsider using the scroll bar as a standard. (Again, I'd still utilize a Position To: prompt.) That was kinda fun! Thanks for keeping the thread going, Booth. - Dan Bale +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-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.