> Should the user get involved or should one let VB take care of the matter and how does one track (confirm) whether the specific Form instance was destroyed.
Both are hard questions. What I prefer for logging puposes is to have nested init/terminiate events logged for referenced objects like this
Parent Init
Child Init
Child Terminate
Parent Terminate
For this to happen the Parent class has to use something similar to this
Code:
Private Sub Class_Initialize()
DebugPrint "Parent Init"
'... more init here
End Sub
Private Sub Class_Terminate()
Set m_oChild = Nothing
'... more cleanup here
DebugPrint "Parent Terminate"
End Sub
Without the explicit Set m_oChild = Nothing the reference in the member variable will get auto-cleared right past the Terminate event so the debug log will get inter-leaved like this
Parent Init
Child Init
Parent Terminate
Child Terminate
Also there is a bug in the IDE, if you add watches (or evaluate expr) in Terminate event that is called from internal run-time cleanup, then the interpreter goes berzerk and skips tear-down altogether with catastrophic results, so setting child references to nothing prevents this bug as well.
Tracking instances has been discussed here before. There is nothing built-in besides the Forms collections and it's not tracking strictly form instances (rather the UI part of these forms). For robust instance tracking one has to be prepared to implement in VB6 techniques similar to memory allocation tracking in MFC or other C/C++ frameworks. It turns out that writing robust production-grade VB6 code is *not* easier than writing it in C/C++ which was a kind of a revelation for me after all those years in the field. I'm inclined to believe that writing production code is similarly hard in *any* language.
cheers,
</wqw>