Whats the correct way to call an event procedure?

[Mendel]

I'm fairly inexperienced with VB and Access so I'm struggling to find a way to do this. I know that I can create a function in a module and then call that function in an event procedure. That's all well and good but what is the correct procedure to do the reverse? I want to create a macro that uses the RunCode Action for a function in my module to call a sub from a form's event procedure.

Access Help File says this:
Tip To run a Sub procedure or event procedure written in Visual Basic, create a Function procedure that calls the Sub procedure or event procedure. Then use the RunCode action to run the Function procedure.

My Sub in the event procedure is called:
Public Sub ChangeSwitch()

and I wrote this function in a module:

Function CallChangeSwitch()
Call ChangeSwitch
End Function

I get the following error:
Sub or Function Not Defined

What am I missing or doing wrong? Access says I can do this but I'm not doing it correctly. Any help would be tremondously appreciated. Thanks.

 

[Atomic Shrimp]

I think I've got this right...

The code that is attached to a form (a class module) is designed to be executed when certain events happen to that form or controls on it, the code is only available to be called from that same form (even a 'Public' sub or function in a class module is only public to that form)

If you want to call code from elsewhere (from outside the form), you need to put it into a standard module, which you can create in the 'modules' tab of your database. A public sub or function in a standard module can be called from anywhere.

HTH

Mike

 

[Fornatian]

Mike is right - although is possible to call other form functions from a form it is widely accepted as best practice to put all code to be shared between forms in general modules.

I always think of it like file management. If I use a file all the time and no-one else needs it, I keep it on my machine(in my form code), if other people need to use the file I put it on the network(the general modules).

Keeping 'stuff' in shared files prevents duplicating code and better management if errors occur.

What you need to bear in mind is that if you export/import the form to other databases it will only take it's own module with it and not those that it needs to carry out the referenced functions.

HTH

Ian

 

[Mendel]

Thanks both of you. I see it now.