Re: main difference between expandable and singlepage subfile

I suspect from some of the previous notes that there might be some
terminology ambiguity.

Non-extendable (SFLPAG = SFLSIZ) means you are simply using one page. Page
Up and Page Down are available, but the application program is simply
reloading the same page with a new set of data. In this case there is no
9,999 limit.

Extendable means you write X SFL pages and if the user presses Page Down on
the last page you load the next X pages after the previously loaded pages.
Here the 9,999 limit comes into play and X is often = 1.

I generally use extendable loading X = 1 pages with each Page Down past the
current end of the SFL. I have however sometimes loaded a much larger
number of pages (typically controlled by a configuration option).
Specifically I have used this approach (loading > 1 page at one time) when
the SFL is defined with SFLDROP and SFLFOLD. What I found (and could not
seem to control though perhaps I missed it) was that if I was showing a
truncated page and the user then switched to non-truncated mode the system
would show the first N SFL records ( that is, what would fit on one page
non-truncated). If the user used Page Down from here they would see the
next N non-truncated SFL records. If they paged down say twice (leaving
them in the middle of the last page loaded) and then switched back to
truncated mode the system would automatically (no interrupt to the
application program) display the truncated page with the top row being the
row at the top of the last shown non-truncated page. The end-user would
see truncated SFLPAG - (N * number Page Down requests) records and blank
records for the records that might still exist but have not been written to
the SFL since there was no interrupt when processing a mid-point of the
last existing SFL page. If the user uses Page Down at this point the
application gets control and can write the next number of records/pages.
But some users consider a partial SFL page being displayed as indication
the SFL is complete (and don't notice the + sign to indicate otherwise).
Loading a large number of records per load minimizes (though doesn't
eliminate) this exposure. I hope the above makes sense -- it's a lot
easier to understand 'seeing' it compared to describing it...

On Mon, Nov 25, 2019 at 4:58 PM Booth Martin <booth@xxxxxxxxxxxx> wrote:

I set a limit in the subfile build. If the subfile exceeds that limit
then the user sees a message window suggesting a tighter filter, or that
only the first x records will be displayed, or ... .

dou sqlcode <> 0 or SFLNUM > 200; // limit subfile to 10 screens:

As an aside, one of the consequences for me is being forced to think
through the design a bit more. Usually this results in better user-flow
and easier new-user training. In other words, a better product.


On 11/25/2019 2:18 PM, Jon Paris wrote:

I tend to agree that 9,999 should be more than enough - but how to

handle that in a user-friendly way is the issue. If you have offered them
to display customers with a wildcard match on the name and they enter*a*
on a high file ...
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com