Custom Footer (Word 2002)

Topic

New Reply

I need to be able to create a custom footer that can extract a pre-determined portion of folder names. For example, our current footer is C:Current CustomersNortheast RegionSa-SmJoe Smith 12345.00orders 0001jsmith.docTAMpjf
The last item in the footer is the user initials-lower case, the second to last is author and the remainder of the footer is created via the autotext insert of the filename and path.

I would like to create the following revised footer: Sa-Sm12345.000001jsmith.docTAMpjf . I need to do this to ease privacy concerns about the detail revealed in the footer of the sales letter. As you can see from the revised footer, I no longer want to use the full path. The first item in the new footer is the folder Sa-Sm (i.e., the folder name will vary as its used to capture customers whose last name starts with Sa to Sm–I will always use the full folder name). Additionally, the second and third element of the new footer are numbers extracted from the respected folders (the folder Joe Smith 12345.00 shows in the footer as 12345.00 (i.e., I will always need the last eight charaters of the folder) and the folder orders 0001 becomes 0001 in the footer (i.e., I will always need the last 4 characters of this folder). Then the document name, author and user initials remain unchanged from the original footer. Once we start to use the new footer, the word document naming convention will also be changed to NOT reveal the customer name (i.e. this does not impact the creation of the new footer).

I have searched through the lounge and can’t find anything close to this issue. Can this be done with VBA? If so, I need some sample code to get me started and finally, I need to understand if the code will change the footer anytime the file is saved to a new location or will the user need to re-run the code if the user changes any of the elements contained in the revised footer (i.e., the saved location of the document is changed or the document name or author is changed)? Since the current footer uses standard word fields–they automatically change to reflect the current saved location, etc.—even if the file saved location is modified from its original location during a subsequent edit process. I need to ensure that the code solution to create a new footer is always accurate just like the MS Word fields update automatically with the current footer using the standard Word fields. The automatic update of the fields in the new footer to reflect subsequent changes maybe my most difficult challenge with a VBA solution. THANKS.

Reply | Quote

Replies

There are no string manipulation functions for use in fields, so I think you’ll have to use VBA.

You could use the following macro:

Sub SetFooter()
Dim strPath As String
Dim strFooter As String
Dim arrParts
Dim i As Integer
Dim n As Integer
strPath = ActiveDocument.FullName
arrParts = Split(strPath, “”)
n = UBound(arrParts)
strFooter = arrParts(n – 3) & “” & _
Right(arrParts(n – 2), 8) & “” & _
Right(arrParts(n – 1), 4) & “” & _
arrParts(n) & “” & _
UCase(ActiveDocument.BuiltInDocumentProperties(wdPropertyAuthor)) & “” & _
LCase(Application.UserInitials)
ActiveDocument.Sections(1).Footers(wdHeaderFooterPrimary).Range.Text = _
vbTab & strFooter
Erase arrParts
End Sub

and call it from the Document_Open event in the ThisDocument module:

Private Sub Document_Open()
SetFooter
End Sub

The footer will automatically be updated when the document is opened, but only if the user enables macros. If you want the footer to be updated when the user saves the document under another name or in another location from within Word, you’d have to hijack the FileSaveAs command.

Reply | Quote

Hans,
Thank you for your sample code. Yes, the users do “enable macros” when opening word files as I have several simple print macros in the template file—so that won’t be a problem. There are many people that “create” these word files..so I need the “most” mechanized solution that can be achieved via vba.

After testing your code, what I have found out is that I will need to have the footer update when the document is saved. The reason for this is that the word file is filled with the customer information, then saved, then printed. These typists would now need to enter the customer information, save it, close the file, re-open the same file and then print it to get the newly revised footer. So it looks like I will need to “hijack” the FileSaveAs command…have no clue how to do this. Would you recommend that I create a new button on the toolbar that will save the file AND update the footer or can the code be arranged in a way that it fires whenever the typist click “save” or “save as” from the File menu? Thanks again.

Reply | Quote

You could use these two macros:

Sub FileSave()
If Right(ActiveDocument.Name, 4) = “.doc” Then
ActiveDocument.Save
Else
FileSaveAs
End If
End Sub

Sub FileSaveAs()
If Dialogs(wdDialogFileSaveAs).Show = True Then
SetFooter
End If
End Sub

They hijack File | Save and File | Save As.

Reply | Quote

Hans,
I have one further question and also want to confirm my understanding on post # 568045. Is there any way to get the footer to be aligned with the left margin the same as it is when using the standard MS word fields in the footer? The macro generated footer starts about 2 inches from the left margin. I have tried experimenting with the vbTab command but that doesn’t seem to be the reason the vba footer does not start at the left margin.

Also, on post 568045, the code actually “appends” the function of the “save” and “save as” function versus a “hijack” of the intended function, correct? These commands still function as normal but additionally create the footer via vba prior to performing their normal function…am I understanding this correctly? Is it possible via code to actually “hijack” the save or save as button [or any other standard function] so that it doesn’t “save” or “save as” anymore but actually performs a different function? I can think of no reason to do this, but I just want to understand whether VBA is limited to “appending a function” or can actually “replace” the intended function in a MS software application. THANKS.

It is important to me that I just don’t come to the lounge for a quick code solution without also attempting to learn the code you or other moderators provide whether it this lounge or the EXCEL lounge…My heart is generally in the EXCEL lounge and I read all the posts daily as a way to learn–I also notice how much of your time you give to helping others learn about code and MS Software….I am truly thankful for your willingness to share your knowledge with others….I am also amazed at your creative ability to solve problems/issues and your patience with those that need the help but don’t always know how to ask…take a bow you are the GREATEST!

Reply | Quote

1) I’d try omitting the vbTab altogether – it was intended to center the text in the footer. So:

