OLE Add of Merge Fields Only Works When User is Administrator in Windows XP

[T Scott]

I have a VB application that updates Word documents by adding merge fields.

The application works OK with all versions of Word from Word 97 onwards and
all versions of Windows from Windows 98 to Windows XP.

However there are a couple of installations (of Word 2000 on Windows XP)
where the update only works when the Windows user is an Administrator. When
a user is logged in as a Power User, with Full Control permissions assigned
to the folder where the document is being updated, the adding of the merge
field executes without error but the update does not "stick".

For illustration, the relevant code is:

objWordMailMergeFields.Add objSelection.Range, strReplacementMergeField

Can anyone advise if there are any other settings (either in Word or
Windows) that need to be changed to enable the update of the document.

Thanks
Tony scott

 

[Cindy M -WordMVP-]

Hi T,

However there are a couple of installations (of Word 2000 on Windows XP)
where the update only works when the Windows user is an Administrator. When
a user is logged in as a Power User, with Full Control permissions assigned
to the folder where the document is being updated, the adding of the merge
field executes without error but the update does not "stick".

Then I'd say the problem has to do with SAVING the file? Have you tried, on
one of these machines, a test that leaves the document open, visible and
activated after the "update" has been run? Is it there, in the document? And
what happens when you then try to use File/Save As? And File/Save?

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Sep 30 2003)
http://www.mvps.org/word

This reply is posted in the Newsgroup; please post any follow question or
reply in the newsgroup and not by e-mail

 

[T Scott]

Hi Cindy,

The section of the program where the update is not "sticking" (and so
causing problems) is not related to saving of the document. The program
does a search and replace of all occurrences of a word. Once all
occurrences of the word are replace the program continues to the next word.
But what is happening is that the replacement does not stick and so the next
search finds the first occurrence of the word that should have been
replaced. This causes an infinite loop.

So there is somthing stopping the OLE command (.add).

Since my first message I have found out that the customer uses McAfee's
ePolicy Orchestra. There is an option to prevent update via office
automation and they assure me that this option is disabled on the virus
server. However I believe the problem is still related to access rights.

Regards
Tony Scott

 

[Cindy M -WordMVP-]

Hi T,

The section of the program where the update is not "sticking" (and so
causing problems) is not related to saving of the document. The program
does a search and replace of all occurrences of a word. Once all
occurrences of the word are replace the program continues to the next word.
But what is happening is that the replacement does not stick and so the next
search finds the first occurrence of the word that should have been
replaced. This causes an infinite loop.

So there is somthing stopping the OLE command (.add).

Since my first message I have found out that the customer uses McAfee's
ePolicy Orchestra. There is an option to prevent update via office
automation and they assure me that this option is disabled on the virus
server. However I believe the problem is still related to access rights.

Maybe, but I've never seen anything in Word related to permission rights when
actually EDITING a document. Opening, saving, and not being able to *continue*
editing because TEMP files can't be managed properly, yes. And the latter
could be a factor, but I'd expect you to get an error message (such as "out of
memory") if that were the case.

But there's a way to find out exactly what is happening when the code runs,
and what is not:

Add some lines to the program that will pause execution after
- the search term is found
?Has the search term actually been found in the document (if you're using
Range.Find, stick a range.Select in there so that you can see what's been
found)

- the replacement for the found term is made
?Has the replacement actually been put there, or not?

- and when the second "Find" is successful
? if the replacement was actually made the first time, is it still there?

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Sep 30 2003)
http://www.word.mvps.org

This reply is posted in the Newsgroup; please post any follow question or
reply in the newsgroup and not by e-mail

 

[T Scott]

Hi Cindy,

Add some lines to the program that will pause execution after
- the search term is found
?Has the search term actually been found in the document (if you're using
Range.Find, stick a range.Select in there so that you can see what's been
found)

I am unable to replicate the problem on my development machines but the code
contains Trace commands that customers can turn on in situations like this.
Below is the relevant code and the Trace output from the customer's machine
appears below that.
As you can see the program tests for a successful find with "If .Find.Found
then". Second and subsequent .Find commands find the original text
indicating that the .Add doesn't change the document.

