How do modules work?

[browninaz]

Hi everyone,

I have a real newbie question. First, let me tell you that I am learning VBA (slowly), and my question is (please don't laugh), are modules the code for a form? If they are, how do you turn them into a form? I have created this really cool and elaborate database for my business, and it works quite well for very little coding being done, but I'm at the point where I want to take it to the next level by autofilling text fields with data from another table's text fields. I know I can do it by assigning values in the forms property sheet, but there has to be a better way (I think ).

Anyways, thanks for helping people like me that don't know what they are doing.

 

[gemma-the-husky]

you can have a code module for a particualr form, or a general code module for the whole database.

the code can be used to achieve anything you require in resoonse to various form events.


generally controls on a form are filled by binding them to fields in the forms underlying recordset (easily the simplest) - but they can also be filled by running code in the form, if the first option cannot be used for some reason.

 

[Solo712]

Hi everyone,

I have a real newbie question. First, let me tell you that I am learning VBA (slowly), and my question is (please don't laugh), are modules the code for a form? If they are, how do you turn them into a form? I have created this really cool and elaborate database for my business, and it works quite well for very little coding being done, but I'm at the point where I want to take it to the next level by autofilling text fields with data from another table's text fields. I know I can do it by assigning values in the forms property sheet, but there has to be a better way (I think ).

Anyways, thanks for helping people like me that don't know what they are doing.

As Dave says, (general) modules are for code which is used by the database or several forms. The usually contain reusable utilities, API functions, global constants and variables. One thing to remember when creating general modules is that when any one function or subroutine is called by a form or report event, the whole module is loaded into memory. So it pays to plan ahead and keep the number of subs and functions in a module at reasonable limits.

The other thing: you do not need to create a general module to launch code referencing fields of tables or queries other than the one to which the form or report is bound. You can manipulate recordsets in the form's events subs and functions. If the code is used by the form exclusively, it is wise to keep it together with the form to reduce the overhead associated with calling code in modules. Same for reports.

Best,
Jiri

 

[browninaz]

Thank you both for the useful posts. I need to dig into my Access textbook and do a little research. This program never ceases to amaze me.

 

[Solo712]

Thank you both for the useful posts. I need to dig into my Access textbook and do a little research. This program never ceases to amaze me.

You are welcome !

Jiri