>There are NO bugs in either Treeview 5 or Treeview 6 that I am aware of. They're pretty reliable. Just painful to learn!:)
>
>Does your NodeClick event have:
>

node.selected=.t.

>The unLTVX variable could be a public variable. You could move your treeview methods to source code (a procedure file). They seem easier to debug.
>Does the download (I recomended) with the hottracker feature crash?
>

Terry,

I added

Node.Selected = .T.

but that diesn;t seem to change anything. I will try the hottracker when time permits. BTW, I'm on VFP5, TreeView is v5.0 SP2, XP Pro.

Actually, here's what I'm trying to do ...

I've got 3 levels. The 3rd level nodes must respond to a double-click event differently from the upper 2 level nodes. It will return a selected ID of the entity in Form.Unload and issues THISFORM.Release.

Unfortunately, the TreeView.DblClick event fires even if you double-click on a 'white' or non-node area in the TreeView, and the entity ID of the selected node is returned and the form closed. This will seem a bit odd to the eventual users of the app.

Basically, I need to 'mask' out the DblClick events firing in the 'white' area of the TV.

My initial thought was to have the HitTest tell me if I'm on the node I want, from the last known {x,y} positions stored by the MouseMove event. I created a basic form to test out the usability of HitTest.

Anyway, I've found a workaround for that ...

In the Click event, I turn on a flag and trigger off a timer that will last longer than the slowest double-click duration. The Timer() event will turn off the flag after the set time has expired.

The Click & the NodeClick events are exclusive, so I put code to turn off the flag in NodeClick.

If a DblClick event fires within the time the flag is still on, I know I've got a 'white' area DblClick.

This far, it seems to achieve what I want.

Thanks again Terry.