Re: Fetching more records for a grid


"Dan Freeman" <spam@xxxxxxxxxxxxx> wrote in message
news:eM8M32GAIHA.4880@xxxxxxxxxxxxxxxxxxxxxxx

OK, this is a general application design issue. I'd argue that an app that
browses through millions of customers is generally less useful than
needed. You, yourself, said nobody ever does that.

Users generally have *some* idea what they're looking for. Ask them to
type something and then show them a list of likely matches. Parameterized
views are *excellent* for this.

After all, a user that's paying bills probably has in-hand a bill from the
vendor they're going to pay. Ask them who it is! This approach plays
nicely into the C/S paradigm. *NO* approach to "show everything and let
them pick" plays nicely into it, least of all changing how the standard
U/I elements work.


Here's the big BUT

BUT I need to maintain some type of similar UI from the old form (which used
the giant table as the recordsource for the grid) to the new one which only
loads 100 records at a time.

Here are the problems:

1. The application has always opened to the first screen full of data in the
table. It does not begin with a search. It is after the form is displayed
that the search can be performed. This is not a problem. The only real
problem is...

2. Sometimes they actually do want to browse through several hundred or even
a few thousand records. They might search for the first one but then browse
through an entire account.

In my current version of the form, they could scroll all the way to the end
of the table as I've said before.

My new version loads 100 records at a time. If I find myself pulling records
from an SQL database instead of using native DBF files then I will want to
stick to this 100 record limit.

I would, however, like to simulate the old "browse through the entire table"
format that they are used to looking at. This means that if they reach the
100th records on the form, I'd like to automatically fetch the next 100. If
they try to scroll up from the first record on the form, I want to fetch the
previous 100 records.

Thanks again,
Jeff


Dan

Jeff Grippe wrote:
My users are used to an application that "browses" the entire
database. The application (or a version of it) goes all the way back
to FPD 2.x and DOS.
I theory, with the current version of the app, they can scroll all
the way from the first record of the table to the last record of the
table. The table has several million records so in practice, nobody
ever goes through the entire database.

If I'm going to convert this app to something that can use SQL and
views, I need some way to simulate the feel of the existing
application.
That is why I need to be able to fetch the next (or previous) group of
records.

Right now I put buttons on the form to do it and that will probably
work fine but it would be nice if it were more elegant.

Thanks,
Jeff
"Dan Freeman" <spam@xxxxxxxxxxxxx> wrote in message
news:OZU08JFAIHA.4612@xxxxxxxxxxxxxxxxxxxxxxx
Wouldn't be natural at all. Highly unnatural, in fact.

This will be a lot of work and probably be confusing to users.
They're used to the last record being at the bottom, not "the last
until you ask for more".

I'm sitting here trying to think of *any* other application that
works as you've described and I can't come up with anything. I'd
rethink this. Dan

Jeff Grippe wrote:
Hello and thanks in advance for the help...

I have a grid control which is based on a small table that is
extracted from a larger table. When the user scrolls to the last
row, I would like to be able to requery and show the next (or
previous if the user scroll up from the first record) batch of
records. How do you detect all of the various method (Keyboard, Scroll
Bars,
Etc.) that the user might be using to scroll up from the top or down
from the bottom.

I could put menu items on the menu to requery but it would be more
natural if they could just work in the grid.

Thanks,
Jeff




.

Loading