Image Map of Navigational Panel to Home/Contents/ Search Access 2.0 Pointer Problems

by Peter Wone - GUI Computing

Image of line

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.

Image of 'How To' title 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.

Happy trails!


1.A form isn't a window, a form has a window. You may have a car, and you may even get inside it, but that doesn't mean you are a car, even though at night the car is all people can see. Get it?
2.Tell me again, Microsoft, that an form variable isn't a pointer. I love it when you tell me lies.
Written by: Peter Wone
June 94

Image of arrow linked to next page
Image of line
[HOME] [TABLE OF CONTENTS] [SEARCH]