Page 1 of 3 123 LastLast
Results 1 to 15 of 35
  1. #1
    Uranium Lounger
    Join Date
    Dec 2000
    Location
    Los Angeles Area, California, USA
    Posts
    7,453
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Separate Modules

    I have all my macros in a global macros.dot template. When I started it without thinking, I just copied them all in one module called "New Macros". I am thinking of putting each one in it's own module, named after the macro. I miss the way I could see all the macros listed in the Organizer like I did in Word 6 & 7.

    1. Is there a downside to doing this? i.e. will having numerous modules increase the size of the template & increase loading time.

    2. I understand that I'll have to reassign toolbar buttons, shortcut keys, & macros listed in menus. Any way to shorten this, if I decide to go ahead with this project?

    Thanks in advance.

  2. #2
    Uranium Lounger
    Join Date
    Jan 2001
    Location
    South Carolina, USA
    Posts
    7,295
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Separate Modules

    I assume that you would put all of those files into the Word Startup directory so that all of your macros are available anytime you start up Word. That means that every time you start Word, it will have to open and read each of those files to create a "directory" of what is in them. Opening and reading multiple files will take a bit longer that opening and reading one file. That will make Word startup a bit slower. How much slower will depend on how many files you have and how complex they are.

    In addition, each of those files is probably going to be only very slightly smaller that the combined file, so the combined size is going to be bigger than the single file. This is probably not a big deal with the price of disk space these days.

    Other than that, I don't see any major downside.
    Legare Coleman

  3. #3
    Platinum Lounger
    Join Date
    Feb 2001
    Location
    Yilgarn region of Toronto, Ontario
    Posts
    5,453
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Separate Modules

    I went through this about 18 months ago. I'm glad I did. Today I'm still settling out my ideas. Here's where I'm at today.


    > numerous modules increase the size of the template &

    Offset by the speed of development. I use a self-built ProcedureStripper to eliminate unreferenced procedures from a completed application, and the VBACodeCleaner to eliminate bloat from a completed template (it's fantastic!).


    > increase loading time.

    I made a post about this yesterday, I think. I have anything up to 12 user-utility templates floating around my Startup folder. I wait anhything from 10 to 30 seconds to fire up the first macro. Zero after that. There was a good reply to my post but I've only just read it and forgotton the name of the respondent.


    > buttons, shortcut keys, & macros listed in menus. Any way

    I try to write my applications so that one module only holds the user-macros. This one module has a set of macros each name prefaced with "cmd_", and those macros act as cover functions for the real code, which can be built in a second module. That second module holds the real top-down logic of the application. I can do what I want in there. As long as I don't change the names of the cmd_ macros in the first module, my button-assignments remain intact. Once I stumbled on that idea I started having fun again!

    Remaining modules in any appliaction are essentially a copy of my Utils.dot. In fact, to create a new application, I just save a fresh copy of the current Utils.dot; I write the cover functions and top-level code (every utility procedure I could ever want is already present, right?!!)

    Once the appliaction is working, I use my home-grown Procedure Stripper application to remove all unreferenced procedures, and the vbaCodeCleaner (I psoted a reference to this last week) to remove bloat.

    Hey Presto! A streamlined application built on tested utility code.

    I have another chunk of code that will update modules of an application; maybe a year has gone by, I add more functionality, and want to bring in upgraded versions of Utils.DOT. The Updater copies across those modules that already exist. I reapply ProcStrip and vbaCodeCleaner and roll it out the door.

  4. #4
    Super Moderator
    Join Date
    Dec 2000
    Location
    New York, NY
    Posts
    2,970
    Thanks
    3
    Thanked 29 Times in 27 Posts

    Re: Separate Modules

    Hi Phil,

    Just on the "separate module for each macro" - that sounds like overkill. A middle way is to organize the macros into modules according to related function. And rename each module to reflect that, for ex. "modFindReplace, modPrint, modFormat" etc.

    "New Macros" is the name Word automatically assigns to a new module in a document or template, when you record a macro. You always should rename these to something different (and significant to you). Similarly, when you insert a new module, you'll get Module 1, Module 2 etc, and you should rename these to something meaningful.

    Gary

  5. #5
    Uranium Lounger
    Join Date
    Dec 2000
    Location
    Los Angeles Area, California, USA
    Posts
    7,453
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Separate Modules

    Hi Chris:

    Thanks for your ideas. BTW, I came across something that you probably already know about reducing the size of your files caused by macro bloat. The article is found here:

    <A target="_blank" HREF=http://support.microsoft.com/support/kb/articles/Q264/9/07.ASP>http://support.microsoft.com/support/kb/ar...s/Q264/9/07.ASP</A>

    WD2000: Template Size Increases When You Add or
    Remove Visual Basic Code

    To use this sample macro in a Microsoft Office application, you need to place the following code into a standard module and add a reference to the Visual Basic for Applications Extensibility library for your project. (In the Visual Basic Editor, click References on the Tools menu.)

    <pre>Option Explicit

    Sub Caller()
    ' This example assumes you are working in
    ' Word, and the project you want to work with
    ' is the first file in the collection.


    ' For Word use:
    FixProject Documents(1)

    ' For Excel use:
    ' FixProject Workbooks(1)

    ' For PowerPoint use:
    ' FixProject Presentations(1)

    End Sub


    Sub FixProject(Doc As Document)
    ' Word

    'Sub FixProject(Doc As WorkBook)
    ' Excel

    ' Sub FixProject(Doc As Presentation)
    ' PowerPoint

    Dim iStdMod As Long, iClsMod As Long
    Dim iFrm As Long, iDesn As Long
    Dim iDoc As Long, n As VBComponent
    Dim i As Long, fname As String

    Debug.Print "before=" & FileLen(Doc.FullName)

    For Each n In Doc.VBProject.VBComponents

    ' The vbext_ct_StdModule type is
    ' only one of several VBComponent
    ' clause for each component type:
    ' (for example: module, form, class, etc)
    Select Case n.Type

    Case vbext_ct_StdModule
    Debug.Print "exporting " & n.Name
    n.export "C:" & iStdMod & ".bas"
    Doc.VBProject.VBComponents.Remove n
    iStdMod = iStdMod + 1

    Case vbext_ct_ClassModule
    Debug.Print "exporting " & n.Name
    n.export "C:" & iClsMod & ".cls"
    Doc.VBProject.VBComponents.Remove n
    iClsMod = iClsMod + 1

    Case vbext_ct_ActiveXDesigner
    Debug.Print "exporting " & n.Name
    n.export "C:" & iDesn & ".dsr"
    Doc.VBProject.VBComponents.Remove n
    iDesn = iDesn + 1

    Case vbext_ct_MSForm
    Debug.Print "exporting " & n.Name
    n.export "C:" & iFrm & ".frm"
    Doc.VBProject.VBComponents.Remove n
    iFrm = iFrm + 1

    Case vbext_ct_Document
    ' This type of VBComponent will
    ' always re-import as a Class module.
    ' The original object association is
    ' removed when importing/exporting.
    Debug.Print "exporting " & n.Name
    n.export "C:" & iDoc & ".cld"
    iDoc = iDoc + 1

    End Select

    Next

    ' Save document now that all
    ' VBComponents have been exported.
    Doc.Save
    fname = Doc.FullName

    'Close the file
    Doc.Close

    Set Doc = Documents.Open(fname)

    If iStdMod Then

    For i = 0 To iStdMod - 1
    Doc.VBProject.VBComponents.Import "C:" & i & ".bas"
    Kill "C:" & i & ".bas"
    Next

    End If

    If iClsMod Then

    For i = 0 To iClsMod - 1
    Doc.VBProject.VBComponents.Import "C:" & i & ".cls"
    Kill "C:" & i & ".cls"
    Next

    End If

    If iDoc Then

    For i = 0 To iDoc - 1
    ' This VBComponent is imported
    ' as a Class module. You will need
    ' to copy its code into the
    ' appropriate ThisDocument, Workbook, etc.
    Doc.VBProject.VBComponents.Import "C:" & i & ".cld"
    Kill "C:" & i & ".cld"
    Next

    End If

    If iDesn Then

    For i = 0 To iDesn - 1
    Doc.VBProject.VBComponents.Import "C:" & i & ".dsr"
    Kill "C:" & i & ".dsr"
    Next

    End If

    If iFrm Then

    For i = 0 To iFrm - 1
    Doc.VBProject.VBComponents.Import "C:" & i & ".frm"
    Kill "C:" & i & ".frm"
    Kill "C:" & i & ".frx"
    Next

    End If

    ' Save document now that all
    ' VBComponents have been exported.
    Doc.Save
    Debug.Print "after=" & FileLen(Doc.FullName)

    End Sub </pre>


    Perhaps you may find this useful.

  6. #6
    Uranium Lounger
    Join Date
    Dec 2000
    Location
    Los Angeles Area, California, USA
    Posts
    7,453
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Separate Modules

    Hi Legare:
    They're all in 1 template so the question is more 1 module versus many for the macros. I think I'll compromise & use Gary's suggestion. Thanks for your input.

  7. #7
    Uranium Lounger
    Join Date
    Dec 2000
    Location
    Los Angeles Area, California, USA
    Posts
    7,453
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Separate Modules

    Hi Gary:

    Thanks for your input. I guess that's what I'll do. My only reluctance is that I was wishing I could have the convenience that I had with Word Basic where I could readily read & copy individual macros with the Organizer.

  8. #8
    Super Moderator
    Join Date
    Dec 2000
    Location
    New York, NY
    Posts
    2,970
    Thanks
    3
    Thanked 29 Times in 27 Posts

    Re: Separate Modules

    You don't have the convenience of copying separate macros via the Organizer, but if you have grouped your macros into separate modules according to related function, it is a very easy matter to copy modules from one template or document into another. Your choices include:

    - export the modules as .bas files and import into the other template
    - have both templates open and in the VBE drag and drop modules from one template to another (this performs a copy)
    - (as Chris Greaves pointed out to me) it's not too hard to automate copying modules via code.

  9. #9
    Super Moderator
    Join Date
    Dec 2000
    Location
    New York, NY
    Posts
    2,970
    Thanks
    3
    Thanked 29 Times in 27 Posts

    Re: Separate Modules

    Phil,

    Actually, Chris had already posted this - including a link to a free downloadable code cleaner utility.

    I'd tried this utility once last year and didn't find it made much difference; but since Chris' rave writeup I figure I have to try it again.

    Gary

    PS: Thanks though for your post; now we know what the source code behind the one from Payne probably looks like[img]/w3timages/icons/devil.gif[/img]

  10. #10
    Uranium Lounger
    Join Date
    Jan 2001
    Location
    South Carolina, USA
    Posts
    7,295
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Separate Modules

    I misread what you were saying. When you said module, I guess I assumed you were going to put those in separate files. I also group my code into modules of similar functions. Not one per procedure, but groups.
    Legare Coleman

  11. #11
    Super Moderator jscher2000's Avatar
    Join Date
    Feb 2001
    Location
    Silicon Valley, USA
    Posts
    23,112
    Thanks
    5
    Thanked 93 Times in 89 Posts

    Code cleaners

    What happens to custom toolbar buttons and menu entries when the VBA modules are (temporarily) deleted?

    Sign me, paranoid.

  12. #12
    Super Moderator
    Join Date
    Dec 2000
    Location
    New York, NY
    Posts
    2,970
    Thanks
    3
    Thanked 29 Times in 27 Posts

    Re: Code cleaners

    I'm sure it's a healthy paranoia based on loads of real-life experience!

    In this case though (based on having tried this all of once) there aren't any ill effects: all of the custom items contain a 'path' to their empowering macro.

    - When the macros/modules are taken away and then restored back to their original places (and with their original names), the custom items can trace back down the path with no problem.

    Now, what bugs me (alluded to I think in Phil's original post), is that merely changing the name of the macro or module, is enough to break that path.
    Clearly Word is storing that path information somewhere* - why isn't it exposable via the user interface or via code so that we can control and/or automate this very common process?

    *Of course, that 'path' information is available initially, when for instance you drag a macro item onto a custom toolbar or menu - initially the "Name" property will be the location and name of the macro. But as soon as you rename it to something comprehensible to the user, that original information is gone.

  13. #13
    Platinum Lounger
    Join Date
    Feb 2001
    Location
    Yilgarn region of Toronto, Ontario
    Posts
    5,453
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Separate Modules

    Yupper. I know EVERYTHING! hah hah. That explains why I'm here, right?



    OK. This code is going to reduce bloat. There is already an excellent item out there, and I posted the web link a couple of weeks ago. <A target="_blank" HREF=http://www.payneconsulting.com/freestuff.htm>http://www.payneconsulting.com/freestuff.htm</A>

  14. #14
    Platinum Lounger
    Join Date
    Feb 2001
    Location
    Yilgarn region of Toronto, Ontario
    Posts
    5,453
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Separate Modules

    I had <A target="_blank" HREF=http://www.vif.com/users/cgreaves/modmn.html>http://www.vif.com/users/cgreaves/modmn.html</A> the Module Manager which was my first attempt at a translation of module management from Wordbasic to VBA. The above url is just to a brochure. No d/l there.

    Then I developed ProcedureStripper whose main purpose was to sniff out un-referenced procedures in a template. i got carried away and it now sorts procedures alphabetically in each module, updates existing modules form other templates (handy when you have "libraries" of code in templates, and so on.

  15. #15
    Platinum Lounger
    Join Date
    Feb 2001
    Location
    Yilgarn region of Toronto, Ontario
    Posts
    5,453
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Separate Modules

    You'll see the most difference if you've performed much editing on a template. It's a parallel effect to the "fast Save" (Sloooow Load) in Word.

    Try it again on a template which you edit daily, or a template that's been around a long time and suffered much change. For those of you who INSIST on storing and removing macros from Normal.dot, Normal.dot would make a good candidate. I was going to write "If you're lucky you'll lose your Normal.Dot and make a fresh start and never use it again for storage", but truth is that Payne Consulting has NEVER lost a single line of my code.

Page 1 of 3 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •