Updating a .bas file within the Normal.dot template in Word? 2

[acribb]

I have been maintaining a large macro within my workplace. It is basically a find and replace macro that let's the users easily create client documents. It is housed within the Normal.dot template and contains a "MyName" module and "AcctMgr" module. I have just completed an upgrade and I simply want to replace the "AcctMgr" module with a new one. Replacing the whole Normal.dot file just causes too much pain for the person to have to go into the module and then re-update their name in the "MyName" code.. I can successfully import the module, but it does not overlay the existing "AcctMgr" module as I hoped it would. The new module just gets added as "AcctMgr1". I plan on distributing this through a document where they can just press PF2 to update...

How can I first remove the existing "Acctmgr" .bas module, and then re-add my new one?

Here is what I have so far (and where I am stuck at (????)):

Sub Updateacctmgr()

'Export Module1 from Normal to a BAS file
'VBE.VBProjects("Normal").VBComponents("Acctmgr").
' FileName:="C:\My Documents\acctmgr(03.21.05).bas"

NormalTemplate.VBProject.VBComponents.Remove (????)

'Import the BAS file into Normal.
NormalTemplate.VBProject.VBComponents.Import _
FileName:="G:\CP\AcctMgr\Acctmgr.bas"
NormalTemplate.VBProject.VBComponents.Import _
FileName:="G:\CP\AcctMgr\frmClientInfo.frm"

MsgBox "Your Account Manager Has Been Succesfully Updated", 64, "Account Manager"
MsgBox "Have A Nice Day.", 48, "Account Manager"

End Sub

Any help is greatly appreciated.....

 

[PCLewis]

You will need to note the KB article and change your security settings which could be unwise. Many viruses will do what you are proposing to do. Replacing code in normal.dot is one of the easiest ways to propogate a malicious piece of code.

Sub test(bAdd As Boolean, bRemove As Boolean)
Dim x As Variant 'NormalTemplate.VBProject.VBComponent

If bAdd Then
  NormalTemplate.VBProject.VBComponents.Import FileName:="c:\test1.bas"
End If

If bRemove Then
  For Each x In NormalTemplate.VBProject.VBComponents()
    If x.Name = "test1" Then
      NormalTemplate.VBProject.VBComponents.Remove x
      Exit For
    End If
  Next
End If

'[URL unfurl="true"]http://support.microsoft.com/kb/q282830/[/URL]

End Sub

 

[mintjulep]

I suggest housing your code in its own dedicated .dot file located in the startup directory for Word. I have found trying to maintain special things in the normal.dot file to be a pain.

This is simpler too. Updates can be distributed in a .doc file. The core "installation" code that I have used is

Static Sub MakeDot()

StartupPath = Options.DefaultFilePath(wdStartupPath)
 
    ActiveDocument.SaveAs FileName:= _
        StartupPath & "\User_Tools.dot" _
        , FileFormat:=wdFormatTemplate, LockComments:=False, Password:="", _
        AddToRecentFiles:=flase, WritePassword:="", ReadOnlyRecommended:=False, _
        EmbedTrueTypeFonts:=False, SaveNativePictureFormat:=False, SaveFormsData _
        :=False, SaveAsAOCELetter:=False

System.PrivateProfileString(FileName:=Options.DefaultFilePath(wdStartupPath) & "\tools.ini", Section:="Version", Key:="Version") = CurrentVersion()

MsgBox ("Success!" & Chr(13) & "Close and Restart Word")
  ActiveWindow.Close
  End
End Sub

---------------

Public Function CurrentVersion()
CurrentVersion = 2.5
End Function

I check for the version in the .ini file first, to avoid installing an earlier version.

 

[acribb]

Thanks for all the tips!

The macro works as having a name, title, phone number, and email address built into it's own module called MyName within the normal.dot template. It also has another module, called Acctmgr which basically displays forms and such that people can enter input information through. After the user enters in the info into the forms, the application does a find and replace on all the variables within a Word 'template' the forms point to. The 'MyName' module houses everyone's own individual id information to have a 'from' address within the documents which will be sent out to the clients.

