Whether to code in a form module or a standard module? (1 Viewer)

Banana · Dec 14, 2007

I'm wondering how other members here make decisions whether they want to place codes behind form or use a standard module instead.

I understand there is a performance penalty when you add another module (and use it), but am not sure whether one big fat module would be faster than several smaller modules with identical coding.

Furthermore, I know that some members use a hidden form to deal with startup and shutdown processing. Sometimes the processing has nothing to do with forms and would make more sense in a standard module, but since the form is already loaded, does it makes more sense to use the module behind the form than calling a function in a separate standard module to execute the needed code?

So, what do you tend to do in such situation?

CraigDolphin · Dec 14, 2007

I don't apply any rational process to the decision except that Public Functions and Variables all get thrown into separate Modules so they can be accessed from any form and I can more easily find them again if I want to make changes.

I've never even known about, or even considered, performance issues in this area so I will be reading the rest of the replies with interest!

boblarson · Dec 14, 2007

I normally place any form processing on the form module and anything I need to be reusable and/or available from multiple places in a standard module.

Banana · Dec 14, 2007

Craig, this is quite a sensible thing to do and I'd do that myself. I just learned about the performance differences myself, and it happened that I had a hidden startup form where I want do processing, but wondered what if I needed to make some of that code public?

Bob, I would like to be a bit pedantic and ask-

Do you just have one big fat module for all public procedures?

boblarson · Dec 14, 2007

Banana said:
Do you just have one big fat module for all public procedures?

It all depends on the project, but normally I will separate out and have one module for utility functions and then it all depends on the number of others by what type of functions it is.

Banana · Dec 17, 2007

I had asked this because I was not sure how I wanted to handle using a startup form to do some startup code but also needed parts of this publicly accessible.

That said, the solution I found was to make it lightweight and place all of my startup/shutdown codes in a standard module, then in appropriate form's event, call a public function. The end result is just one module (instead of two modules, one for the form's events and another for publicly accessible codes).

pbaldy · Dec 17, 2007

I do the same thing Bob does; if I will only need something in one form, I'll make it a sub/function in that form's code. Otherwise it goes in a standard module.

I will make more than 1 standard module if I have a lot of functions, and I'll group them by something logical (AR functions, parts functions, etc). I doubt I have an application with more than 4 or 5 standard modules though. While there is a theoretical performance hit for each module, I doubt it's noticeable, maybe not even measurable. I've certainly never noticed one, though I've never tested a "one big module vs several small modules" scenario.

Simon_MT · Dec 18, 2007

I would only use Modules. It does matter whether or not there is a re-usability issue or not. All your VBA code is in one place. I started doing this after reading that Forms and Reports perform better without their own Modules. Whether or not this is true, I find the Modules very adaptable and transportable, they are so much easier to find and it instils I have become more disciplined.

I prefer to many many Modules and to organise them, its easier to get to within Expression builder. A use quite a few so the list of Function is substantial. In most Modules I also use Private Functions for the internal calls within a Public Function.

The one thing I discovered was With CodeContextObject, no hard coding the Current Form or Report just preface the control with a dot rather than me me me!

I got the server down doing some diags on some faulty memory - so I have no mail at the moment but I put humpty dumpty back soonish! Bloody thing.

Simon

Banana · Dec 18, 2007

Simon_MT-

Just curious-

When you use form's module, there are some parameters given. Let's take BeforeUpdate for example:

Code:

Private Sub Form_BeforeUpdate ([b]Cancel As Integer[/b])

