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
>>>>