× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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 thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.