I'm getting a compiler error even though the sub is defined

[Seth Schrock]

I have created a subroutine that is declared as public in one of my form modules. In another form module I am trying to call it. However, when I try to compile my code, I get an error that says Sub or Function not defined.

I'm calling it like this:

Call InOutStatus

And it is declared like this:

Public Sub InOutStatus()
 
End Sub

When I actually run the code, it works fine. Why am I getting a compiler error?

Note: By form module, I mean the object that gets created in the Microsoft Access Class Objects group in the VBA editor whenever you create an event in the form. I'm not exactly sure what to call it, so I chose form module.

[NeoPa]

Form Modules, while visible to all code, are not General Modules, so need qualification when referred to. The code should read :

Call Form_frmYourForm.InOutStatus

or (only if the form is open) :

Call Forms("frmYourForm").InOutStatus

Alternatively, it is very unusual for code from a specific form to be called from outside of that form. It normally (Though not necessarily) indicates the procedure is in the wrong place.

[Seth Schrock]

That did it. Even though during normal use the called form will be open, I went ahead and used your first option so that if I ever need to do some troubleshooting on the calling form, I don't have to worry about making sure another form is open.

Thanks NeoPa!

[ADezii]

Just some useless information. A Sub-Routine defined within a Form's Class Module is essentially a Method of that Form, ergo the

Form.Sub-Routine 

Calling Syntax.

[Seth Schrock]

I wouldn't call that useless information. It helps it make sense to me of why. Thanks ADezii.

[NeoPa]

I agree Seth. It's not remotely useless :-)

Oh, and BTW you're welcome to the assistance.

[NeoPa]

I forgot to mention earlier that there is another strange issue that comes up every now and again where the compiler seems to get its knickers in a twist and complains about something not being there, when clearly it is. I've found that by cutting the declaration code out, then pasting it back in again, the compiler seems to come to its senses and again recognise that it actually exists. Don't worry about this if your issue is already fixed, but for any others reading this thread where nothing else has worked, this simple fix is always worth a try.

[TheSmileyCoder]

If your code is acting "weird" (yes that really is the best word I could come up with) then I have found its often a matter of in-consistent compilation, the cause of which is usually editing "live/running" code. Don't ever do that!

I have found it often helps to decompile the application:
http://bytes.com/topic/access/insigh...-fresh-compile

[TheSmileyCoder]

Note that forms are a class, and that YOUR form is a sub-class of forms. Thats why you can use the following:

Dim frm as Form_YOURFORMNAME
Set frm=Forms("Form_YOURFORMNAME") 'Only works if open

Now you might wonder what the benefit of this would be. The clear benefit is that you actually get intellisense of the controls in the form. Just like you can do Me. to show (among others) controls in your form, you can also now do frm..

[NeoPa]

Smiley:
Don't ever do that!

Indeed. I appreciate the potential problems involved. I actually do do it regularly myself, but I have procedures I follow which ensure this problem doesn't occur with me any more (At least I can't remember it happening for ages and ages so I assume they're reliable). Nevertheless, I have kept up with the linked thread and, in general, would advise members similarly (to your quoted comment that is. Avoid it like the plague).

Nevertheless, I still remember it happening and I can't assume that everyone has avoided the problem just because we have Smiley, hence the idea to post my quick fix (which essentially flags the code as not compiled, just as a specific decompilation would).

Smiley:

Dim frm as Form_YOURFORMNAME
Set frm=Forms("Form_YOURFORMNAME") 'Only works if open

I found, in A2003, that it could be run, and does work, whether the form is open or otherwise. However, it causes the form to stay loaded (if not necessarily open) if an attempt is made to close it while your code still has any active references to it. Similarly, it will cause the object to be loaded if your code runs at a time when it is not already loaded.

In most cases this will not be an issue, but I have fallen over it myself when dealing with all the forms in a database with (literally) hundreds of them to process through. My process crashed complaining of lack of resources, as I recall. Tidier code was required once I appreciated what was happening.

Anyway, I digress. I just wanted to add the Government Health Warning (that I should have added earlier when I first introduced the idea into the thread.), in case anyone saw it and decided to use it more extensively.

BTW Smiley's point about all forms and reports being classes in their own right, which are simply derived classes from the main classes Form and Report that all Access databases have, is absolutely right and can be an important point to be aware of.

[TheSmileyCoder]

I will admit to doing it myself once in a while (Editing live code) but I do try to steer clear of it, since I know and realise the potential issues involved. It sometimes feels like that "game" boys played as kids, who could hold their hand over the flame the longest without getting burnt. Its fun and games, but well, every once in a while somebody got burnt!

The decompilation however will affect all modules, where your fix only affects a single module at a time.

Also remember that you can safely modify values during breakmode, by using the immediate pane. That can be quite usefull, to more quickly try out different scenarios.