me.name vs me.formname

[Guus2005]

Odd thing happend to me today,

I upgraded from Acc2010 to Acc2016, still using mdb files, i created an mde file for the customer who runs it in an Acc2010 environment.

I tested it on Acc2010 and it gives me an error message.
"Method 'Name' of object 'Reference' failed"
Which refers to this command:

DoCmd.Close acForm, Me.FormName

I didn't write this program, to close a form i always use:

DoCmd.Close acForm, Me.Name

Compiling this code doesn't give me an error on both. Intellisense doesn't complete Me.FormName when you type Me.FormN<ctrl><space>.

I didn't know about Me.FormName but my program is full of it. So probably it meant something in the past.

Does this sound familiair?

About the error, i will try to create an mde in Acc2010 that should get rid of the error. It has always worked like that.

Thx!

 

[Pat Hartman]

"FormName" is not a reserved word.

The "Me." indicates that the field is a member of the fields collection of the form or report's class module. If Me. doesn't pull up intellisense that includes FormName, then there is something wrong with the form.

Where is FormName defined? It sounds like the developer did something "slick" and it is now coming back to bite you.

PS - when closing a form from within the form you would use:
Me.Close

So the only time you would use the statement you showed is if form A is closing form B.

 

[The_Doc_Man]

Is there ANY chance that this form in question was somehow involved with Outlook? Because the .FormName property belongs to Outlook (not to Access).

 

[Guus2005]

Thanks for your input.

FormName is also not the name of a control on the form or the name of the attached recordset field.
To my knowledge the application doesn't have any ties to Outlook.

In an odd way it is reassuring that two men with a combined expertise of more than 30 years also don't know what's happening here!

But thank you both for your time!

 

[missinglinq]

I've been working in Access for almost twenty years and have never heard of FormName either...although I suppose it could be something from a pre-2000 version of Access...a lot changed after Access 97.

You could go into the code window of any Form, go to Find, enter FormName , select Current Project and step thru your file using FindNext...and you might find where FormName is instantiated.

The quick fix, though, after making a backup copy of the file, would be to go into the code window of any Form, go to Find and Replace, under 'find' enter FormName and under 'replace' enter Form, select Current Project and hit ReplaceAll.

Linq ;0)>

 

[JHB]

..
FormName is also not the name of a control on the form or the name of the attached recordset field.
..

Do you've any backup/copy of the database that still will run with FormName without any problem, then it could be interesting if you could post a database with that form included.

 

[Guus2005]

Hi missinglinq,
I am using MZTools and Rick Fisher's Find & Replace add-ins so i am well covered in that aspect.

To reproduce:
Create a form with two buttons; Command0 and Command1

This is the code:

Private Sub Command0_Click()
    DoCmd.Close acForm, Me.FormName
End Sub

Private Sub Command1_Click()
    DoCmd.Close acForm, Me.Name
End Sub

Apparently Me.Close is not supported.

Enjoy!

 

[Galaxiom]

Apparently Me.Close is not supported.

No it isn't supported

However there is no need to include the parameters in DoCmd.Close if you are on the form you want to close because the current form is the default.

 

[The_Doc_Man]

that two men with a combined expertise of more than 30 years

At the time of this post, the only other poster was Pat Hartman, who is DEFINITELY a "she" - just as a side note!

 

[Guus2005]

:banghead:

At the time of this post, the only other poster was Pat Hartman, who is DEFINITELY a "she" - just as a side note!

@Pat Hartman, I hope i didn't offend you. I am very sorry if i did. I didn't know.

 

[JHB]

Just because no one usually uses FormName it doesn't mean that the name doesn't exist as property in the form itself.
How many have really checked up on FormName before they've answered this thread?

There are more like FormName eg. TabularCharSet.

 

[The_Doc_Man]

How many have really checked up on FormName before they've answered this thread?

I did, for one. Using Ac2010 and Object Browser's search ability, the only place where FormName showed up exactly spelled that way was under an Outlook definition set. And I had Access, Word, Excel, and Outlook libraries checked in my References list at the time of the search.

