Re: Subfile "move to top" function

What we did was put together a check for the capability, if it's not
there, we display a screen with instructions on how to re-configure
the emulation session. Along with a note to contact our support line
if the user has any questions or problems.

Charles

On Wed, Feb 16, 2011 at 3:46 PM, M. Lazarus <mlazarus@xxxxxxxx> wrote:

Booth,

 I still have the same somewhat artificial, but real limitation of
not having control over how people's emulators are set up.  If it's
not 132 position capable, I'll either get an error or, if I test for
that condition, the functionality goes out the window.

 -mark

At 2/16/2011 03:21 PM, you wrote:

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

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.