Hi Agnes,

Well, you may be right about the form, I just do not see it any more, all references to it are gone.

What I think though, is that when an object is created in a datasession (the treeview here), it points to the datasession.
If the Treeview does not release properly, the datasession cannot release since it still holds a pointer to it.

Think your mirror is a good idea. I will have to create two methods, one for creating a node and one for removing a node. These two methods will update a property or a cursor of the nodekeys that exist. Hence the NodeExists() function will not error any more

Gregory
________________

>Hi Gregory,
>>Conclusion as far. There is a relation between the datasession and a Treeview error. ...
>
>Just one step more. The relation is not direct between Datasession and Treeview.
>It's more likely that the treeview will hold the form and the form will hold the datasession. (Think about a callback in the error)
>The problem is, that the treeview is the one and only reference to the form. Any other reference, even _VFP.FORMS is gone. It seems that the datasessions are handled a little bit special so the datasession will be 'visible'.
>
>>....The art or challenge is in avoiding the error. Sort of: you can come as close as you like, but do not touch
>
>Good point. Thats what I told you about a mirror or shadow structure of nodes. Anything will be done within the mirror structure. I simply mistrust the treeview.
>
>Agnes
>
>>
>>Thanks for the intrest
>>
>>
>>
>>>Hi,
>>>
>>>I think you've sort of worked this out elsewhere in this thread but FWIW:
>>>
>>>I've found that any untrapped error with a treeview operation (typically an invalid attempt at adding nodes) can prevent the treeview (and consequently it's form) from being released cleanly. If the DataSession still exists then it's a pretty good indicator that the form has NOT in fact 'closed normally' - if you check I'll bet the forms Unload() did not in fact fire.
>>>
>>>I always code for errors in the Treeview's own Error() method - even if it's just to ignore them <g> and that seems to prevent the problem.
>>>
>>>HTH,
>>>Viv
>>>
>>>>>
>>>I've got a Form with a (subclassed) container ( Treeview control and ImageList control ).
>>>The Form has a private datasession. Closing the form leaves an unknown datasession behind. The form closes normally.
>>>Except for
>>>this.Treeview.ImageList = this.ImageList
>>>in the init() of the container, there are no object references being kept.
>>>
>>>Any solution to get rid of the unknown datasession ? (vfp6sp5)
>>>
>>>Leaving the ImageList out does not help either
>>>>>