Improve multi-selection for touch UI by adding option that synchonizes selection and check-state

[joachimmarder]

The desired behavior should be similar to Windows 10 Explorer with checkboxes activated on the right pane.

[sanjayssk]

I did a test implementation on basic high level paths and the basic select and multi-select is now working which is exactly similar to Explorer check boxes. But I found numerous cases on inspection of the code where this should work, for example, draw selection, reselection or selection when inserting nodes by stream (copy, paste), etc. This is more work, and I have marked all such paths and then am going to make the new feature work for all of the paths by a different low level code. Some paths will need a modification of the demo for testing and verification.

[joachimmarder]

In case the necessary refactorings are large, we should consider postponing this issue for V7.0. I would like to have the last V6 release to be stable. A new major version is a good point to do in-depth refactorings.

[sanjayssk]

I have now implemented this in my local copy and tested all the paths. It works. Besides, this code is used only when the new Selection option will be turned ON which is OFF by default so existing applications not using this option are not going to be affected. Do you still think that I should postpone it?

BTW, this option is not specific to touch. When it is ON and check boxes are shown, this works exactly like Windows Explorer's Show Checkboxes feature. So it works even with the mouse, including the multi-selection/draw-selection behavior from Explorer where when you change selection, check boxes follow the selection and when you click on check boxes, the selection follows the check boxes. In that sense, it's useful even without Touch if the application wants this kind of feature.

FEEDBACK REQUESTED:
Currently, I have made the tests with a global flag. But now I'm going to implement the option itself. Hence a feeback is requested on the following:

The option name I thought of is toSyncCheckboxesWithSelections (please suggest a shorter name that conveys the meaning)

It's a TVTSelectionOption and requires 2 other conditions to be effective:

1. Check boxes must be shown:
   (toCheckSupport in FOptions.FMiscOptions) and Assigned(FCheckImages)

2. The Node's CheckType should be ctCheckBox. It won't be supported for ctTriStateCheckBox as that contains too many paths to check and verify because the selection propagates to parents or children.

But the above conditions can only be mentioned in the comments as per the standard in VirtualTreeView code where many options depend on other options. The conditions will be evaluated via a function at run time because the checktype is in the node.

[joachimmarder]

Do you still think that I should postpone it?

This is entirely up to you. It was just meant as a kind of offer to postpone the bug in case the chnages are very extensive.

BTW, this option is not specific to touch. When it is ON and check boxes are shown, this works exactly like Windows Explorer's Show Checkboxes feature.

Yes, this was the intention.

The option name I thought of is toSyncCheckboxesWithSelections (please suggest a shorter name that conveys the meaning)

I vote for toSyncCheckboxesWithSelection without "s". If I need to choose, I prefer a self-explanatory name over a short name.

[joachimmarder]

But the above conditions can only be mentioned in the comments

Additionally you can set the depending properties / flags in case the toSyncCheckboxesWithSelection is added at designtime.

[sanjayssk]

Yes, that makes sense. Thanks.

[sanjayssk]

Additionally you can set the depending properties / flags in case the toSyncCheckboxesWithSelection is added at designtime.

I would have liked to switch on something in Design to instantly get the CheckBox support of many kinds, simple checkboxes that are streamed, above sync checkboxes, with selection, and more. But VTV also requires that each node then should switch on its CheckType in its initialization event. That will need special flags and the associated logic for pre-initialization of the node.

May be, in version 7 we should look at giving more such features that do not require writing code. Have there been any requests for such design-time features?

[joachimmarder]

But VTV also requires that each node then should switch on its CheckType in its initialization event.
That will need special flags and the associated logic for pre-initialization of the node.

You are right. But maybe it would be a good idea to initialize the fields CheckStateand CheckType of a new node in TBaseVirtualTree.MakeNewNode with some useful values instead of leaving them uninitialized.

[joachimmarder]

Have there been any requests for such design-time features?

I don't think so. But all open feature request can be found in the issue tracker flagged as "Enhancement".

[sanjayssk]

But maybe it would be a good idea to initialize the fields CheckStateand CheckType of a new node in TBaseVirtualTree.MakeNewNode with some useful values instead of leaving them uninitialized.

This will be nice. I will inspect and see if I can find clues on why it was left uninitialized. If we can initialize them then switching on the CheckBoxes would be easier by the option.

[joachimmarder]

I will inspect and see if I can find clues on why it was left uninitialized.

I cannot imagine any except performance. But the difference will be absolutely negligible. We should however open a separate issue for this change.