Initially, up until now, my method of distribution of any macro updates (we're always adding more templates and new features), was to simply store the normal.dot file out on the network, and then email instructions to the users on how to copy and paste the normal.dot file into their Office10, Office11, or Templates folder, depending on what version of Word they were running (even though most people, but not all, are running Word 2003). The user would then have to go into the VB code window and into the MyName module and manually overtype the generic identification info with their own, and then close out of Word. The button resides on a toolbar in Word. As you can imagine, non-technical people seeing code and such is a little hard for some, and i'm tired of having to help everyone everytime there is a new update.

I was opting for the method of 'remove' and 'add', simply so they would not have to do the little coding dance of re-adding their name every time there is an update.

I'd like to be able to somehow code this up in it's own .dot file, and when I send out updates, have an initial setup screen where the user can enter in their name, email, phone, etc and then have that somehow store to the Module within the template. I'm just not sure how to do this or if it's even possible. Is it possible to write a form that takes the information and fills in code within a module? Thanks again for any further help you can lend...

 

[fumei]

mintjulep is right on.

I have written a full five day course on advanced Word VBA. Just Word (Ok a little on the other apps, but very little). The very first thing I start people off is creating their own home for their code. Module 1 of the course deals with having a proper home for your code and/or autotext.

The number 1 troubleshooter method is to delete normal.dot. If this contains weeks of well written properly debugged code...lossing it because some network overwrote it - annoying.

Unless it is absolutely required - and IMHO that is very very little - evrything should be outside normal.dot. Even Microsoft advises this. They even state why - normal.dot gets corrupts easiliy. The amount of I/O is very high, and more I/o, more chance of errors.

Simply put, important and crucial code should not be in normal.dot. Distribution is not really a factor anymore, and having well design code files make up-dates easier, and each can be loaded as a global code file as either automatic startup (regardless of the instance of Word), automatic startup associated with another template, or as needed beither a specific file, or manually _ gee I need THAT code file. You can even call procedures across them

Why use normal.dot? It should be kept clean, lean...and alone.

Oh, re distribution. It can be sent out as a .Doc file, with Document>open code that uses organizer to move modules or styles (as....styles) to either document or existing templates(.DOT) on that machine...including the local normal.dot.

Gerry

 

[acribb]

Ok, so I put the code in it's own .dot file. It still leaves me with the problem that every time I update it, the user is going to have to go into a code window to edit their personal information. Is there any way around this so the user can have a nice pretty form to enter in their information, which will ultimately be stored within the code in that MyName.bas module? This is an important piece to the Macro which allows the user to not have to enter in their name, address, phone number, email, etc., every time they want to push out a document to a client. I guess the possiblity of storing a Word document on each user's individual machine containing their contact information is a possiblity, but what if that gets deleted, or moved from the location, etc...

Any ideas?

Thanks again.

 

[combo]

Why not use two modules, one with code, replacable, and the second to keep variables with local data?

combo

 

[mintjulep]

You can write the user information to a .ini file, or to the registry.

I would suggest the .ini.

Easy to make a form to facilitate entering this.

 

[acribb]

mintjulep:

Can you elaborate on the .ini idea? It sounds good, but more details or examples would be better. Where should I store the .ini file on the user's computers? When I send out more updates just have the new form overwrite the old .ini file out there?

Thanks again....

 

[mintjulep]

.ini files are simply text files that can be used to store assorted tidbits of information following a prescribed format. The file can be broken into sections, and each section can have multiple keys. Each key has a value assigned. Their use is well described in the VBA on-line help. The line starting with "System.PrivateProfileString" in my example code above writes the version number to the file tools.ini.

I write them to the user's startup folder, since I already need to extract the path to that folder to create the .dot file and they seem to do no harm there.