Ghost Form Remains after cloning new Forms

[Guest]

I have a database which had a form frmMainDataEntry which was opened from a
switchboard form. I needed to add a different DataEntry form and Cloned
frmMainDataEntry into frmDataEntryType1 and frmDataEntryType2;
(frmMainDataEntry was then deleted).

Each of the forms have a btnReturnToMenu whose OnClick event is a macro with
only a Close action (default close being to close the currently active form).
Whenever I click the button on the cloned forms an error message appears "MS
Access can't find the form frmMainDataEntry referred to in macro expression
or VB code". I've checked every macro and can't find any reference to this
now nonexistant form, and am not using any modules. I've used the documentor
and see no reference to this form in any of the form or macro listings. I've
tried setting the macro to an explicit Close|Form|frmDataEntryType1|Prompt
and the error message still occurs.

Is there something in the form naming process that is buried inside that
transferred when I cloned the new forms? Any help would be appreciated.
(I'm using Access 2002 although the db was converted from the original in
MSA97).

Townsend37

 

[Dirk Goldgar]

I have a database which had a form frmMainDataEntry which was opened
from a switchboard form. I needed to add a different DataEntry form
and Cloned frmMainDataEntry into frmDataEntryType1 and
frmDataEntryType2; (frmMainDataEntry was then deleted).

Each of the forms have a btnReturnToMenu whose OnClick event is a
macro with only a Close action (default close being to close the
currently active form). Whenever I click the button on the cloned
forms an error message appears "MS Access can't find the form
frmMainDataEntry referred to in macro expression or VB code". I've
checked every macro and can't find any reference to this now
nonexistant form, and am not using any modules. I've used the
documentor and see no reference to this form in any of the form or
macro listings. I've tried setting the macro to an explicit
Close|Form|frmDataEntryType1|Prompt and the error message still
occurs.

Is there something in the form naming process that is buried inside
that transferred when I cloned the new forms? Any help would be
appreciated. (I'm using Access 2002 although the db was converted
from the original in MSA97).

My first inclination was to think you must have left some reference to
the original form in there somewhere, and I still wouldn't rule it out.
But first let's make sure that Access itself isn't messing things up for
you, through the operation of the nefarious Name AutoCorrect "feature".

Click Tools -> Options... to open the Options dialog, go to the General
page, and see if the Name AutoCorrect options are checked. If they are,
uncheck them all, then click OK on the dialog, and try your form again.

 

[Guest]

My first inclination was to think you must have left some reference to
the original form in there somewhere, and I still wouldn't rule it out.
But first let's make sure that Access itself isn't messing things up for
you, through the operation of the nefarious Name AutoCorrect "feature".

Click Tools -> Options... to open the Options dialog, go to the General
page, and see if the Name AutoCorrect options are checked. If they are,
uncheck them all, then click OK on the dialog, and try your form again.

My first inclination was the same as yours, that is why I went to the
documenter figuring it might print out the offending reference that I
couldn't see by looking directly at the macros. But no luck there.

I just checked the Name Autocorrect feature and it is disabled. The last
resort; completely rebuilding the 2 forms with over 60 controls/labels each
is not very appealing. Incidently, I forgot to say that after I click the
btnReturnToMenu and then dismiss the error message, the next click of
btnReturnToMenu does the job.

I appreciate your comments and hope we can find the culprit.

Townsend

 

[Dirk Goldgar]

My first inclination was the same as yours, that is why I went to the
documenter figuring it might print out the offending reference that I
couldn't see by looking directly at the macros. But no luck there.

I just checked the Name Autocorrect feature and it is disabled. The
last resort; completely rebuilding the 2 forms with over 60
controls/labels each is not very appealing. Incidently, I forgot to
say that after I click the btnReturnToMenu and then dismiss the error
message, the next click of btnReturnToMenu does the job.

I appreciate your comments and hope we can find the culprit.

Townsend

Do you by any chance have combo or list boxes on the form that have
rowsource queries -- whether stored queries or inline SQL statements --
that refer to the old form name? How about calculated controls?

 

[Guest]

Do you by any chance have combo or list boxes on the form that have
rowsource queries -- whether stored queries or inline SQL statements --
that refer to the old form name? How about calculated controls?

