Forms with modules tend to load more slowly than forms without modules. You
do have to load the code at some point, however. I have never heard of code
in the form or report modules causing corruption. I would think that if it
were a problem, there would not be a lot of Access applications running in
the world.
My personal practice is to put form specific code in the form /report
modules and put generic code in standard modules.
Now, with that said, there is a lot of redundant code in most applications.
For example, lets say you prefer to use your own navigation buttons. You
code the events for the buttons in each form. There are a couple of
approaches to avoid that. One is to create a standard module that includes
your standard naviagation code, and call the functions form the form module.
This only required standard naming conventions. So that if you have a button
to move to the next record, it will always be named cmdNextRec. Now you have
one set of code for n number of forms. You not only save some space, but if
you need a change, you need it in only one place. Another is similar, exept
it uses a class module with sinking events.
--
Dave Hargis, Microsoft Access MVP
"RLN" wrote:
> Re: Access 2003
> I learned recently that writing all vba code out in modules and referencing
> form objects out there is better as opposed to the code residing inside the
> form object in order to protect your code if your objects should get
> corrupted.
>
> Is this a good practice?
>
> Example:
> A module called basFormMainStartup that has the forms startup code...
> vs....
> Private Sub Form_Load() (which is inside the form Load event of the object
> itself)
>
> Anyone with opinions on this?
>
> Thanks.
>
|
Similar Threads
