Re: Subfile "move to top" function

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

At 2/13/2011 05:36 PM, you wrote:

A couple of thoughts:

- MOUBTN() is a useful keyword.

- "SFLSCROLL (Subfile Scroll) keyword for display files

You use this field-level keyword in the subfile-control record format to
return the relative record number of the subfile record that is at the
top of the subfile when control is given back to your program."

Is that of any use in the process you desire, Mark?

On 2/13/2011 4:06 PM, Joe Pluta wrote:
> On 2/13/2011 3:49 PM, M. Lazarus wrote:
>> Joe,
>>
>> I usually want to keep the same paging, unless the user
>> specifically requests it. Otherwise it can be disconcerting when
>> every action shifts the target line to the top of the page. I guess
>> I'll have to play with the *TOP version and see if it behaves acceptably.
>>
>> -mark
>
> Okay, good luck. I understand your wanting to keep the paging
> normalized I'm still a bit confused, though. If the user switches the
> top, won't that become the "new normal"? At that point, if you then go
> back to the old style SFLRCDNBR, you'll shift the perceived top, won't
> you? It seems to me that if you are going to allow the user to change
> the base for the top, then you'll have to basically replicate the
> SFLRCDNBR logic yourself. Find out which record number of "top" +
> "multiple of page size" is less than the record you wish to display, and
> then put that in SFLRCDNBR. Then position the cursor using either a
> conditioned DSPATR(PC) or by absolute cursor positioning.
>
> Joe

--
Booth Martin
802-461-5349
http://www.martinvt.com