Call Command

[Galaxiom]

Is the button on a subform?

 

[MajP]

The code, although it won't work, does compile without error.

Bad code can compile and then error. Happens all the time. That is why they are called "Runtime Errors" vice compile time errors.
Forms!AbadFormName will always compile. The syntax is correct, but the form index (its name) is wrong. These types of errors can only be found at runtime.

 

[The_Doc_Man]

Why would the action work on one form and not the other with similar code?

If I read this correctly, your problem is that having routine A call routine B which is in the class module for FormB will fail any time it references an object local to FormB IF it uses a Me. reference or a name that applies to form B. Because in that specific context, Me. refers to FormA, the caller, because the context of Me. in that case is the caller (routine A). Your case that failed is mentioned in a paragraph that begins with "In a new form" - and that means a mixed-context reference.

Me. is a shortcut to the class module associated with the active context, which is caller A based on your description of the call sequence. Things might or might not be visible in FormB depending on how they are declared - but they DO depend on what is actually loaded at the time.

 

[Dave E]

Hi Pat,

I find the forum useful most times. The last problem I had was resolved although the root of the problem was never discovered.
This time, I had chosen to use the Call Me.Command### as I'd never used it before and saw an opportunity, within my database, to try it out.
It worked well on the main form but failed on the next form with identical conditions.
I was asking if anyone had any thoughts on the issue.
As the problem involved only one small piece of code, I saw no benefit in packing up the database and posting it.

A few responses were a little off the mark and were not relevant to my problem. A few were constructive, however, and gave me food for thought on the syntax of the command used and its aims.

The method I used was correct and did work on one form but not the other. That is why I asked the question. Surely it is good to understand why a perfectly good piece of code could be problematic without any real reason. I am still investigating but have now removed the code from form 2 and replaced it with a Function call.

If a reply isn't relevant then it implies that somebody didn't read my post properly and was, therefore, not supplying a suitable response but went off on a tack that meant little to, or wasn't relevant to, my original question.

But all was not lost. I did get a positive response or two that led me towards avoiding the method I was trying and have redesigned the code appropriately.

I'm always grateful for useful help on the forum.

Happy Daze

DaveE

 

[Dave E]

Bad code can compile and then error. Happens all the time. That is why they are called "Runtime Errors" vice compile time errors.
Forms!AbadFormName will always compile. The syntax is correct, but the form index (its name) is wrong. These types of errors can only be found at runtime.

No, the form name is correct and is opened by code on other forms without a problem. I had tried several different styles of the same command without success but on the main form, it works perfectly.

 

[Dave E]

If I read this correctly, your problem is that having routine A call routine B which is in the class module for FormB will fail any time it references an object local to FormB IF it uses a Me. reference or a name that applies to form B. Because in that specific context, Me. refers to FormA, the caller, because the context of Me. in that case is the caller (routine A). Your case that failed is mentioned in a paragraph that begins with "In a new form" - and that means a mixed-context reference.

Me. is a shortcut to the class module associated with the active context, which is caller A based on your description of the call sequence. Things might or might not be visible in FormB depending on how they are declared - but they DO depend on what is actually loaded at the time.

My orginal post does indicate that the Call is self-contained within the one form. The code calls a routine on another object within the form's code.
That I was replicating a similar call on another form may have caused unintended confusion.

 

[moke123]

The code, although it won't work, does compile without error.

I looked back at a copy of your Db from a previous post. Many of your form modules have no declarations at all. When I added them in, there were numerous undeclared variables which threw errors. These types of errors can cause all sorts of problems.

 

[Dave E]

That's interesting, moke123. But that code you examined had a bug which would cause the database to close spontaneously while moving from form view to design view.
I have, on occasion, had error messages about the odd undeclared variable used in some code, but not often. Being undeclared doesn't always creat errors, it seems.
Also, bear in mind that there is no target user for this database. It's a growing experiment and a way to keep my elderly brain from waning.

The existing problem was a separate issue.

Thanks

DaveE

 

[Dave E]

Is the button on a subform?

No, the form is already open and the Call is to an existing Command button within the same form.

 

[Dave E]

Do you have Option Explicit declared in each of the modules?

Sorry I missed your post - Yes I have Option Explicit declared in each module.

 

[moke123]

That's interesting, moke123. But that code you examined had a bug which would cause the database to close spontaneously while moving from form view to design view.
I have, on occasion, had error messages about the odd undeclared variable used in some code, but not often. Being undeclared doesn't always creat errors, it seems.

Yes undeclared variables don't always create errors but when they do it causes odd error messages and sometimes causes the database to spontaneously close.