Re: Subfile "move to top" function

[Booth Martin <booth@xxxxxxxxxxxx>]

Have you looked at the SFLSCROLL keyword?  That may be useful to you for 
your design.

If real estate is an issue, have you considered a 132-column screen 
instead of 80-column?



On 2/16/2011 1:39 PM, M. Lazarus wrote:
>    Thanks all for the suggestions on how to handle different methods
> of subfile positioning.
>
>    SFLRCDNBR(*TOP) was a contender, but I don't like some of the side
> effects, such as when the cursor is in a record other than the first,
> that line jumps to the top.  I only want that behavior when a
> function key is pressed.  For this application, that behavior would
> be very annoying.
>
>    Also, the cursor always jumps to the input field in the SFCTL
> record, unless I explicitly position it at a specific subfile record,
> which is also not desirable.
>
>    For this application, subfile scroll bars and mouse button usage in
> DDS is not an option due to lack of screen real estate, lack of
> universal support for these features on all emulators and the rest of
> the application does not use these techniques, thereby giving an
> inconsistent UI.  The audience consists of a broad range of end
> users, with different shop standards and emulators.
>
>
>    I think my approach will be as follows:
>
> -  Records will be loaded into arrays and updates to the DB will only
> occur when the user requests it or when doing a Save&  Exit from the
> application.  This should give me a performance advantage and make it
> easier to manipulate the data.
>
> -  When a reposition of a record to the top is requested, reload the
> subfile based on -nth record on the current screen and position to
> that page/record.  So, given the following:
>
> SFL page size = 10.
>
> 35 records loaded.
>
> Cursor is on RRN 24 (aka page 3, record 4.)
>
> Pressing "F10=Position to top" will reload the subfile, beginning
> with RRN4, thereby eliminating the first 3 records from the
> SFL.   SFLRCDNBR(CURSOR) value will be 21, so the first record on SFL
> page 3 will be what used to be RRN 24, with the cursor positioned to
> that record.  A total of 32 records will be in the SFL at this point,
> instead of the original 35.
>
> PageUp will follow the new paging until PageUp is pressed on the
> first page.  At that point I will reload the SFL starting from RRN 1.
>
>
>    I think my biggest challenge will be to make sure to keep the lines
> in sync with the original data set, including multiple repositions by
> the user.  I don't think that's such a big hurdle to overcome.
>
>    Any additional thoughts?
>
>
>    -mark