ActiveDocument.Sections(1).Footers(wdHeaderFooterPrimary).Range.Text = _
strFooter

2) If you create a macro with the same name as a built-in command, Word will execute the macro instead of the built-in command. It is completely up to you as programmer to decide what the macro will do. In most cases, you will invoke the standard action together with some extra code, but you can also disable a built-in command this way. If you’re in a devilish mood, you could even have File | Open make selected text bold, and make Edit | Copy close the active document.

If you’re interested, you can download a file listing all built-in commands from Word commands, and their descriptions, default shortcuts and menu assignments. The comments are amusing.

Thanks for your kind words, by the way!

Reply | Quote

Hans,
Thanks. Eliminating the vbTab did the trick…after I checked what I was trying..in error, I also had eliminated the _ after the equal sign–this is not good, trust me. To ensure this new footer is universally used, can I add this code to each typists’ normal.dot file? We also have several other templates for an invoice and shipping label…I believe these template files would also need to have the code inserted into them as when a template is opened it [the new templace] supercedes or over writes the normal.dot template that is opened at the start-up of MS Word…is this correct? THANKS.

Reply | Quote

If you put the FileSave and FileSaveAs macros in a module in Normal.dot or in a global template (add-in), they will replace the built-in commands, even in a document based on another template. Normal.dot and global templates stay loaded throughout the entire Word session.

Reply | Quote

Hans,
Everything has worked fine with this solution; however, the end users have made an additional request that I have not been able to code. They have requested that I print “Page #” centered on the next line following the revised path macro you created in this thread. Additionally, they do NOT want the page number to appear on the first page.

So on a 3 page document , they want the path only in the footer on page 1 , but the path (still left aligned on the first line of the footer) and Page 2 and Page 3 centered on the line following the path in the footer for pages 2 and 3. I noticed that the Page number dialog box has a check box on whether to show the page number on the first page…and I tried the Word macro recorder but I still can’t get the desired result, I haven’t been able to successfully write an “IF” statement to keep the page number from appearing on page 1. Nor have I been able to discern the code to “center” the Page # on the line following the file path. I can only get my “page #’s” to be left aligned which I am guessing is the default. Also, my left aligned page numbers are “over-writing” the file path you created..I can’t seem to get the page number to start on the second line of the footer—I must need a carriage return in the code or something. Thanks.

Reply | Quote

Try this:

