Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Avoiding ghost forms and grey hair 1

Status
Not open for further replies.

HappyCoda

Programmer
Sep 26, 2005
10
AU
Just been through a fun little debugging effort that began when I discovered my form had a ghost!

I'd open the form from a commandbutton and play with the newly openened form via VB. Happily. That is, until I discovered the values I was getting back from VB disagreed with what the form was telling me on screen.

I found out that there were two instances of the form open, one with visible=true and the other visible=false. The first was the one I had opened. The second was opened by aliens, I was forced to conclude. Until I discovered that these two statements produce entirely different results:

1. DoCmd.OpenForm(Form_FormName.Name)
2. DoCmd.OpenForm("FormName")

I had chosen method 1 so that if I changed my form name, I wouldn't have to change my code. Supposedly safer. I never had this problem when I was using .MDBs! However, in a .ADP if you call

Form_FormName.Name

and the form is not open, the project automatically opens a hidden instance to query the property (.Name) and doesn't close it. Hence method 1 opens the form twice. When you query the form in VB, you're actually talking to the initially opened, but hidden, instance of the form.

I guess I was being too tricky for myself!!!

Hope this helps someone somewhere or is interesting to same.

Cheers,
HappyCoda
 
Gee whiz, HappyCoda, depriving the rest of us of this FUN debugging experience you had by posting it on this forum. What can I say but
------------------
THANKS!!!!
------------------

---------------------------------------
The customer may not always be right, but the customer is ALWAYS the customer.
 
Hey NorthNone, you're welcome! Sorry for the deprivation, though, but I'm sure there are plenty of other fun and exciting ways out there of earning your grey hairs! :)
 
The technical explanation is that forms are class modules, that is, objects. And all form objects in Access have essentially been predeclared invisibly as

Code:
Dim Form_MyForm As New Form
This special syntax using the keyword New lets VB know that you want to automatically instantiate the object the moment you use its name. And, if you set the object to nothing, then use the object again, it re-instantiates it. So as you described, Form_MyForm.Name instantiates the form invisibly. This method also has weird side-effects because the form will only stay open as long as the instantiating code is still executing, or some object reference to it exists, and resetting code will close the form. You also can have multiple forms of the same name open so Forms("Formname") doesn't work.

For what it's worth, I don't see how the Form_MyForm method would protect you against a form name change, because in that case it would then be Form_MyOtherForm and Form_MyForm will fail with a "variable not defined" or "User-defined type not defined" error, or something similar, depending on how you used it.

If you'd like to know about another access headache you can avoid, see Controls bound to bit columns crash workaround

 
Thanks, ESquared. All Makes sense. And you're right, my little work-around wouldn't do jack if the form changed names. I was thinking of:

DoCmd.CloseForm, acForm, me.name.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top