ActiveDocument.Content.Find.Execute gives Runtime Error 4605

[Ancient Brit]

I have a very simple piece of code that refuses to work.

I'm missing something obvious, I know, but for the life of me I can't see
what it is.

Background: I have three different Word documents, the partial contents of
which are to be copied (minus the final pilcrow) to another document. The
distinction for each document type is in the main story, and so I simply need
to search each document for its identifier and act accordingly on the
different parts from each. One is copied from section 3 to the penultimate
section, one is copied from section 2 to the end, and the third is copied
from section 1 to the end (all minus the last pilcrow). Couldn't (in theory)
be simpler.

The main document contains the relevant macros, one of which allows the user
to designate and open a secondary document to be copied, and then checks to
see what kind of document was opened according to the identifiers.

The code so far:

'Get currently open document, which is the target document
M_TargetDoc = ActiveDocument

'Now get source document
Dim dlgOpen As FileDialog
Set dlgOpen = Application.FileDialog(FileDialogType:=msoFileDialogOpen)
With dlgOpen
.Title = "Select Your Source Document"
.Filters.Item (3) 'Preselects .doc files
.AllowMultiSelect = False
.Show
End With

If dlgOpen.SelectedItems.Count = 0 Then
'User pressed Cancel, so abandon task
Exit Sub
Else
M_SourceDoc = dlgOpen.SelectedItems.Item(1)
End If

'Open the file chosen above:
Documents.Open FileName:=M_SourceDoc 'This will become the active doct

'Begin by setting M_DocTypeFlag to 0 as a QC check
M_DocTypeFlag = 0

'Now scan the currently-active document to determine its probable type
Set M_DocTypeRange = ActiveDocument.Content

'Is it Type 1?
M_DocTypeRange.Find.Execute FindText:="Document Information Record", _
Forward:=True

If M_DocTypeRange.Find.Found = True Then M_DocTypeFlag = 1

etc.

The code fails on .Execute - claims the command is not available. So I set
up a watch and then examined the object's properties and it's true - Execute
is not associated with it. But I can't see a workaround.

The code is taken from Microsoft's own example in Help for the FIND object:

Set myRange = ActiveDocument.Content
myRange.Find.Execute FindText:="blue", Forward:=True
If myRange.Find.Found = True Then myRange.Bold = True

I realize that it could be in error. Anyone any thoughts?

 

[Pesach Shelnitz]

Hi,

Your code works for me without error. In fact, when I insert the string
"Document Information Record" and add the following line after the line in
your code with Execute, the macro selects the search string in the document
that it opens.

M_DocTypeRange.Select


Pesach Shelnitz

 

[Rich007]

Dear Ancient Brit
I tested the code you included below and it works fine on my pc.
Sorry, but I can't be any more constructive than that.
Cheers
Rich (a not-so ancient Brit).

 

[Ancient Brit]

That's really odd. I get the same error on two different systems - both
running Office 2003, both under XP Pro (one's a networked IT environment
workstation at a client's location, the other's a standalone PC at home).

Your result is what I expected to get. Any thoughts on possible causes?

Best,

Peter

 

[Ancient Brit]

Eureka, as they say.

On a hunch I checked the source document - and it's protected. That raises a
raft of other issues but if I unprotect the document (fortunately I know the
password), the code works as expected.

Thanks to both Pesach and Rich for their thoughts.

I may yet have other, different questions...

Best,

Peter

 

[Graham Mayor]

Easy enough to unprotect it

Dim i As Integer
Dim bProtected As Boolean
Dim sPassword As String
sPassword = ""
'Unprotect the file
If ActiveDocument.ProtectionType <> wdNoProtection Then
bProtected = True
ActiveDocument.Unprotect _
Password:=sPassword
End If

'Do your thing

'Reprotect the document.
If bProtected = True Then
ActiveDocument.Protect _
Type:=wdAllowOnlyFormFields, _
NoReset:=True, _
Password:=sPassword
End If


--
<>>< ><<> ><<> <>>< ><<> <>>< <>><<>
Graham Mayor - Word MVP


<>>< ><<> ><<> <>>< ><<> <>>< <>><<>

 

[Ancient Brit]

Hi Graham

Thanks for that - I was debating whether to try that route, but then tripped
over the fact that for one set of documents no user will know the password
(and neither will I), so I'll basically need to test for protection in the
secondary document once it's open and if present, advise the user to contact
the issuing center (so that they can issue an unprotected version of the
document) and abandon the task.

I'm aware that Word protection can easily be got around, but this is a
regulated environment and there's an SOP forbidding hacking into protected
documents (even if it's easy ) Until this project I had no idea that Word
protection had such a negative impact on VBA.

My next (i.e. current) task is to take a (sometimes large) selection of text
(could be as much as 500 pages) in the secondary (source) document and walk
through it section by section, copying all but the section break in each
section and pasting it into the current insertion point in the primary
(target) document, observing page orientation for the secondary document
section and reflecting it in the primary (the primary already has headers and
footers defined and they mustn't be overridden by the copy/paste process -
there's an integrity check that's performed each time the primary document is
opened, and embedded fields and bookmarks in the cover and every section
footer after the cover are checked for changes; if there are, the document is
flagged as requiring review). A little complex but the rules are basically
simple.

It's at times like these that I butt up against some of the more obscure
failings of Word 2003 and VBA (like the failure of screen updating to be
genuinely switched off - I get some really weird effects sometimes, with
dotted outlines for objects in the document - like footers - suddenly
appearing on the screen, and so far haven't found a way to make things look
"clean").

This is all complicated by the fact that it's an SAP Office Integration
environment, and SAP is having odd effects on things like Document_Open() and
AutoOpen() (like apparently preventing them from executing much of the time
when a document is retrieved from SAP for editing).

Chapter 2 of this thrilling saga follows shortly

Thanks once again,

Peter