Hello:
I am back to working on my grid. Every time I start to dig in, my boss gives me some other work to do. Some day, I may actually have something useful.
Right now, I am working on a model using an array. It is, of course, very easy to move within the array when there is no need to adjust the view array. (The array holds only those rows which could be viewed in a grid/browse.)
When the view array has to change, I want to behaviour to be like a browse. I am a bit puzzled by the behaviour of a browse though. Here is what happens on my system:
(Note that when I refer to a row, I am referring to the row of the browse counting from the top UNLESS I state "table row".)
I open the browse. The current row is the first one.
I execute a skip 10 and then click on the browse. It updates the current row to being the 11th. Good.
I execute a skip 10 and then click on the browse. It updates the current row to being the 21st. Good.
I execute a skip 10 and then click on the browse. At this point, I know that the view will change. What it does is unexpected. It does not simply advance 10 rows and scroll the display so the current row is the bottom row. Instead, it scrolls such that the current row is the 16th row. This is not halfway which would be the 15th row.
If I instead execute skip 20 twice, I get the same row (16th) being the active row.
The above are what I get if there are enough rows for the skip to be fully done. If there are not, the 16th row is still the active row, and it has the last table row. (This is assuming that there are at least 16 table rows.)
If I adjust the browse height so that there are 14 rows, then the odd positioning is to the 8th row. Handy size chart: Browse Active Height Row ------ ------ 30 16 29 16 14 8 5 4 4 3 3 3
The same sort of behaviour happens with negative skips.
Obviously, the function is active row = int((browse height + 1) / 2) + 1.
But why?
Sincerely,
Gene Wirchenko