Re: Fetching more records for a grid
- From: "Jan" <Nomail@xxxxxxxxxxx>
- Date: Thu, 27 Sep 2007 16:10:26 +1000
Jeff,
The concept you are describing is similar to the TBROWSE function in the old clipper days and now (apparently) carried forward to visual objects. However in all the chatter on this thread there were several issues overlooked, What if a record is added that logically becomes the next record when the user arrows down, because you have an extract of the real table, the user will not see this unless they drop out and go back in again or scroll past the current 100 and back again.
The same issue applies to if another user deletes a record, the deleted record will still be visable to this user until the data is refreshed. What happens though if the user decides to action the deleted record?
Codewise to achieve what you want is not onerous, in clipper the TBROWSE function was only about 50 lines of code and catered for drawing the boxes (grid) and maintaining the scrollbar on the side etc. The philosophy of the code was to read the first page full of records into an array and display the array (say 10 records). When the record pointer was moved the array was refreshed, thus the data was always current. When the user issues a page up Skip back 20 recs (or whatever the nuimber of visable rows x2 and refill the array then update the display. HOME and END were also catered for (top & bottom).
Under VFP and Windows all this control was given over to the grid control, hence all the problems with grid highlights and data filtering etc that the grid was notorius for in the early days, some of which still linger on.
But back on topic, I use grids in a similar fashion, with a search box and an option group to specify display and search sequences. What this allows me to do is match to the data sought as the user types ie Smith, John. I use the comma to concatenate fields, so Smi,joh might find John Smith where Smi finds Smith, the comma says pad out the key with the contents of the current record (ie Smith) then look for the contents of the next key ie John.
This idea leads to very fast data location and is flexible enough to allow the user to find smith then scroll through the neighbouring records for the exact match.
I base my grid and search field directly on the table and I don't use SQL.
Rgds
Jan
"Jeff Grippe" <jeff@xxxxxxxxx> wrote in message news:13fkra877o77lb2@xxxxxxxxxxxxxxxxxxxxx
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
.
- Follow-Ups:
- Re: Fetching more records for a grid
- From: Jeff Grippe
- Re: Fetching more records for a grid
- References:
- Fetching more records for a grid
- From: Jeff Grippe
- Fetching more records for a grid
- Prev by Date: FRead vs. FileToStr
- Next by Date: help on sql-statement
- Previous by thread: Re: Fetching more records for a grid
- Next by thread: Re: Fetching more records for a grid
- Index(es):
Relevant Pages
|
Loading