Sub SetFooter()
Dim strPath As String
Dim strFooter As String
Dim arrParts
Dim i As Integer
Dim n As Integer
Dim rng As Range
strPath = ActiveDocument.FullName
arrParts = Split(strPath, “”)
n = UBound(arrParts)
strFooter = arrParts(n – 3) & “” & _
Right(arrParts(n – 2), 8) & “” & _
Right(arrParts(n – 1), 4) & “” & _
arrParts(n) & “” & _
UCase(ActiveDocument.BuiltInDocumentProperties(wdPropertyAuthor)) & “” & _
LCase(Application.UserInitials)
With ActiveDocument.Sections(1)
‘ Specify a different footer for the first page
.PageSetup.DifferentFirstPageHeaderFooter = True
‘ Set the footer for the first page
.Footers(wdHeaderFooterFirstPage).Range.Text = _
strFooter
‘ Set the footer for subsequent pages
.Footers(wdHeaderFooterPrimary).Range.Text = _
strFooter & vbCr & vbTab & “Page ”
Set rng = .Footers(wdHeaderFooterPrimary).Range
rng.Collapse Direction:=wdCollapseEnd
rng.Fields.Add rng, wdFieldPage
End With
Erase arrParts
Set rng = Nothing
End Sub

Reply | Quote

Hans,
Thanks for the code..it has worked wonderfully. Like many projects, I guess I am into phase 2. Earlier in this post you stated that Word field strings cannot be manipulated. Can Word fields be created much like EXCEL permits user defined functions? The reason I am asking is I would like to create a field, named say KWGD path, and the field is populated by the code in the macro that establishes the file path in the footer. Is this possible? If so, I would need to be able to add this new user defined field to the normal.dot so that all of my users could insert this field anywhere into the document. I am so much hoping such a field can be created. The answer will determine my next steps. THANK YOU.

Reply | Quote

You can set a custom document property or a document variable in code. The difference is that the user can view and edit custom document properties in the Custom tab of File | Properties, while document variables can only be edited in code.
The user can refer to a document property anywhere in the document by inserting a DocProperty field, and to a document variable by inserting a DocVariable field. Here is code to set a custom document property.

Sub SetValue()
Dim strPath As String
Dim strValue As String
Dim arrParts
Dim i As Integer
Dim n As Integer
On Error GoTo ErrHandler
strPath = ActiveDocument.FullName
arrParts = Split(strPath, “”)
n = UBound(arrParts)
strValue = arrParts(n – 3) & “” & _
Right(arrParts(n – 2), 8) & “” & _
Right(arrParts(n – 1), 4) & “” & _
arrParts(n) & “” & _
UCase(ActiveDocument.BuiltInDocumentProperties(wdPropertyAuthor)) & “” & _
LCase(Application.UserInitials)
ActiveDocument.CustomDocumentProperties(“KWGD”) = strValue

ExitHandler:
Erase arrParts
Exit Sub

ErrHandler:
ActiveDocument.CustomDocumentProperties.Add Name:=”KGWD”, _
Type:=msoPropertyTypeString, Value:=strValue, LinkToContent:=False
Resume ExitHandler
End Sub

Reply | Quote

Hans,
Thank you for this code…I have been experimenting with it and have the following observations. First, if I run the code twice [i.e. for example, the path needs to be updated to reflect the fact that the document was saved in a different place or using a different document name], I get a Run time error -2147467256 (80004005) Automation Error, Unspecified Error. If I delete the KWGD custom document property and then re-run the code–no error message. So I am stumped as to how to capture the “new” file path if a document is subsequently re-named through a file save_as action. Can the code be “smart enough” to discern if the KWGD custom document property already exists and if so, delete it prior to re-creating it to avoid the run time error?

Second question is that the document must be saved prior to running the code or a “blank” record is returned as the property value. This makes sense as there is no path or document name until the document is saved. This made me wonder if I could associate your new code to post 568099 where you “high-jacked” the file save and save_as functions. Again, the macro would need to discern if a KWGD property field already existed prior to creating one as noted in my first paragraph to avoid the runtime error.

The last issue I observed is when the KWGD custom document property is placed in the body of a document or in the header / footer it is a “one” time shot as far as accuracy. For example, I created the kwgd custom document property using your code, and then inserted this field into the document body. If I then follow the steps above, delete the KWGD custom document property, save the document with a new name and then re-run the macro…the field value does reflect the “new” file path / filename, etc. However, the kwgd custom document property already inserted in the document still shows the previous path and file name. I need to be able to create and use a document field or document variable that once placed in the document [ either in the body or header / footer ] will change to reflect a new path / filename, etc. as the user saves the document.