I checked all the controls bound, unbound, text/combo/list boxes and there
are no refs to the old form. I hadn't realized it before, but click anything
on the form, including a text control and you get the error. Dismiss the
error and you can proceed using the form as though nothing is wrong. It
almost appears that when the form is displayed on the screen by the Open Form
action of the switchboard, it isn't fully active until you click somewhere on
the form. That click instantaneously gives the error almost like it is
resulting from some sort of an 'on activate' function. I gave another look
at the switchboard macros and again don't see anything, but I believe it has
to be related to making the form the active window. The switchboard macro is
2 lines OpenForm and GoToControl. I thought the GoToControl would activate
the form if the OpenForm hadn't.

Townsend

 

[Dirk Goldgar]

I checked all the controls bound, unbound, text/combo/list boxes and
there are no refs to the old form. I hadn't realized it before, but
click anything on the form, including a text control and you get the
error. Dismiss the error and you can proceed using the form as
though nothing is wrong. It almost appears that when the form is
displayed on the screen by the Open Form action of the switchboard,
it isn't fully active until you click somewhere on the form. That
click instantaneously gives the error almost like it is resulting
from some sort of an 'on activate' function. I gave another look at
the switchboard macros and again don't see anything, but I believe it
has to be related to making the form the active window. The
switchboard macro is 2 lines OpenForm and GoToControl. I thought the
GoToControl would activate the form if the OpenForm hadn't.

Curiouser and curiouser. How about conditional formatting? Got any on
that form?

 

[Dirk Goldgar]

I checked all the controls bound, unbound, text/combo/list boxes and
there are no refs to the old form. I hadn't realized it before, but
click anything on the form, including a text control and you get the
error. Dismiss the error and you can proceed using the form as
though nothing is wrong. It almost appears that when the form is
displayed on the screen by the Open Form action of the switchboard,
it isn't fully active until you click somewhere on the form. That
click instantaneously gives the error almost like it is resulting
from some sort of an 'on activate' function. I gave another look at
the switchboard macros and again don't see anything, but I believe it
has to be related to making the form the active window. The
switchboard macro is 2 lines OpenForm and GoToControl. I thought the
GoToControl would activate the form if the OpenForm hadn't.

Here's an idea. Use the undocumented Application.SaveAsText method to
save the form and all its properties to a text file. You can do that by
entering this command in the Immediate Window:

Application.SaveAsText acForm, "FormName", "C:\Temp\FormName.txt"

(substituting the name of the form for FormName, and fixing up the
output file path to make it valid). Then open the text file
FormName.txt in NotePad or some other text editor, and search it for any
occurrence of the old form name. If you don't find it, then the problem
can't be in the form itself, but must be in a query or macro somewhere.

Unless ... I suppose there could be some sort of corruption or "dead
code" being carried around in the clones, in which case you could try
reimporting the form from the text file (using Application.LoadFromText)
and see if the newly imported form misbehaves the same way.

 

[Guest]

Here's an idea. Use the undocumented Application.SaveAsText method to
save the form and all its properties to a text file. You can do that by
entering this command in the Immediate Window:

Application.SaveAsText acForm, "FormName", "C:\Temp\FormName.txt"

(substituting the name of the form for FormName, and fixing up the
output file path to make it valid). Then open the text file
FormName.txt in NotePad or some other text editor, and search it for any
occurrence of the old form name. If you don't find it, then the problem
can't be in the form itself, but must be in a query or macro somewhere.

Unless ... I suppose there could be some sort of corruption or "dead
code" being carried around in the clones, in which case you could try
reimporting the form from the text file (using Application.LoadFromText)
and see if the newly imported form misbehaves the same way.

Thanx, its almost midnight here in EST so I'll try that in the a.m. but
first, how do I access an immediate window. I just did a search for this in
the help and drew a blank.

 

[Dirk Goldgar]

Thanx, its almost midnight here in EST so I'll try that in the a.m.
but first, how do I access an immediate window. I just did a search
for this in the help and drew a blank.

Also know (from earlier versions) as the Debug Window. Just press
Ctrl+G.

 

[Guest]

Here's an idea. Use the undocumented Application.SaveAsText method to
save the form and all its properties to a text file. You can do that by
entering this command in the Immediate Window:

Application.SaveAsText acForm, "FormName", "C:\Temp\FormName.txt"

(substituting the name of the form for FormName, and fixing up the
output file path to make it valid). Then open the text file
FormName.txt in NotePad or some other text editor, and search it for any
occurrence of the old form name. If you don't find it, then the problem
can't be in the form itself, but must be in a query or macro somewhere.

Unless ... I suppose there could be some sort of corruption or "dead
code" being carried around in the clones, in which case you could try
reimporting the form from the text file (using Application.LoadFromText)
and see if the newly imported form misbehaves the same way.