Set objWordMailMerge = objWordDoc.MailMerge
Set objWordMailMergeFields = objWordMailMerge.Fields
Do ' (while target field is found and no error)
Set objRange = .Content
With objRange
Trace PROCEDURE_NAME & " - Find (1) " & strTargetMergeField
lngErrNumber = 0
On Error Resume Next
.Find.Execute FindText:=strTargetMergeField,
Forward:=True
lngErrNumber = Err.Number
Trace PROCEDURE_NAME & " - After Find (1) " & strTargetMergeField &
IIf(lngErrNumber <> 0, " Error: " & lngErrNumber & " " & Err.Description,
"")
On Error GoTo ErrorHandler
Trace PROCEDURE_NAME & " - After On Error... "
If lngErrNumber <> 0 Then
Trace PROCEDURE_NAME & " - Error No. " & lngErrNumber & " generated from
..Find.Execute FindText:=" & strTargetMergeField
If lngErrNumber = 5590 Then
' Error 5590 - The Find What text
contains a range that is not valid
' Ignore this error - probably
nothing in range
lngErrNumber = 0
Trace "OLE Find " & strTargetMergeField & _
" returned Error 5590 - The Find What text contains a range that is not
valid" & vbCrLf & _
" Content section may not
contain anything to search for"
Else
' Reissue command with error handler
on to force the error again
Trace PROCEDURE_NAME & " - Issuing .Find.Execute FindText:=" &
strTargetMergeField
.Find.Execute
FindText:=strTargetMergeField, Forward:=True
End If
Else
' There was no error number
Trace PROCEDURE_NAME & " - There was no error"
End If
If lngErrNumber = 0 Then
' Either no Error number or Error No.
5590 ignored
Trace PROCEDURE_NAME & " - Before If .Find.Found Then"
If .Find.Found Then
Trace PROCEDURE_NAME & " - After If .Find.Found Then - Found"
.Select
Set objSelection =
objWordApp.Selection
Trace PROCEDURE_NAME & " - Before objWordMailMergeFields.Add " &
strReplacementMergeField
objWordMailMergeFields.Add _
objSelection.Range,
strReplacementMergeField
Trace PROCEDURE_NAME & " - After objWordMailMergeFields.Add " &
strReplacementMergeField
If Not objSelection Is Nothing Then
Set objSelection = Nothing
End If
Else
' Target field not found
Trace PROCEDURE_NAME & " - After If .Find.Found Then - NOT Found - About to
Exit Do"
Exit Do
End If
Else
' There was an error number
End If ' If lngErrNumber = 0 Then
End With ' With objRange
DoEvents
' Check if merge was cancelled
If m_blnProcessCancelled Then
' Merge Cancelled by operator
Trace PROCEDURE_NAME & " - Merge Cancelled by operator"
GoTo ExitProcedure
End If
Loop ' (while target field is found and no error)


TRACE OUTPUT FROM COMPUTER WHEN * * NOT * * LOGGED IN AS
ADMINISTRATOR ------------------------------