I hope I have not made this post too long or too confusing; but I really try to leverage your time by not leaving out any of the critical details or thought processes. Also, if this is too complicated and I really need a professional consultant, please let me know as I do not want to over step the lounge’s mission statement as to “helping” but not “consulting”. I hope all is well with you and your family. Thank you.

Reply | Quote

Some code is not designed to be run twice.

It is common for Word VBA to generate an error when trying to add a new item to a collection with a duplicate key (in this case, the name of the custom property). Similarly, if you try to check whether the property is there by accessing it, if it’s missing you will get an error. If you expect the code to run when the property already exists, you need to account for these errors. One way is as follows, which is an example I have handy and not related to your particular custom property. It looks at every property to find the target and, if it doesn’t exist, creates it:

Public Function ReadWFP() As String
' Return value of WFP document property or, if it doesn't exist,
' create it with the value 00
Dim docprop As DocumentProperty, custProps As DocumentProperties
Set custProps = ActiveDocument.CustomDocumentProperties
For Each docprop In custProps
If docprop.Name = "WFP" Then
' The property exists! Validate string
Select Case docprop.Value
Case "00", "01", "10", "11" 'valid
' No action; extract value after Select
Case Else
' This is no good; reset to 00
docprop.Value = "00"
End Select
ReadWFP = docprop.Value
GoTo cleanUp
End If
Next
' The property needs to be created
custProps.Add Name:="WFP", LinkToContent:=False, _
Type:=msoPropertyTypeString, Value:="00"
ReadWFP = "00"

' Clean up objects
cleanUp:
If Not docprop Is Nothing Then
Set docprop = Nothing
End If
Set custProps = Nothing
End Function

(That’s old code; I think I’m a bit more efficient these days. )

Another approach is to use error handling. Try to create the property, trap and inspect any errors, and then proceed from there.

Reply | Quote

Thanks for the return post…can you also shed some light on my third paragraph? Is what I have observed, that once a custom document property field is placed in the document it is “frozen” with its value fixed at the time of insertion? If this is the case, I will need to seek other alternatives. I really need a “dynamic” field or variable to resolve my problem, sorry I mean challenge. THANKS.

Reply | Quote

(Edited by jscher2000 on 28-Jun-06 12:20. )

All fields are static until refreshed. Otherwise, no one would use the table of contents feature (or they would destroy their computers in aggravation).

Fields can be set to update at print time (Tools>Options…, Print tab), but you cannot impose this on the user. Or you could change this setting in a Document_Open or Document_New procedure, but this would require the user to trust you.

I haven’t studied this thread to see exactly what you want, but if you want to require truly real-time updating, fields alone are not the solution. They can be part of a solution, but some VBA code will need to refresh them when the underlying values have changed.

Added: I read up the thread a bit, and you probably should “hijack” the Save command. Presumably your solution will be stored in a global template distributed to all users. Unless there already is a replacement FileSave or FileSaveAs procedure elsewhere in the environment, that’s your best bet. If macro security is high or very high, you might need to sign the global template, but that’s beyond my actual experience and you can deal with that after you’ve worked out the functionality.

Reply | Quote

In the first place, I have to apologize. The macro I posted contains a very stupid typo: the document property is referred to as “KWGD” one time, and “KGWD” the other time. The second one should have been “KWGD” too, of course. This causes the error message you got.

You can update all fields in the document by adding a line immediately before the ExitHandler label

ActiveDocument.Fields.Update

You can call SetValue in the Document_Open event procedure in the ThisDocument module:

Private Sub Document_Open()
Call SetValue
End Sub

Each time the document is opened, the document property is updated, and the fields in the document too. So if the document has been moved to another folder or has been renamed, the DocProperty field will reflect the current situation.

If you also want the field to be updated when the document is saved under a different name, hijack the FileSave and FileSaveAs commands:

Sub FileSave()
If Right(ActiveDocument.Name, 4) = “.doc” Then
ActiveDocument.Save
Else
FileSaveAs
End If
End Sub

