Code behind forms or Modules - which is better? 
Author Message
 Code behind forms or Modules - which is better?

I have an application with user forms that currently uses Code behind forms
for all programming. But the forms are getting wieldy. I'm thinking about
switching to having one or more modules control the app.

Anybody have any opinions about this either way? Any code samples that calls
a module procedure from an event in a form?

Thanx

Leah



Fri, 26 Oct 2001 03:00:00 GMT  
 Code behind forms or Modules - which is better?

Quote:

> I have an application with user forms that currently uses Code behind forms
> for all programming. But the forms are getting wieldy. I'm thinking about
> switching to having one or more modules control the app.

> Anybody have any opinions about this either way? Any code samples that calls
> a module procedure from an event in a form?

> Thanx

> Leah


I wouldn't worry about putting stuff out into modules unless it is something
that can be used from several areas.  If it is form specific, I'd leave it in
the form's background code.....

--
-------------------------
| gHaD (Aaron Robinson) |
|MJM-PC Solutions, Inc. |
|      Chicago, IL      |
-------------------------



Fri, 26 Oct 2001 03:00:00 GMT  
 Code behind forms or Modules - which is better?
Hello Leah,

I avoid code behind forms as much as I can because it is real hard to
maintain.  You can put just about everything into standard modules and call
it from from the form.  If you are working with form controls you can even
use a parameter that references the control and pass it with Me!ControlName.

Matthew MacFarland

Quote:

>I have an application with user forms that currently uses Code behind forms
>for all programming. But the forms are getting wieldy. I'm thinking about
>switching to having one or more modules control the app.

>Anybody have any opinions about this either way? Any code samples that
calls
>a module procedure from an event in a form?

>Thanx

>Leah




Fri, 26 Oct 2001 03:00:00 GMT  
 Code behind forms or Modules - which is better?
When i started i noticed a retyped alot of code cause i used the function
several times in differetn fields etc :

example: after update , onchange etc....

just so you know , once you set up a specific sub that performs something ,
you can call it anywhere in the form again by just specifing it .

See the example below.
The commandbutton CheckValues is issued after clicking the button , and i
called it also after the update of field NewValue
Thus , by chnaging the CheckValues , all checks everywhere in the form will
be updated

seeyas Steve

example :

Private Sub CheckValues_Click()
dim bla bla
if bla bla then
bla bla bla
else
bla bla
end Sub
-------------------------------------
Private Sub NewValue_AfterUpdate()
CheckValues_Click
end sub



Fri, 26 Oct 2001 03:00:00 GMT  
 Code behind forms or Modules - which is better?
I think there is a case to use both.  Use more than a few standard modules
as when a single routine gets called in a certain module, ALL the scripts in
that module get loaded, thus there is a time and memory issue there.

I use form class modules for items that are specific actions on that form,
otherwise, I call a script from standard modules to do the work,
particularly, printing issues and functions.  True, sometimes, I can't
remember whether I have the routine in the forms module or standard module,
but it is easy enough to answer.


Quote:
> I have an application with user forms that currently uses Code behind
forms
> for all programming. But the forms are getting wieldy. I'm thinking about
> switching to having one or more modules control the app.

> Anybody have any opinions about this either way? Any code samples that
calls
> a module procedure from an event in a form?

> Thanx

> Leah




Fri, 26 Oct 2001 03:00:00 GMT  
 Code behind forms or Modules - which is better?
If you use code in mudules you can create lightweight forms that perform
much better than forms with a classmodule. Code in modules can be used from
any place in the MDB. I always use code in modules when possible. Only when
the form itself is creating an argument I have found this impossible - like
the usage of NotInList and BeforeUpdate events.
Look at the modules as a library of code where you put procedure with
related functionallity together.


Quote:

>> I have an application with user forms that currently uses Code behind
forms
>> for all programming. But the forms are getting wieldy. I'm thinking about
>> switching to having one or more modules control the app.

>> Anybody have any opinions about this either way? Any code samples that
calls
>> a module procedure from an event in a form?

>> Thanx

>> Leah

>I wouldn't worry about putting stuff out into modules unless it is
something
>that can be used from several areas.  If it is form specific, I'd leave it
in
>the form's background code.....

>--
>-------------------------
>| gHaD (Aaron Robinson) |
>|MJM-PC Solutions, Inc. |
>|      Chicago, IL      |
>-------------------------



Sat, 27 Oct 2001 03:00:00 GMT  
 Code behind forms or Modules - which is better?
        I have heard this claim of improved performance for separating
code from forms, but I have never seen any convincing proof of it.  If
Hans-Christian or anyone else has any, it would be good to see.  It
would also be good in answering this question to distinguish between VB
and Access environments.  
        IMHO, it would be hard to overcome the execution time costs of
calling shadow routines in the module and the maintenance costs of
trying to figure out what's happening.  Perhaps if one were a diligent
OO programmer and put business logic in the module and interface logic
in the form, the distinction would be understandable.
Quote:
-----Original Message-----

Posted At: Tuesday, May 11, 1999 5:14 AM

If you use code in mudules you can create lightweight forms that perform
much better than forms with a classmodule.



Sat, 27 Oct 2001 03:00:00 GMT  
 Code behind forms or Modules - which is better?
Most people in this newsgroup would relate their questions and answers to
Access since it is an Access newsgroup.
To test the difference between lightweight and none lightweight I suggest
you make two similar forms. One with code in the forms class module and one
with code in a module. Open the forms and calculate the time it took. This
will convince you to always use a lightweight form when possible.



Quote:
> I have heard this claim of improved performance for separating
> code from forms, but I have never seen any convincing proof of it.  If
> Hans-Christian or anyone else has any, it would be good to see.  It
> would also be good in answering this question to distinguish between VB
> and Access environments.
> IMHO, it would be hard to overcome the execution time costs of
> calling shadow routines in the module and the maintenance costs of
> trying to figure out what's happening.  Perhaps if one were a diligent
> OO programmer and put business logic in the module and interface logic
> in the form, the distinction would be understandable.

> -----Original Message-----

> Posted At: Tuesday, May 11, 1999 5:14 AM

> If you use code in mudules you can create lightweight forms that perform
> much better than forms with a classmodule.



Sun, 28 Oct 2001 03:00:00 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. Code-behind file inheriting from another code-behind file

2. Q: Code Module vs UserControl (Form, Class) module.

3. Q: Code Module vs UserControl (Form, Class) module.

4. Q: Code Module vs UserControl (Form, Class) module.

5. Network Error - corrupted code behind form Access 2000

6. Modify query using code behind forms

7. Code Behind Forms Missing in A2K

8. Too much code behind form???

9. Viewing Code Behind Forms: Unexpected Error

10. Progamatically Changing Code Behind Forms

11. Web Form & Window.Open in Code Behind

12. Passing Form Fields to VB.NET Custom Business Object in an ASP.NET Code Behind Page

 

 
Powered by phpBB® Forum Software