Emphasis mine. If we use a lightweight form instead, and called a function, how would you handle the event when you do not want to complete (e.g. we don't have sufficient information to proceed forward with the updates and need to cancel the event).

Also, how is CodeContextObject (first time I heard of this) is better than a Form or Report object? I could just pass the Form object and refer to it all I want?

Simon_MT · Dec 18, 2007

I would put this is the relevant Sections Module as:

Function Section_Form_BeforeUpdate

I have Stock records they can be on any Form or Subform so anywhere a Stock Record can be found there is appropriate Function call to:

Code:

Function Artists_ImagesOriginalsEntry()

    With CodeContextObject
        If IsNumeric(.[Orig Old Stock]) Then
            Call PricesReveal
            DoCmd.OpenForm "Originals Images Review", acNormal, "", "[Orig Old Stock] = " & .[Orig Old Stock], , acWindowNormal
        End If
    End With

End Function

Simon

Banana · Dec 18, 2007

I'm sorry, but I'm not sure I understand how this will allow an event to cancel or fail?

Simon_MT · Dec 18, 2007

I wasn't being specific to an Event cancel or fail. The difference between the two approaches is a Sub or a Function and it then boils down to naming conventions within the Module. Your Sub

Code:

Private Sub Form_BeforeUpdate (Cancel As Integer)

could be called:

Code:

Function FormWhatever_ControlWhatever_BeforeUpdate (Cancel as Integer)

All you have to ensure is that each Function retains a unique name.

Simon

Banana · Dec 18, 2007

It's very possible that it's *me* who's muddling the water, but I was concerned because I think that Cancel (and other arguments associated with certain events) are derived from Access itself and does much more than if I just created a custom Cancel As Integer... Is that not the case?

ChrisO · Dec 18, 2007

Well it seems like a good question so here’s 2 cents worth from me…but that’s all it is.

Until such time that speed becomes a problem, don’t even bother to consider it. Most of the discussions of execution speed I see these days are based on the past…but things have changed. Often the argument boils down to “If you want your car to go faster then empty the ashtrays.”

If we remove the speed argument we are left with style. Style is not an ‘always do it this way’ or ‘always do it that way’ but in trying to understand the reason for the style at any particular moment.

Think lazy…think reusability and maintenance.

If we have code that serves only one form, perhaps a splash screen, then it seem logical to place the code in the forms class module. If we do it like that then both the Form and its class module are more portable.

However, if we have a global error handling routine then it makes more sense to place that in a standard module of its own. Again, it makes it more portable and reusable.

As I see it, we should try to funnel code through a single procedure that will produce the single result we require. If we do that then we can make changes, fix bugs and report errors more accurately in one and one only place.

So, if we are not all that familiar with code we can look upon the question from the point of database normalization. Try not to define anything in more than one place and try to keep the procedures atomic (they do one and one only thing).

But if the code can only serve one master then bind it to its master…it makes the master more portable.

Think lazy, however… it does take some effort to be lazy.

Hope that makes some sense.

Regards,
Chris.

boblarson · Dec 18, 2007

Well said, Chris, well said.

Banana · Dec 18, 2007

Chris, I love your car top speed & ashtray analogy!

Pretty accurate for several "optimizations."

That said, the main reason why I asked this question was more because I was sort of stumped about how I wanted to place my code which would primarily deal with managing ODBC datasources and network connection automagically. I originally placed them behind a form's module as I wanted to do some routines on startups and shutdowns and used that form as a startup form and made it so that it should be always be the last form. But Startup/Shutdown processing wasn't the only thing I wanted to do- I wanted to be able to access some routines, perhaps to verify that the connection is still alive for example. Therefore, I needed it to be publicly accessible to anything else in my database.

Thus, my solution of using a lightweight form referencing a standard module, and in my case, this should work as I really don't need to issue any Cancels, although Simon_MT's premise of not ever using Form Modules piqued my curiousity for such circumstances.

ChrisO · Dec 18, 2007

G’day Banana.

I can’t detect a question in your reply.

If you are talking about code that must run then please don’t try to do it at shutdown…there is no way to guarantee a shutdown sequence. Code that is required to run must be run as close as possible in time before the functionality that requires it. Example, if you need to ‘clean’ a database before running some function then clean it before running the function…not after it.

If you were asking me if what ‘Simon Said’ is correct then I would have to respond by not following what ‘Simon Said’.

But Simon may have a point and simply hasn’t stated it clearly yet.

Regards,
Chris.

Banana · Dec 18, 2007

Chris, my apologies for obsfucating the question. There are two questions, one which I think I've already answered, and one other, which was prompted by Simon's idea. Here this go:

Question 1:

If I had a piece of code where I wanted to run on both startup Form's Load Event and Unload event (having assured that it is the last form to close) but has some routines that needs to be publicly accessible?

The answer to that was to use a lightweight form and instead of writing a code in form's module, call a public function. This way everything stays in one module but is just as accessible from form's event.

Simon then added that he doesn't use form modules ever calling everything from a standard module, so all of his forms are lightweight, if I understood him correctly.

I then asked another question, more or less directed to Simon (but open to anyone else who may know the answer):

If a lightweight form was used, and you called some function for certain events, would you be missing out in some builitin functionality if you had created a Event Procedure?

For example, when we create a event procedure with say, BeforeUpdate, we're given a Cancel As Integer where we can set it to True to prevent the BeforeUpdate event from complete. While I am sure we can do something similar in a public function call, I do not know whether there may be more going under the hood that would be missed when using custom Cancel and the likes?

I hope that helps clear things up.

ChrisO · Dec 19, 2007

G’day Banana.

Well I think it’s up to you to decide where best to put the code.

One way of doing it would be to keep the code, which is only used by the Form, behind the Form and place the ‘multi-user code’ in a standard module.

As for missing out on some of the functionality when using light-weight forms…
You should be able to Cancel any event that can be Canceled by using DoCmd.CancelEvent in the Public Function called to handle the event.

However, other events will become more difficult (If not impossible) to handle. Consider: -

Private Sub Form_MouseMove(Button As Integer, Shift As Integer, X As Single, Y As Single)

If we try to handle that event in a light-weight Form from where do we derive the arguments?
Now we could try to use API calls to get the arguments but why?

I would simply suggest trying several ways and see which best suites your needs.

Regards,
Chris.

Whether to code in a form module or a standard module? (1 Viewer)

split with a cherry atop.

GrumpyOldMan in Training

Smeghead

split with a cherry atop.

Smeghead

split with a cherry atop.

Wino Moderator

Registered User.

split with a cherry atop.

Registered User.

split with a cherry atop.

Registered User.

split with a cherry atop.

Registered User.

Smeghead

split with a cherry atop.

Registered User.

split with a cherry atop.

Registered User.

Similar threads

Users who are viewing this thread