问题
This question will seem obvious to those who haven't encountered the problem themselves.
I need to handle selection changes in VTV. I have a flat list of nodes. I need to do stuff with all currently selected nodes whenever
- User clicks a node;
- User Shift/Ctrl-clicks a node;
- User uses arrow keys to navigate the list;
- User creates selection by dragging the mouse
- User removes selection by clicking on empty space or Ctrl-clicking the only selected node
etc. It's the most common and expected behavior, just like Windows Explorer: when you select files with mouse and/or keyboard, the information panel shows their properties. I need nothing more than that. And this is where I get stuck.
Some of my research follows.
At first I used OnChange. It seemed to work well, but I noticed some strange flickering and I found that in the most common scenario (one node is selected, the user clicks another one) OnChange is fired twice:
- When the old node is deselected. At this time the selection is empty. I refresh my GUI to show "nothing is selected" label in place of all the properties.
- When the new node is selected. I refresh my GUI again to show the properties of new node. Hence the flickering.
This problem was googleable, so I found that people use OnFocusChange and OnFocusChanging instead of OnChange. But this way only works for single selection. With multiple selection, drag-selection and navigation keys this doesn't work. In some cases Focus events don't even fire at all (e.g. when selection is removed by clicking empty space).
I did some debug output study to learn how these handlers are fired in different scenarios. What I found out is a total mess without any visible sense or pattern.
C OnChange
FC OnFocusChange
FCg OnFocusChanging
- nil parameter
* non-nil parameter
! valid selection
Nodes User action Handlers fired (in order)
selected
0 Click node FCg-* C*!
1 Click same FCg**
1 Click another C- FCg** C*! FC*
1 Ctlr + Click same FCg** C*!
1 Ctrl + Click another FCg** C*! FC*
1 Shift + Click same FCg** C*!
1 Shift + Click another FCg** C-! FC*
N Click focused selected C-! FCg**
N Click unfocused selected C-! FCg** FC*
N Click unselected C- FCg** C*! FC*
N Ctrl + Click unselected FCg** C*! FC*
N Ctrl + Click focused FCg** C*!
N Shift + Click unselected FCg** C-! FC*
N Shift + Click focused FCg** C-!
1 Arrow FCg** FC* C- C*!
1 Shift + Arrow FCg** FC* C*!
N Arrow FCg** FC* C- C*!
N Shift + Arrow (less) C*! FCg** FC*
N Shift + Arrow (more) FCg** FC* C*!
Any Ctrl/Shift + Drag (more) C*! C-!
0 Click empty -
1/N Click Empty C-!
N Ctrl/Shift + Drag (less) C-!
1 Ctrl/Shift + Drag (less) C-!
0 Arrow FCg** FC* C*!
This is quite hard to read. In the nutshell it says that depending on the specific user action, the three handlers (OnChange, OnFocusChange and OnFocusChanging) are called in random order with random parameters. FC and FCg are sometimes never called when I still need the event handled, so it is obvious I have to use OnChange.
But the next task is: inside OnChange I can't know if I should use this call or wait for the next one. Sometimes the set of selected nodes is intermediate and non-useful, and processing it will cause GUI flickering and/or unwanted heavy calculations.
I only need the calls that are marked with "!" in the table above. But there is no way to distinguish them from inside. E.g.: if I'm in "C-" (OnChange, Node = nil, SelectedCount = 0) it could mean that user removed selection (then I need to handle it) or that they clicked another node (then I need to wait for the next OnChange call when new selection is formed).
Anyway, I hope my research was unnecessary. I hope that I'm missing out something that would make the solution simple and clear, and that you, guys, are going to point it out for me. Solving this puzzle using what I have so far would generate some terribly unreliable and complex logic.
Thanks in advance!
回答1:
Set the ChangeDelay
property to an appropriate, greater than zero value in milliseconds, e.g. 100
. This implements the one-shot timer Rob Kennedy suggests in his answer.
回答2:
Use a one-shot timer. When the timer fires, check whether the selection is different, update your display if it is, and disable the timer. Each time you receive a potential selection-changing event (which I think is always OnChange), reset the timer.
This gives you a way of waiting for the event you really want and avoid flickering. The cost is a slightly delayed UI.
回答3:
I assume that you might have used the answers given here or even found another solution but I would like to contribute a bit here...
In a NON-Multiselect environment (I have not tested it in a multi-select environment) I have found a quite simple solution without the delay:
Keep a global PVirtualNode pointer (Lets call it FSelectedTreeNode). On startup obviously you will assign nil to it.
Now eveytime you use your arrow keyboard keys to select the next node the OnTreeChange will happen twice. Once for the node that will be deselected and once for the newly selected node. In your OnTreeChange event you do the following:
If Node <> FSelectedTreeNode then
begin
FSelectedTreeNode := Node;
If Node = nil then
{Do some "Node Deselected" code}
else
{Do whatever you want to do when a new node is selected}
end;
This works quite well with my code and it has no flicker and at least no delay.
The trick is that the newly selected node will be assigned to the global pointer and it will happen last. So when you select another node afterwards it will not do anything on the first OnTreeChange because then the global pointer will be the same as the node being deselected.
回答4:
You forgot OnStateChange event. This event will be fired right after any selection change and you can then handle all selected nodes.
procedure TForm1.vstStateChange(Sender: TBaseVirtualTree; Enter,
Leave: TVirtualTreeStates);
begin
if tsChangePending in Leave then
DoSomething;
end;
来源:https://stackoverflow.com/questions/7995559/virtualtreeview-properly-handling-selection-changes