frmMain::RemapTemplateMergeFieldsForInternetMail - Set objWordMailMerge =
objWordDoc.MailMerge
frmMain::RemapTemplateMergeFieldsForInternetMail - Find (1) [[NamePrefix]]
frmMain::RemapTemplateMergeFieldsForInternetMail - After Find (1)
[[NamePrefix]]
frmMain::RemapTemplateMergeFieldsForInternetMail - After On Error...
frmMain::RemapTemplateMergeFieldsForInternetMail - There was no error
frmMain::RemapTemplateMergeFieldsForInternetMail - Before If .Find.Found
Then
frmMain::RemapTemplateMergeFieldsForInternetMail - After If .Find.Found
Then - Found
frmMain::RemapTemplateMergeFieldsForInternetMail - Before
objWordMailMergeFields.Add Custom1
frmMain::RemapTemplateMergeFieldsForInternetMail - After
objWordMailMergeFields.Add Custom1
frmMain::RemapTemplateMergeFieldsForInternetMail - Find (1) [[NamePrefix]]
frmMain::RemapTemplateMergeFieldsForInternetMail - After Find (1)
[[NamePrefix]]
frmMain::RemapTemplateMergeFieldsForInternetMail - After On Error...
frmMain::RemapTemplateMergeFieldsForInternetMail - There was no error
frmMain::RemapTemplateMergeFieldsForInternetMail - Before If .Find.Found
Then
frmMain::RemapTemplateMergeFieldsForInternetMail - After If .Find.Found
Then - Found
frmMain::RemapTemplateMergeFieldsForInternetMail - Before
objWordMailMergeFields.Add Custom1
frmMain::RemapTemplateMergeFieldsForInternetMail - After
objWordMailMergeFields.Add Custom1
frmMain::RemapTemplateMergeFieldsForInternetMail - Find (1) [[NamePrefix]]
frmMain::RemapTemplateMergeFieldsForInternetMail - After Find (1)
[[NamePrefix]]
frmMain::RemapTemplateMergeFieldsForInternetMail - After On Error...
frmMain::RemapTemplateMergeFieldsForInternetMail - There was no error
frmMain::RemapTemplateMergeFieldsForInternetMail - Before If .Find.Found
Then
frmMain::RemapTemplateMergeFieldsForInternetMail - After If .Find.Found
Then - Found
frmMain::RemapTemplateMergeFieldsForInternetMail - Before
objWordMailMergeFields.Add Custom1
frmMain::RemapTemplateMergeFieldsForInternetMail - After
objWordMailMergeFields.Add Custom1
}
}
} Lot's more repetition here until user cancels operation
}
}
frmMain::RemapTemplateMergeFieldsForInternetMail - Find (1) [[NamePrefix]]
frmMain::RemapTemplateMergeFieldsForInternetMail - After Find (1)
[[NamePrefix]]
frmMain::RemapTemplateMergeFieldsForInternetMail - After On Error...
frmMain::RemapTemplateMergeFieldsForInternetMail - There was no error
frmMain::RemapTemplateMergeFieldsForInternetMail - Before If .Find.Found
Then
frmMain::RemapTemplateMergeFieldsForInternetMail - After If .Find.Found
Then - Found
frmMain::RemapTemplateMergeFieldsForInternetMail - Before
objWordMailMergeFields.Add Custom1
frmMain::RemapTemplateMergeFieldsForInternetMail - After
objWordMailMergeFields.Add Custom1
frmMain::RemapTemplateMergeFieldsForInternetMail - Merge Cancelled by
operator

Regards
Tony Scott

 

[Cindy M -WordMVP-]

Hi T,

As you can see the program tests for a successful find with "If Find.Found
then". Second and subsequent .Find commands find the original text
indicating that the .Add doesn't change the document.

OK, when looking at your Find code, generally, I'm wondering if the merge
field is not being added, or if it's being added but just isn't replacing
the "found" text? Have you ever looked at such a document to be sure?

My "gut feeling" is that something may be preventing the *replacement*.
And since your code apparently doesn't reset the search range but always
runs on the entire document range, it keeps getting the same hit.

If you stick a .Delete in there, before the .Add, do you get different
results?

There is at least one Option setting in Word that will prevent
"overtyping" replacing a selection and I'm guessing that this may be the
problem.

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Sep 30 2003)
http://www.word.mvps.org

This reply is posted in the Newsgroup; please post any follow question or
reply in the newsgroup and not by e-mail

 

[T Scott]

Hi Cindy,

Many many thanks.

There is at least one Option setting in Word that will prevent
"overtyping" replacing a selection and I'm guessing that this may be the
problem.

This was the cause.
The "Typing replaces selection" option is normally checked on by default.
Changing the setting does not make any difference to Automation on Word 97
but the Automation of Word 2000 and later versions have a different
behaviour in this respect, requiring the "Typing replaces selection" setting
to be checked ON if .Adds are applied to Selections.
Because the Administrator and Power User had different Word settings the
..Add worked with the Administrator and failed with the Power User

I will change the code in the next version to .Delete the selection before
the .Add rather then just applying the .Add to the .Selection.

Thanks Again
Tony Scott