Results 1 to 8 of 8
  1. #1
    Access_Novice is offline Competent Performer
    Windows 7 64bit Access 2013
    Join Date
    Sep 2013
    Posts
    265

    When to use standard modules vs. class modules


    As a best practice, when is it best to use a form module (a class module right?) vs. a standard module. Can anybody give some examples please? I'm looking for some general guidelines to follow when using class modules vs. standard modules.

  2. #2
    Micron is online now Virtually Inert Person
    Windows 7 32bit Access 2007
    Join Date
    Jun 2014
    Location
    Ontario, Canada
    Posts
    12,737
    A form or report module is technically a class module, but I'd watch how you use this term as many would think you mean a module that allows you to instantiate as many objects of a class, all of which would have the same methods and properties (although not all the same property values since at least the key would have to be unique for each object in the collection). Thus I would refer to a form module as exactly that, and leave the "class" and "standard" terms out of it. As you probably know, you can only have one copy of a form/report with the same name in a db, yet you could have several class objects called dbUser (created by your custom class clsDbUser for example) so it's not the same in that respect.

    You would have to use a standard module in order to expose variables or procedures throughout the db. So if you had a function that checked a set of controls to ensure required ones had data, you would have to write this for every form that needed it if you did not put it in a standard module. Code on a form or report is not "visible" to anything else if that form/report is not open (design view not included). In addition, putting repetitive routines in standard modules is sometimes not only good practice (because it cuts down on repetition and the number of places you would have to edit if it needed tweaking) but as noted, is absolutely necessary if it has to run before any form/report is opened. A startup routine that allows/blocks user entry or determines their access level on opening would be an example where it would make sense to not rely on the opening of a form to run that code. I'm also in the habit of putting functions into standard modules if they supply query criteria because they're easier to deal with. Maybe you have to, but I can't say because I just do it that way. An AutoExec macro can only call code from a standard module because nothing is open at the time it runs.

    So those are some reasons why that I could come up with, and they all have to do with the first statement in the second paragraph. Although this was written for VB6, it has some good information on the subject. https://msdn.microsoft.com/en-us/lib...=vs.60%29.aspx
    Of particular importance might be the information on Public variables in modules and is worth considering when designing in Access too.
    Last edited by Micron; 01-01-2016 at 11:39 PM. Reason: forgot link
    The more we hear silence, the more we begin to think about our value in this universe.
    Paraphrase of Professor Brian Cox.

  3. #3
    Access_Novice is offline Competent Performer
    Windows 7 64bit Access 2013
    Join Date
    Sep 2013
    Posts
    265
    Quote Originally Posted by Micron View Post
    A form or report module is technically a class module, but I'd watch how you use this term as many would think you mean a module that allows you to instantiate as many objects of a class, all of which would have the same methods and properties (although not all the same property values since at least the key would have to be unique for each object in the collection). Thus I would refer to a form module as exactly that, and leave the "class" and "standard" terms out of it. As you probably know, you can only have one copy of a form/report with the same name in a db, yet you could have several class objects called dbUser (created by your custom class clsDbUser for example) so it's not the same in that respect.

    You would have to use a standard module in order to expose variables or procedures throughout the db. So if you had a function that checked a set of controls to ensure required ones had data, you would have to write this for every form that needed it if you did not put it in a standard module. Code on a form or report is not "visible" to anything else if that form/report is not open (design view not included). In addition, putting repetitive routines in standard modules is sometimes not only good practice (because it cuts down on repetition and the number of places you would have to edit if it needed tweaking) but as noted, is absolutely necessary if it has to run before any form/report is opened. A startup routine that allows/blocks user entry or determines their access level on opening would be an example where it would make sense to not rely on the opening of a form to run that code. I'm also in the habit of putting functions into standard modules if they supply query criteria because they're easier to deal with. Maybe you have to, but I can't say because I just do it that way. An AutoExec macro can only call code from a standard module because nothing is open at the time it runs.

    So those are some reasons why that I could come up with, and they all have to do with the first statement in the second paragraph. Although this was written for VB6, it has some good information on the subject. https://msdn.microsoft.com/en-us/lib...=vs.60%29.aspx
    Of particular importance might be the information on Public variables in modules and is worth considering when designing in Access too.
    This was very helpful. Thank you for your answer.

  4. #4
    Micron is online now Virtually Inert Person
    Windows 7 32bit Access 2007
    Join Date
    Jun 2014
    Location
    Ontario, Canada
    Posts
    12,737
    Happy to help when I can & you're welcome.
    The more we hear silence, the more we begin to think about our value in this universe.
    Paraphrase of Professor Brian Cox.

  5. #5
    Missinglinq's Avatar
    Missinglinq is offline VIP
    Windows 7 64bit Access 2007
    Join Date
    May 2012
    Location
    Richmond (Virginia, not North Yorkshire!)
    Posts
    3,016
    Another reason to place Functions in Standard Modules is that it not only makes it a snap to re-use the Functions in multiple Forms/Reports...but also in multiple databases!

    The aforementioned routines to determine user-access levels being one example...routines to re-size Forms, depending on the PC's Screen Resolution, being another that comes to mind.

    Many developers have a standard 'utilities' module that they always use; when they start a new database, they simply import the module from an existing db into the new one...no searching of Forms/Reports being necessary!

    Linq ;0)>
    The problem with making anything foolproof...is that fools are so darn ingenious!

    All posts/responses based on Access 2003/2007

  6. #6
    Micron is online now Virtually Inert Person
    Windows 7 32bit Access 2007
    Join Date
    Jun 2014
    Location
    Ontario, Canada
    Posts
    12,737
    Good point! As a matter of fact, you could create a library database and set a reference to it in your project. There are some caveats to watch out for, and I've never created one, but as long as they are standard modules, it's worth considering in the early stages of one's vb development IMHO. You can always use it as a source for copying modules into a new project if calling them from your app is not something you'd want to do.
    The more we hear silence, the more we begin to think about our value in this universe.
    Paraphrase of Professor Brian Cox.

  7. #7
    Access_Novice is offline Competent Performer
    Windows 7 64bit Access 2013
    Join Date
    Sep 2013
    Posts
    265
    Quote Originally Posted by Missinglinq View Post
    Another reason to place Functions in Standard Modules is that it not only makes it a snap to re-use the Functions in multiple Forms/Reports...but also in multiple databases!

    The aforementioned routines to determine user-access levels being one example...routines to re-size Forms, depending on the PC's Screen Resolution, being another that comes to mind.

    Many developers have a standard 'utilities' module that they always use; when they start a new database, they simply import the module from an existing db into the new one...no searching of Forms/Reports being necessary!

    Linq ;0)>
    That's a lot of good information. Thank you.

  8. #8
    Access_Novice is offline Competent Performer
    Windows 7 64bit Access 2013
    Join Date
    Sep 2013
    Posts
    265
    Quote Originally Posted by Micron View Post
    Good point! As a matter of fact, you could create a library database and set a reference to it in your project. There are some caveats to watch out for, and I've never created one, but as long as they are standard modules, it's worth considering in the early stages of one's vb development IMHO. You can always use it as a source for copying modules into a new project if calling them from your app is not something you'd want to do.
    Interesting. I will have to looking into this library database stuff.

Please reply to this thread with any new information or opinions.

Similar Threads

  1. Passing a value between modules
    By NISMOJim in forum Programming
    Replies: 3
    Last Post: 07-19-2013, 12:34 PM
  2. Where Can I Get Info On Modules
    By aamer in forum Access
    Replies: 1
    Last Post: 08-24-2012, 11:33 PM
  3. Steer me towards Modules
    By libraccess in forum Access
    Replies: 2
    Last Post: 04-10-2012, 09:01 PM
  4. Modules using Crosstabs
    By OTSeraph in forum Access
    Replies: 1
    Last Post: 02-10-2012, 10:50 AM
  5. How to use Modules
    By wasim_sono in forum Access
    Replies: 0
    Last Post: 01-16-2007, 06:29 AM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Other Forums: Microsoft Office Forums