In a browse in our application, the user can select multiple records. The order of selecting the records is important here, because the records have to be processed in the order the user selects (production orders).
If the user selects them one by one with the mouse, everything works fine.
If the user drags a selection (selecting one record, then move the mouse up or down while holding mousebutton pressed) everything works ok, both up and down.
If the user selects one record with the mouse, then shift-selects another record, things are getting less clear. If the secondly selected row is BELOW the first one, the order of selecting is ok. If the second row is ABOVE the first one, the order of selection is inverted.
I created a small test program so you can play with it. You can find it here as a Github gist.
If you run it, it will look like this:
Select record nr 5 with the mouse, press SHIFT and select record nr 1. Then press the 'show order' button. This button just shows the order of selection:
In this case it will show:
This is strange, because I started with nr 5 and then extended the range to 1, so I would have expected the order to be exactly the reversed of this.
As you can see, I experimented with capturing the state of the SHIFT key, so I could possibly revert the order of the records when the selection was done holding the SHIFT key, but is there a better way than this?
Looking at the source, it seems that the order of selection for SHIFT clicks was intended to work in the way you expected but then the developer got it exactly backwards. There's a comment that says "Want to select range, from previous focused row to row just shift-clicked" but the code that selects rows does the following to determine which direction to add them.
if (focusRow > clickedRow)
{
goForward = TRUE;
}
else
{
goForward = FALSE;
}
If the code matched the comment it would be the opposite.
The documentation for FETCH-SELECTED-ROW says:
[quote]The AVM maintains a numbered list of selected rows, starting at 1. The AVM builds this numbered list as the user selects rows in the browse. When you call the FETCH-SELECTED-ROW method, the AVM searches this list to find the nth row selected by the user.[/quote]
This can be interpreted to mean that the rows are supposed to be added in the order they are selected, in which case the current behavior would be a bug. I don't know if we should change this behavior now because there may be other applications which rely on it (though I can't see how they could, as your examples illustrate).
Thanks for verifying. I just did a little test in 9.1d and the behavior is exactly the same. I am wondering if I should report it as a bug since it has probably always been this way.
For now, I think we will work around it, using keyboard state.
It has, indeed, always been this way. The code in question was added 20 years ago for 9.0A and hasn't been changed since.