Query Field Selector

[SOS]

Could someone please elaborate this. I always thought Subs had to be in a module to be globally available.

I tried setting a Sub on what I assume is meant by a "form module" (Microsoft Office Access Class Object) to Public but it was still not found by other modules. (Access 2007)

If you preface it with this:

(for example if I have an event (cmdTest_Click()) on form named Test1, I can change it to:

Public cmdTest_Click()

and then call it using:

Form_Test1.cmdTest_Click


Or a module on the form -

Public Function GetMyTest()

Form_Test1.GetMyTest

 

[namliam]

Yes, you can set it public, which then allows you to call the code from outside the form... But as your sample shows you then have to call the form & function to get it running.

It is "Good practice" and a general rule... Anything public or even code that is or may not be particular to a form goes into a module!

 

[Galaxiom]

Thanks for that.

One circumstance where I thought it might make sense to call code from another form rather than in a module is where actions triggered on a main form may be duplicated by events on its subforms.

For example a Save procedure run by a button on a main form could be duplicated by moving to another record on a subform. Rather than repeating the code in the subform, the subform event would trigger the main form's Save.

If placed in a module for access by both the form and subform, the code would have to spell out the full name of the controls rather than using Me.

So the critical question is:
Does Me in a called procedure refer to the object making the call or the object that owns the procedure?

 

[SOS]

Does Me in a called procedure refer to the object making the call or the object that owns the procedure?

Me refers to the current class object that the code is being run in. So, if the code is being run as part of the subform, ME refers to the subform. If the code is on the main form, then ME refers to the main form.

 

[Galaxiom]

It is "Good practice" and a general rule... Anything public or even code that is or may not be particular to a form goes into a module! [emphasis added by Galaxiom]

I think this is overstated. There are good reasons to call a procedure from another object, such as making a main form procedure accessible from its subforms or other forms without having to use fully qualified control names as would be required in a module.

Moreover, only the called procedure needs to be made public. The subs called by the public procedure from within its own module can remain private.

It so happens I had an immediate need for this technique having baulked at translating an entire set of procedures from a form to a module when they needed to be run from another form. Instead I was able to do it with a trivial amount of code.

My problem was triggering a series of procedures already coded in another form after passing a variable into it. Had I originally expected it to need to be called from another form I would have written it for a module from the start.

But this is a much better arrangement anyway not only because Me works. It also keeps the code with the form where it acts instead of cluttering up the modules.

Once again following up on a casual "by the way" posting has opened new doors for me. The time I spend here following other contributors problems and posting where I might be able to help is much more than paid back on discoveries like this.

Thanks heaps SOS.

 

[SOS]

It is "Good practice" and a general rule... Anything public or even code that is or may not be particular to a form goes into a module!

True, but from a practical standpoint it isn't always possible. Sometimes we have to be practical where pragmatism will not serve, especially if under severe time constraints. There just simply may not be enough time to rewrite something to make is "good practice" if you have a large set of code being run on a form and you need to activate it from elsewhere. But I agree, if possible, you should try to put things in a standard module if it affects more than just the one area.

 

[namliam]

folks... Good practice and a general rule, means just that...

Dont go around finding the few exceptions where it MAY make sence...
GENERAL RULE AND GOOD PRACTICE is to.... *ugh*

Yes sometimes it makes sense to do something which in general is not a good idea... *ugh*

 

[SOS]

folks... Good practice and a general rule, means just that...

Dont go around finding the few exceptions where it MAY make sence...
GENERAL RULE AND GOOD PRACTICE is to.... *ugh*

Yes sometimes it makes sense to do something which in general is not a good idea... *ugh*

When your boss tells you that you must have something done by tomorrow, it means that choices must be made. Sometimes you can't make the good choices as there are constraints pushing things. But I think we've all had to "compromise" at one time or another simply because we couldn't get someone else to see it as important. I've had it that way many times in my career. And you can argue with the boss only so much and in the end, you have to do what he/she says regardless. So, again, I come back to the exception is still valid even though it is not necessarily good. I would love to be able to do everything according to the book all of the time, if they would only let me. But they seem to keep coming up with unreasonable requests that I can't get out of. So I must, many times, do something I would not do normally.

For those who are not so constrained - I am envious.

 

[Galaxiom]

folks... Good practice and a general rule, means just that...

Dont go around finding the few exceptions where it MAY make sence...
GENERAL RULE AND GOOD PRACTICE is to.... *ugh*

Yes sometimes it makes sense to do something which in general is not a good idea... *ugh*

Claims of "good practice" need to be substantiated with good reasons or they amount to nothing more than assertions of common practice. It becomes dogma when those who question its wisdom are warned against such enquiry and their observations trivialised by further unsubstantiated statements of faith bolstered by disparaging language.

I have always been suspicious of general rules especially when applied without concern for their foundations and believe much can be learned by finding exceptions. Indeed the exception I outlined above tells me that this general rule is intrinsically flawed or at least in need of major ammendment.

Where the code refers entirely or almost entirely to controls in a particular object it makes sense to store it in the module associated with that object.

There is nothing intrinsically wrong with making part of that code public to allow the actions to be initiated from other modules. Arbitrarily separating part of the code which acts upon controls in that module, simply because it is also called from outside, does not make sense.

Standard modules do make sense when the actions are performed on multiple objects and there is no clear association of the overall process with any particular target object. However even in this circumstance where a set of procedures are performed on an object as part of a more elaborate set of procedures on multiple objects, I would call them from a single public procedure inside the target object's module which in turn would be called from the standard module.

It makes much more sense and is far easier to follow to pass a single command to each of the object modules and have their sequences completed within that module than to send line after line of commands from the standard module.

The proper use of a standard module is when virtually identical actions are performed on different objects allowing for the code to be entered once and performed within the context of each call.

It is highly useful and perfectly legitimate to call a procedure in another object module. The general rule is a simplistic assertion that lacks foundation.

 

[namliam]

Where the code refers entirely or almost entirely to controls in a particular object it makes sense to store it in the module associated with that object.

There is nothing intrinsically wrong with making part of that code public to allow the actions to be initiated from other modules. Arbitrarily separating part of the code which acts upon controls in that module, simply because it is also called from outside, does not make sense.

This is not an exception IMHO... Making it public to call from the outside but to things on the form it is contained within is exactly what the general rule is for... You keep it there where it is needed...

The point of general rules though is that they apply to 90+% of all cases!
They dont have to match 100%...

I.e.
If you cross the road.... it is good to look left, right and left again, before crossing the road... as a GENERAL RULE... Except when your in England or the few other places where they drive "on the wrong side of the road" then you want to look Right, left and Right again... General rule.... general good practice... covering 90+% of all situations but not 100%...

I think we are debating this for the sake of debate, where we generaly agree and are nitpicking on small words and stuff...

 

[Galaxiom]

This is not an exception IMHO... Making it public to call from the outside but to things on the form it is contained within is exactly what the general rule is for... You keep it there where it is needed

With due respect this is not what you originally described as the general rule which you stated as "anything public......goes into a module"

I think it is important to be clear. As you see where I joined into this thread I had been under the impression that the only way to have a sub available from another object was to put it in a standard module.

I think this is a very common misconception and even SOS's last post appeared to imply that even though the rule could be broken under extenuating circumstances it was still best practice and one should apologise for deviating from it.

The reality is it there are good reasons to include public code in an object module and in many situations it would be best practice to do so.

 

[Galaxiom]

Forgive me for labouring the point but it is important. Access has so much opportunity for misunderstanding we need to be diligent in the detail.

It is dangerous to substitute a generalisation for a genuine rule. General rules do work at least generally. But a genuine rule is based on the phenomonon itself rather than the consequential patterns of behaviour.

Public code is most often found in standard modules but this is not because it is public. A better rule would reflect the underlying principle while a generalisation can potentially lead to inefficient structure of the code.

Code which could be reused in the same context in other objects should be located in standard modules. Mathematical functions, window positioning routines etc.

Otherwise locate the code specifically relevant to an object in the object's module. Were a series of commands in the module need to be performed from another module they should be grouped into a single public sub.

Consider simplifying all communication to an object module to clearly named high level single commands for each call. Avoid calling a series of smaller subs as this is much more difficult to manage when changes are made to the processes. It is easy to forget the context of the smaller subs beyond the module.

For example don't make calls to a form's module such as write to this box, lock that box and enable that button. Make a public function, say, EditMode(). The call then looks like Form_Formname.EditMode which is much easier to understand than a series of small adjustments.

Even if you say, had an advance edit mode for the form that enabled more features and as such was a superset of the edit mode you would have a Sub called AdvanceEditMode(). It is essential to keep the communication between modules as clear as possible.

Place all the Public subs at the top of the object's module listing so they are clearly visible. Don't hide a Public sub in the middle of your listing.

As much as possible try to perceive any sub you write in the context of the larger structure of the program and future enhancement. A generalised function passed a couple of parameters is often very little more work to write than the specific code for a particular form in a particular database.

A well written generalised version might find use elsewhere in the current project or your next.