Sub FileSaveAs()
If Dialogs(wdDialogFileSaveAs).Show = True Then
Call SetValue
End If
End Sub

Disadvantage is that the document is modified after it has been saved, so if you now close the document, you’ll be asked whether to save changes.

I have attached a demo document. Download it to your PC, then open it. Enable macros to see the field updated.

Reply | Quote

Hans,
Thanks for the return post…I have downloaded your example and will digest it. I caught the typo when I read your post and made a mental note to make both references the same. I “thought” that I had corrected it after I copied the code from the lounge to Module1–and was ready to share this news in a return post. But when I just now double checked the code Module1, I failed to correct the typo…so, no need to apologize as I failed to execute basic follow through. I will post back once I can digest your example file and advice. Many , many thanks for your patience and willingness to share your talent to help others learn.

Reply | Quote

Hans,
I think the macro in your example file will work wonderfully. I am still digesting the code though….you are truly a genius. Thanks again for your assistance.

Reply | Quote

Can someone explain “how” the ErrHandler sub works in Hans’ code?

I am occassionally getting a run time error -2147467256 (80004005), Automation Error, Unspecified Error. When I click “debug” it goes to the first line of the ErrHandler sub routine. I believe the end user is creating the error when saving the file in a path that was not anticipated when I initially posted to the lounge.

The stated path was always to be C:ActiveBBBClient12345.99Matter0000CMfilename.doc. The macro then “created” a field named kwgd in document properties by parsing the various folder layers into a string. What has now happened, is the user occassionally saves the document to path C:Activefilename.doc. Since the saved path does not contain the assumed number of layers, I believe the macro code blows up with the error message noted previously when the user “saves” or “saves as” a document with a too short file path. How can I adjust the error handler routine to not create the KWGD field when the user saves the file to a path that is not expected by the macro [i.e. not enough folder layers]? THANKS.

Reply | Quote

> Can someone explain “how” the ErrHandler sub works in Hans’ code?

The code in post 582,559 follows this logic:

• Set an error handler to go to the label “ErrHandler” if there is an error;
• Calculate strValue;
• Set the custom document property “KWGD” = strValue; if that property does not exist, Word throws an error and execution continues in ErrHandler, which creates the custom property with a value = strValue and then resumes when you left off;
• Clean up and quit[/list]Your modified version re-uses one error handler for three different conditions. As a result, your error handler may itself generate an error: as noted above, creating a custom document property which already exists generates an error.

  As a first stab at a workaround, try the attached code. It has individual error handlers for each of the properties “KWGD4”, “KWGD5”, and “KWGD6”. Does it help?

Reply | Quote

jscher2000,
Thanks for the post. Your macro still gives me the same error. After reading your initial post that I had improperly combined the ErrHandler routine from Hans’ original post, I decided to go back to his macro in post 583655 which created only a single new field [kwgd] in the document properties.

