Hi!

There are no other simple way. There are no any event firing between first click and Expanded event filring after second click on the node during the DblClick process. When Expanded event fired, node is already expanded. There is no even where to put NODEFAULT, at least I see no way.

You can use another approach for tree, however, so it will look as good as possible. When node expanded by Double Click, NodeClick is fired in this process, when it is expanded by the "+", NodeClick is not fired. So in the Expanded event you can distinguish which way node was expanded and collapse nodes as quickly as possible.

In addition, it is good idea to put only blank node as a child node and no other nodes. When node expanded by "+" sign, then add child nodes on the fly after removing the blank node. Otherwise collapse it back (Double click). This will assure also that tree contains little of nodes (so users will not be able to catch the jumping during double click).


LockWindowUpdate can help only if you will find a good use for it in the NodeClick event. How you will unlock when user did not clicked second time? In MouseDown event, I guess, but this require some experimenting.



>Hi Sergey,
>
>The native behavior of the dblclick on a node in a treeview control is to expand or collapse the node. Unlike a VFP control, this OLE control appears to execute it native behavior before, not after, the DblClick() method fires. Therefore, by the time any code in the DblClick() method is reached, the expand or collapse has already occurred.
>
>I can easily reverse this by issuing a

this.Expanded = !( this.Expanded )

in the DblClick() method. The effect is a flicker visible to the user as the previous unwanted expand or collapse is reversed.
>
>I am tying to prevent the flicker by preventing the expand/collapse from occuring in the first instance.
>
>Another approach would be to lock the control from repainting using the LockUpdate API function. The problem again is that the unwanted native behavior has already occurred before the LockUpdate code is reached in the DblClick() method, so issuing a LockUpdate call in DblClick() is ineffective.
>
>Thank you for your response. I hope you have an idea or two to share.
>
>Regards,