>The current VFP grid has always displayed the results (of a table search) in the center/middle row of the grid (instead of at the top). This has always puzzled me.
>
>The Browse window has always displays the results from the very top downwards, which I would say is much more correct.
>
>I realize that this can be achieved in a grid, using a bunch of tricky code involving Doscroll, and one has to play around with the problems of the textbox sometimes losing focus, etc. ( I have got this code working by the way).
>
>Am I the only one that finds this a pain? Has everyone else accepted this particular behaviour of the grid. (I do not see any requests for this improvement in the wishlist.)
>
>Why, some of you may ask, do you want the results displayed from the top row, instead of the center row?
>Answer: Because it wastes valuable space. Only the bottom half of the grids records are relevant. The top half of the grids records are not relevant.
>The end-users will generally type text into a search box. The results will display in the grid. If the users have typed in “Jones”, they want to see a grid full of “Jones”s, starting from the top. They are not interested in seeing the top half of a grid filled with “Jameson”s and only from the center down filled with “Jones”.
>
>I would like to see a future VFP grid having an optional property to display results either in the Center, or at the Top of a grid. It would make things so much easier.
>
>Your thoughts would be appreciated.
>
>regards
My 2c :
Firstly, "accepted" means you have a workaround. After that, "oh what". However, all the things to arrange for that really is a waste of time.
Right now I am not able to see anymore how the grid behaves originally, but there is some more I recall, originating from the functionality demanded :
Showing the last part of the ControlSource (table) causes the most pain. Hence, why to show the half of the grid(content) only ? Look at Browse; it's really the same. Also (looking at Browse) it's rather random, depending on the lastly selected record (and the size of the grid).
Just think of someone browsing through the grid downwards, coming to the last part. Once the previous topic is solved, all kind of strangenesses occurs related to pressing "PgDn" once more, showing the data shifted one row, hence it doesn't look like the end. A real pain (but possibly caused by the solvation of the previous topic).
How to make a row current ? at browsing, the active record does not change. I can't say that it should, but at least there should be some provision for "always first row" or similar. Of course, this is easy to solve initially, but it really is not when the grid is allowed to be resized etc.
Once you decided that -for example- the active record within the visible grid must be at a different location at the various actions, again you have to do it all yourself. Compare ^PgUp with ^PgDn, the first logically selecting the very first row, and the last selecting the very last row. Though opinions may differ, to me this is logic. Again, easy to solve, but more difficult within the other "problems".
Of course, I (think I) know the logic of making a row the actual row. But I find it a rather way around to do this via the ControlSource. And, as far as I know, you ALSO have to do it via the Grid itself. I'd rather have a command that makes a row actual, implying the ControlSource's record to become the actual one implicitly. I mean, right now there is too much that can go out of line.
Where the grid (IMO) was designed to show a cursor (i.e. all what's in there), in the end it doesn't adapt to that really. This is hard to explain, but comes to the fact that once the cursor's result (number of records) have been made equal to the size of the grid (and not the other way around ...) you bump into all the problems at the same time. Possibly one just HAS to size the Grid to the result of the cursor ...
Somewhat opposed to the above I'd like to see some auto-interaction between the grid coming to its end of the data, and the remote DBMS filling the cursor again. Really, once you approach a system like "read 1,000 records a time" why I have to initiate the new read from the dbms ? Looking at remote views (being very nice in its basis) this really can't be done like this (I think). But how nice would it be ... (and how much would it improve on performance).
Why is it so hard to show the actual row ? IMHO it needs all kinds of tricks to do this properly, and the standard feature shows the actual row "a little" only, depending on the further colors.
Create grids visually ... pfff. I know, tools exist to do it for you, but they are always in lack of something. So you end up with the maximum number of columns you expect there ever to be (implying overhead I think). Besides this, you end up with these standard columns only after trying for many days otherwise ... Okay, do it in code. But for the beginner, this is not where to start from (or ?).
Please note that the latter has all to do with method-code you need. Also note that this wouldn't be needed (most cases) once there would be some event properly working as a trigger on the various parts of the grid. More difficult to explain, but think of method code to fire from a column created at runtime from some method at the grid level. I am not exactly sure anymore what events I am talking about, but I think it was about Refresh, Resize and all you can think of on the column not working out to the grid itself, whereas a Refresh of a column really refreshes the grid too (or ?).
Again, 2c only and by heart (oh, and derived from VFP5, sorry).
Anyway, to my findings grids could be improved a LOT, and they are about the first a newby will work with. So I guess it's a commercial aspect as well ...
Surely, I am not the know-it-all on this subject, but it is how I encountered the grid anyhow.
But I am an accepted-one, because all is working now.
