by Peter Wone - GUI Computing
Often it is desirable for a form to manipulate whatever form was previously active — we’ll call this its calling form.
In order to obtain a pointer to the calling form (oh all right, a Form variable referring to it) we build a stack of type Form using a variant and an array of Form. These variables are declared at the module level, and their scope is such that they are not visible to code outside their module, but within it they are exposed to all code.
Declared global arrays, routines and samples.
Real Programmers Can Write C++ In Any Language
There's a hidden nasty in all this. If (when) we neglect to sever the reference to an form which is not a child of the current form, the form can't shut down.
I don't suppose Microsoft ever expected anyone to have an form variable pointing at an form which is not a child of the current form.
What appears to be happening is, when you tell the form to close, a WM_DESTROY message is sent to it. The net effect of this is that starting from the bottom of a (potentially very long) linked list and working back to the form, child forms run their destructors and deallocate themselves, until finally the form has no children and can deallocate itself. All of which works nicely and is why it doesn't matter if you don't bother to
dynasetvariable.Close Set dynasetvariable = Nothing
before closing a form.
The fly in the ointment is that CallingForm refers to an form which isn't a child of the form. Form level variables are just about the last thing to go, so the form has even destroyed its window form1. Everything appears to work. Until...
Until you try to open the form again, when you get a "Cannot destroy previous instance of form."
So. Orphaned pointers in Access. And you actually believed Microsoft when they told you that pointers didn't exist in Access? Silly. Real Programmers can write C++ in any language.
So what do we do about this? Easy. Deallocate your pointers2 in the form's destructor like any normal C++ programmer.
What do you mean, you don't got one? Course you got one. It's called Form_Unload, which strikes me as a very reasonable name.
You're lucky it's not called fObj(OBJ_FRM).Destructor.