Dirk: Thanks! Pay Dirt, but not where we thought!
I did the SaveAsText trick on all the forms and found nothing. So I tried
the same thing with the macros. Lo and behold there was the offending
no-longer-existant form called out in a Condition statement. I rechecked the
mdb and found the condition occluded by the column width. The macro had to
do with a "find record" feature in the form footer. Apparently forms compile
when you first click on the form and checks for unrecognized references right
away without waiting for a macro to actually be used. I've not yet tried the
correction, but will let you know if it doesn't work. I'll have figure how
to re-write the macros so the condition refers to the "current form" rather
than a hard-coded reference. The current condition reads
[Forms]![fMainDataEntry]![FindTitleStarting]<>"". I've never been real
comfortable with the "Me" designation, would
[Forms]![Me]![FindTitleStarting]<>"" work; where Me would refer to either
form 1 or 2?

btw: I was intrigued by the text versions, they look much like the old
hard-coding of dBase or Foxbase. I noticed a few wierd entries but will
start a new thread to ask for an understanding of them.

Townsend

 

[Dirk Goldgar]

Dirk: Thanks! Pay Dirt, but not where we thought!
I did the SaveAsText trick on all the forms and found nothing. So I
tried the same thing with the macros. Lo and behold there was the
offending no-longer-existant form called out in a Condition
statement. I rechecked the mdb and found the condition occluded by
the column width. The macro had to do with a "find record" feature
in the form footer. Apparently forms compile when you first click on
the form and checks for unrecognized references right away without
waiting for a macro to actually be used.

Very interesting, and not something I was aware of. I don't use macros
for much of anything, preferring VBA code wherever possible, so my
experience with macros is limited.

I've not yet tried the
correction, but will let you know if it doesn't work. I'll have
figure how to re-write the macros so the condition refers to the
"current form" rather than a hard-coded reference. The current
condition reads [Forms]![fMainDataEntry]![FindTitleStarting]<>"".
I've never been real comfortable with the "Me" designation, would
[Forms]![Me]![FindTitleStarting]<>"" work; where Me would refer to
either form 1 or 2?

No, I can't see how that could work. "Me" is a VBA keyword, and
wouldn't be understood by a macro. I suppose you might be able to use

[Screen].[ActiveForm]![FindTitleStarting]<>""

But if it were me, I'd rewrite it as a VBA function or procedure.

btw: I was intrigued by the text versions, they look much like the old
hard-coding of dBase or Foxbase. I noticed a few wierd entries but
will start a new thread to ask for an understanding of them.

I believe the SaveAsText and LoadFromText methods were added to support
source-code control via Visual SourceSafe, but don't take that as
gospel.

 

[Guest]

Dirk: Thanks! Pay Dirt, but not where we thought!
I did the SaveAsText trick on all the forms and found nothing. So I
tried the same thing with the macros. Lo and behold there was the
offending no-longer-existant form called out in a Condition
statement. I rechecked the mdb and found the condition occluded by
the column width. The macro had to do with a "find record" feature
in the form footer. Apparently forms compile when you first click on
the form and checks for unrecognized references right away without
waiting for a macro to actually be used.

Very interesting, and not something I was aware of. I don't use macros
for much of anything, preferring VBA code wherever possible, so my
experience with macros is limited.

I've not yet tried the
correction, but will let you know if it doesn't work. I'll have
figure how to re-write the macros so the condition refers to the
"current form" rather than a hard-coded reference. The current
condition reads [Forms]![fMainDataEntry]![FindTitleStarting]<>"".
I've never been real comfortable with the "Me" designation, would
[Forms]![Me]![FindTitleStarting]<>"" work; where Me would refer to
either form 1 or 2?

No, I can't see how that could work. "Me" is a VBA keyword, and
wouldn't be understood by a macro. I suppose you might be able to use

[Screen].[ActiveForm]![FindTitleStarting]<>""

But if it were me, I'd rewrite it as a VBA function or procedure.

btw: I was intrigued by the text versions, they look much like the old
hard-coding of dBase or Foxbase. I noticed a few wierd entries but
will start a new thread to ask for an understanding of them.

I believe the SaveAsText and LoadFromText methods were added to support
source-code control via Visual SourceSafe, but don't take that as
gospel.

Thanx, for the screen.activeform clue. I've now got everything working.
Don't ya hate those gremlins that are right in front of your eyes, and you
don't see them. You said from the outset that it had to be in a macro and
you were right. Not exactly the mechanizm we expected but we learn something
every day if we keep our eyes open.

Are we having fun yet? I am !

Pete T