Problem in ListGrid with Selection when using Shift+Arrowkeys in order to select rows

[Blama]

Hi Isomorphic,

a customer made us aware of this selection issue when using shift+arrow-keys in order to select records in our application (v10.1p_2017-07-04, also happening online in this sample with v11.1p_2017-07-09, Chrome 59, Win10).
Please see this video:



Row 5 is clicked with the mouse and then some rows are selected with Shift+ArrowKeys.

• 1st issue is that when "going back up and deselecting rows", row 6 is not deselected.
• 2nd issue is that when the selection reaches row 3 and "down" is pressed again, the expectation would be to have rows 4+5 marked, not 3+4. Here is seems that the "reference base row" is not 5, but changes to the top selected row.
• This also happens in a similar wrong way in grouped ListGrids, but it is different here in 5.1/10.1 and 6.1/11.1

10.1:


11.1:




Best regards
Blama

[Isomorphic]

We're looking into the selection behavior you've reported and considering what changes, if any, should be made. Some of those interactions are long-standing behavior, which have been in place for many releases.

[Isomorphic]

We agree that there's been a regression in shift-selection behavior and are making a change that will restore the as-intended behavior to SC 10.0p and all newer branches. The fix should be in the nightly builds dated 2017-07-21 and beyond. This will address the fact that when you move down via shift-selection inside a selected range, records get de-selected.

However, as far as the other behaviors you point out - such as that an "extra" record appears to remain selected when you move back up after having moved down via shift-selection or that upward and downward movement are asymmetric with respect to what's left selected when you reverse directions - that is part of our long-standing and now expected behavior. There is no universal standard here and we don't claim to exactly match any other software, but if you're interested in Feature Sponsorship we would consider adding a new behavior option that matched - say - Windows Explorer.

[Isomorphic]

Update: We're considering some more significant changes to address your concerns, but it means that it will be a bit longer, and we won't necessarily apply the initial fix mentioned above to all branches in time for the 2017-07-21 night builds. When those other changes are committed, we'll update this thread.

[Isomorphic]

We've fixed the issues you describe as of today's nightly builds (dated 2017-07-29) in SmartClient 10.1p and newer releases. Note, however, that we still do not claim to match exactly the behavior of apps such as Windows Explorer, OS X App Finder, etc. If you have such specific requirements, you may need to consider Feature Sponsorship.

[Blama]

Hi Isomorphic,

thanks for the change. In 6.1p it's now working perfectly. I did not retest 5.1p.

Best regards
Blama