it doesn't mean that the name doesn't exist as property in the form itself

The evidence you showed doesn't unequivocally support that interpretation. In the locals window, you will see every visible item in the context of where you took the code break. Your example was taken in context of a code break in the Command0 Click Event of form Form92 in database Test. So we would see everything visible in that context.

That property appears to belong to the overall database (test) because the item above it in the list, + Form , is not expanded. If that were a form property, it would appear only when you expanded the form object. So it is NOT part of the form's properties. Damned if I know to what specific Access structure it belongs, but it doesn't belong to the form.

 

[JHB]

..
That property appears to belong to the overall database (test) because the item above it in the list, + Form , is not expanded. If that were a form property, it would appear only when you expanded the form object. So it is NOT part of the form's properties...

Do I understand what you say correctly, so FilterOn, Tag etc. is NOT the property of the form, (because they also appear in the list and not only under the +Form)?

 

[The_Doc_Man]

OK, there is that issue... the Locals window shows EVERYTHING that can be seen. So maybe I'll step back - but only a bit.

The correct way to finish this part of the question is to expand the + Form and see if FormName appears under the extended branch-line that is created by the expansion. Because the original question was "Why does Me.FormName not work?" The answer is that of the object properties and methods "gathered" under "Me" the .FormName property isn't one of them. It comes from elsewhere.

The problem with the Locals window is that in the "main" branch, you don't know WHERE that contribution originates. To say it is visible is fine, but to say that it should work as "Me.FormName" is not proved by its presence in the main Locals branch.

More than once, when looking at the Locals window, I have come to the conclusion that what we see is the result of the COM interface showing us a list of everything it thinks COULD be there without regard to whether it actually IS there.

I know you have seen this: Some items in the Locals list are shown as "<you have entered an expression that has an invalid reference to the property XYZ>" - which means the property doesn't apply to anything in the list. Yet neither you nor I t made the list of things to display, so how could we have entered an invalid reference? We couldn't.

And THAT tells me the Locals window is operating from some kind of list associated with the COM and visuals interfaces. It is interesting that it has a value and that the value makes sense in the situation - but it STILL doesn't tell us how that value got there and to what it belongs. But it doesn't belong to "Me" and that is the central issue here.

 

[The_Doc_Man]

Just to do a sanity check (no "long overdue" comments from the peanut gallery, please), I checked one of my older systems that still ran Ac2002. I keep it around for compatibility with a couple of things and I don't use it much. But it ALSO has Object Browser, Word, Excel, Outlook, etc. in the References list. Property .FormName DOES NOT APPEAR at all. No object in Ac2002, Excel, Word, or Outlook has it. So that establishes a lower boundary for when this property could have first been used.

 

[static]

Right click object browser > Show hidden members

If it's hidden you're better off not using it because it could get removed.

 

[isladogs]

Its so easy to forget the hidden members

Does anyone know how to set Show Hidden Members to be true by default?
There are some useful hidden features e.g. Balloon, WizHook

 

[Pat Hartman]

In an odd way it is reassuring that two men with a combined expertise of more than 30 years also don't know what's happening here!

Especially when one of us is a woman
I am not offended. Sorry about the Me.Close. I actually use DoCmd.Close with no form reference since I am always closing the open object. You could also use
DoCmd.Close acForm, Me.Name

I don't know if anyone asked but is the form's RecordSource being changed after the form is opened so that a recordset that includes a field named FormName is loaded?

 

[The_Doc_Man]

Colin, in the case of what we were looking at, in Ac2010 it was not hidden.

Pat, wouldn't the field name displayed in that case be bolded? Because user-defined stuff is usually highlighted to stand out from Access-defined stuff.

 

[isladogs]

Colin, in the case of what we were looking at, in Ac2010 it was not hidden.

Just to clarify what I meant....I had been following this tread wondering why I couldn't see formname listed and hadn't considered it might be just be hidden.

As for my question, it's long irritated me that I can't make the setting global and permanent. Even in databases where I have set it true and use one or more hidden items, it reverts to false when the database is reopened