His macro produces the same error. This is no fault of the code, but that a change in what I was told originally that was “fixed” and would never change [i.e., the file path]—did change. If you take your macro or Hans’ macro and save the word file to the short path of C: jscher2000.doc or C:My Documents jscher2000.doc, you will get the run-time error -2147567259, etc. noted in my previous post [for your macro, you will need to add the code that Hans’ used to auto fire the macro with the save and save as functions [noted in next paragraph]. I get the error message when “saving” or file saving the word document to a “short” file path.

If I am using your macro and click debug, it takes me to the first line in ErrHandler3. I believe the reason for this error is that with the short file path, there is no k-6 or k-5 items in the path to use for the Right function [i.e. because the users have violated their own path rule that was given to me when I tried to mechanically fix the path through a macro.

The minimum file path to use the macro is:
C:|ActiveDocsClientsSA-SMSmith12345.00Matter0002CMdocument_name.doc

So I need the macro to check to see that there are at least 6 folders in the path . Should there be 5 or less folders then I wan to abort the entire sub-routine and not create the fields in the doc properties.

Is it possible to code the macro to “count” the number of folders in the file path prior execution [in Han’s macro the sub-routine was triggered by the user executing a file “save” or a file “save as”]?? Is this type of function / coding beyond the scope of help provided by the lounge? I do not want to “abuse” the lounge, so if what I am asking is unreasonable, please say so. I went searching through the lounge on ways to “count” folders in a path and found nothing…I am not the best at using “search”…so maybe I missed something or I have, in fact, asked for something that is too difficult. Thanks.

Reply | Quote

I couldn’t remember the point of all this, so I went back to the top:[indent]

---

…our current footer is

C:Current CustomersNortheast RegionSa-SmJoe Smith 12345.00orders 0001jsmith.docTAMpjf

The last item in the footer is the user initials-lower case, the second to last is author and the remainder of the footer is created via the autotext insert of the filename and path.

I would like to create the following revised footer:

Sa-Sm12345.000001jsmith.docTAMpjf

---

[/indent]So you’re saying that the assumption that all documents have a consistent filing methodology has broken down.

Okay, so now –[indent]

---

Should there be 5 or less folders then I wan to abort the entire sub-routine and not create the fields in the doc properties.

---

[/indent]– that actually is not too bad. As you’ve noticed, the path is being populated into a dynamic array of strings using the Split() function. You only need to add one line:

strPath = ActiveDocument.FullName
arrParts = Split(strPath, "")
n = UBound(arrParts)
If n < 5 Then Exit Sub

You might need to experiment with that (perhaps it needs to be 6 to account for the drive letter?) to make it fit your code.

Reply | Quote

Hans,
I am stuck again on this topic. The users have changed several of the assumptions from my initial posting last June. First, the actual file location can be in the location of your previous macro or one additional folder deeper or two additional folders deeper from the initial assumed path location.

Additionally, the end users decided to put the macro into their “normal.dot” for convenience. The only issue is that they receive an error message whenever they open a blank document…after some research, I believe this is because that the StrPath = ActiveDocument.FullName is less than the 3 assumed in the macro[i.e. file path is C:word.doc—This path is missing the additional folders that is assumed in the macro]–so that n-3 is negative.

I have tried to modify the code to create three fields [KWGD4, KWGD5, KWGD6]..and not to error if a document is openned that does not contain a deep enough file path for the macro to run [i.e., c:mydocumentsfilename.doc]
If the document is stored with the normal protocal, then the end user selects the field KWGD4 in the footer, if they store it one folder deeper, then it is KWGD5 that has the correct path and if it is 2 additional folders deeper from the KWGD4 assumptions, then they use KWGD6—I believe that human interaction is needed here, as I never know exactly what the full file path will be–so the end user must select between KWGD4, KWGD5 and KWGD6 as the correct path to display on the document.

My modified macro [it is a mess] is attached in the word file. It runs, but the code only creates one field after each save [i.e., KWGD4 is created on the first save or save is], the KWGD5 is created on the second save or save as and KWGD6 is created on the third save…once all three fields are created, they all modify correctly with additional future saves. I need to create all three fields on the first save or save as—plus not generate an error message should the file path not be long enough for the macro–since this code is now resident in the normal.dot.

I know you will laugh when you see the macro…I am still a long way from understanding VBA…thanks for your patience.

Reply | Quote

I don’t understand why you want to create 3 different document propertiesd KWGD4, KWGD5 and KWGD6. Why not use just one, and fill it with the appropriate information depending on the depthj of the path? You could do something like this:

…
strPath = ActiveDocument.FullName
arrParts = Split(strPath, “”)
n = UBound(arrParts)
Select Case n
Case 4
‘ code for n = 4
strValue = …
Case 5
‘ code for n = 5
strValue = …
Case 6
‘ code for n = 6
strValue = …
Case Else
‘ Wrong depth
MsgBox “Path doesn’t have required depth.”, vbInformation
Exit Sub
End Select
ActiveDocument.CustomDocumentProperties(“KWGD”).Value = strValue
ActiveDocument.Fields.Update
…

Reply | Quote

Hans,
I am struggling with the length of the path..can I display the value of n in the immediate window to help me in the coding process? If not, I am assuming that the value of n for this path c:active clientsR-SclientnamematternameCMdocumentname.doc is 6? Does the calculated value of n count the backward slashes or the names in the path [7]? Also, I would like to include the value of n in the error text in the message box…is this possible? Again, thank you for your patience and assistance.

Reply | Quote

Split produces a zero-based array, i.e. the first item is numbered 0, the second one is numbered 1 etc. In your example, Split would result in an array with 7 elements, numbered 0, 1, …, 6:

arrParts(0) = “C:”
…
arrParts(6) = “documentname.doc”

Note that UBound returns the index of the last element, it is one less than the actual number of elements.

You can insert

Debug.Print n

in the code to display the value of n in the Immediate window, and you can show it in a message box like this:

MsgBox “n = ” & n

or

MsgBox n & ” – ” & Err.Description

Reply | Quote

Hans,
Thanks for the explanation and pointer on how I can learn the value of n…I am hopeful that I can finish this macro now…but one final question of clarification…

I am reading the help file on Select Case…seems this is a better way to “nest” a series of conditions versus using “if” statements nested together. I had tried using nested “if” statements originally to create only one KWGD field…but for some reason that I haven’t figured—only the first “if” statement ever worked…if it wasn’t true neither of the other two “if” statements were triggered—this is why I decided to create 3 different KWGD fields and let the end user select which one should be inserted into the document or footer.

Again, thanks for your help…As I have said before in this and the EXCEL forum, the only thing greater than your computer knowledge—is your willingness to share with other people. The speed and thoroughness of your replies in this and the EXCEL forum are awesome….you are truly an amazing human being…I just can’t begin to thank you enough for all of your help over the years….

Reply | Quote

Select Case … End Case is indeed a more efficient replacement of a series of If … Then … ElseIf … Then … End If statements.

Thanks for your kind words.

Reply | Quote

Hans,
I have been making steady progress on this macro and it has been in production for about two monthes. Once it was done, the word processors felt it would be more beneficial to include the macro in the normal.dot. Anyway everything has worked fine, except that the file properties box no longer fires when saving the document [i.e., when you go to Tools / Options, select the save tab and then click on the box “prompt for document properties”].

I am guessing this result is because I have “hi-jacked” the save and save as action per your advice in post 568045. When I remove the macro from the normal.dot–then the file properties box does work once you activate it. My question is can I have the files property box fire when the document is closed via code?

I have analyzed the transcription process and most of the time when the file is first saved the word processor doesn’t have the required the information to adequately complete the items in the file properties box. What would be better is that when the document is closed, prompt the user with the file properties box and then save the document prior to Word closing the document. Can the “close” function also be “hi-jacked” to perform these two tasks [prompt the user with the file dialog box and then save] prior to “closing” the document? Thank you for your advice.

Reply | Quote

You could add the line

Dialogs(wdDialogFileSummaryInfo).Show

immediately below (or above) SetValue in the FileSaveAs macro.

Intercepting the Close command is tricky – it’s better to create an AutoClose macro.

Reply | Quote

Hans,
Thanks..I will work with this idea…appreciate your advice. Again, thank you. Take care.

Reply | Quote

(Edited by jscher2000 on 15-Sep-06 16:52. Lengthy Code Moved to Attachment)

Hans,
The word processing group needed some more flexibility..so I added some additional code to your macro..it is below. On occassion and I can’t seem create what recreates it, I get a Run time error -2147467259, then it states automation error and unspecified error. Can you shed some light on the error message, what does it mean? When I click debug, it high lights the first line in the ErrHandler routine. I do have one question though..what happens to the macro should the path simply be G:Active Docs ? Since I don’t have enough fields in the path for the macro, I wonder if it blows up should the end user have short path . I have been called to the user’s desk to see this error message on several occassions, but I can’t reproduce it on my pc..so I wonder what the user is doing to get the message or did I do something when I expanded your code? Thank you.

Reply | Quote

Jim, your code directs three different errors to the same handler, so I suspect the problem is when your KWGD4 property already exists and one of the other two is missing. If you “walk through” the code, you’ll see what I mean:

– assign value to property KWGD4 ; no error, continue
– assign value to property KWGD5 ; error, go to handler
– add new property KWGD4 to the document; error, that property already exists, go to self

I haven’t looked at the original code to see what you have changed, but if you experiment with a problem document using the debug single step feature you can confirm one way or the other what is going wrong.

Reply | Quote