By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,493 Members | 1,351 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,493 IT Pros & Developers. It's quick & easy.

Trapping Errors Via Automation

P: n/a
Is there a way to trap an error generated in another app that is controlled
via automation? I have an Access 2000 app that opens Word 2000 and proceeds
to open a series of documents and, in each document, parse the contents and
write it to an Access table (the Access app, after opening Word, runs a
macro within Word which parses and writes to the Access app via DAO).

Occasionally we get an error from Word (such as "document is locked for
editing" or other), which hangs the process. The process is an overnight
one, so, obviously, if it hangs from a Word error message.

Is there a way to trap these error messages generated by Word and just move
onto the next document?

Thanks,

Neil
Nov 13 '05 #1
Share this Question
Share on Google+
21 Replies


P: n/a
Why not move the Word Macro to Access VBA code?

Nov 13 '05 #2

P: n/a
Because it was hideously slow when I did it that way. When the Word document
was sent through the pipe to Access for Access to parse, it was very slow.
When I moved the code to a Word macro, allow Word to parse it itself without
sending to Access, and then have Word write to an Access table, it was much
faster (though it still takes a fair amount of time).

But I suppose I could open the Word doc from Access and then just use the
Word macro to parse it. That might work.

Neil
"Chuck Grimsby" <c.*******@worldnet.att.net> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...
Why not move the Word Macro to Access VBA code?

Nov 13 '05 #3

P: n/a
That's a pretty common way to do it. Write the Macro in Word, but call it via
Access automation, and trap errors returned from the call.

On Mon, 09 May 2005 04:42:36 GMT, "Neil" <no****@nospam.net> wrote:
Because it was hideously slow when I did it that way. When the Word document
was sent through the pipe to Access for Access to parse, it was very slow.
When I moved the code to a Word macro, allow Word to parse it itself without
sending to Access, and then have Word write to an Access table, it was much
faster (though it still takes a fair amount of time).

But I suppose I could open the Word doc from Access and then just use the
Word macro to parse it. That might work.

Neil
"Chuck Grimsby" <c.*******@worldnet.att.net> wrote in message
news:11**********************@o13g2000cwo.googleg roups.com...
Why not move the Word Macro to Access VBA code?


Nov 13 '05 #4

P: n/a
No, that's not what I'm saying. I'm saying that I *already* call the macro
via Automation from Access, but don't get error messages in Access to trap.

In one particular example, if the file's already open, a dialog box appears
in Word, "File is locked for editing" or something like that, which screws
up the whole process. As I note below, perhaps if I move the file open
portion of the code to Access, then I'll be able to trap an error (right now
it's in the macro).

But it seems that when one runs a macro via automation, that any errors that
happen through the macro execution are not trappable by the calling
application (in this case, Access). Or do you know of a way of doing that?

Thanks,

Neil
"Steve Jorgensen" <no****@nospam.nospam> wrote in message
news:la********************************@4ax.com...
That's a pretty common way to do it. Write the Macro in Word, but call it
via
Access automation, and trap errors returned from the call.

On Mon, 09 May 2005 04:42:36 GMT, "Neil" <no****@nospam.net> wrote:
Because it was hideously slow when I did it that way. When the Word
document
was sent through the pipe to Access for Access to parse, it was very slow.
When I moved the code to a Word macro, allow Word to parse it itself
without
sending to Access, and then have Word write to an Access table, it was
much
faster (though it still takes a fair amount of time).

But I suppose I could open the Word doc from Access and then just use the
Word macro to parse it. That might work.

Neil
"Chuck Grimsby" <c.*******@worldnet.att.net> wrote in message
news:11**********************@o13g2000cwo.google groups.com...
Why not move the Word Macro to Access VBA code?

Nov 13 '05 #5

P: n/a
Hi Neil,

It sounds as if you need to beef up the error trapping in the Word
macro.

For instance, before trying to open a document in Word, try to open it
as a binary file in a mode that will lock it. If that fails, you'll know
that Word won't be able to open it either, and you can either skip the
file or try making a copy of it and opening that.

If you're not familiar with this article, it's worth reading, as are
some of the articles it links to:
Considerations for Server-Side Automation of Office
http://support.microsoft.com/?id=257757
On Mon, 09 May 2005 09:16:29 GMT, "Neil" <no****@nospam.net> wrote:
No, that's not what I'm saying. I'm saying that I *already* call the macro
via Automation from Access, but don't get error messages in Access to trap.

In one particular example, if the file's already open, a dialog box appears
in Word, "File is locked for editing" or something like that, which screws
up the whole process. As I note below, perhaps if I move the file open
portion of the code to Access, then I'll be able to trap an error (right now
it's in the macro).

But it seems that when one runs a macro via automation, that any errors that
happen through the macro execution are not trappable by the calling
application (in this case, Access). Or do you know of a way of doing that?

Thanks,

Neil
"Steve Jorgensen" <no****@nospam.nospam> wrote in message
news:la********************************@4ax.com.. .
That's a pretty common way to do it. Write the Macro in Word, but call it
via
Access automation, and trap errors returned from the call.

On Mon, 09 May 2005 04:42:36 GMT, "Neil" <no****@nospam.net> wrote:
Because it was hideously slow when I did it that way. When the Word
document
was sent through the pipe to Access for Access to parse, it was very slow.
When I moved the code to a Word macro, allow Word to parse it itself
without
sending to Access, and then have Word write to an Access table, it was
much
faster (though it still takes a fair amount of time).

But I suppose I could open the Word doc from Access and then just use the
Word macro to parse it. That might work.

Neil
"Chuck Grimsby" <c.*******@worldnet.att.net> wrote in message
news:11**********************@o13g2000cwo.googl egroups.com...
Why not move the Word Macro to Access VBA code?


--
John Nurick [Microsoft Access MVP]

Please respond in the newgroup and not by email.
Nov 13 '05 #6

P: n/a
"hideously slow"?!? Then you're doing something wrong, more then just
error trapping.

Usually, it'll go faster.

Nov 13 '05 #7

P: n/a
On 9 May 2005 16:04:52 -0700, "Chuck Grimsby" <c.*******@worldnet.att.net>
wrote:
"hideously slow"?!? Then you're doing something wrong, more then just
error trapping.

Usually, it'll go faster.


That's not my experience. Every COM call that passes across an application
barrier has a lot of overhead. If you're running a loop in Access, making
calls to libraries in Word, there's a real performance hit. The documentation
even says so, and recommends ways to mitigate the problem like calling
functions that take array parameters rather than making individual calls in a
loop.
Nov 13 '05 #8

P: n/a
That's a good idea about the Word macro and checking if the file's open. I
was hoping there was a way to have the calling app actually get any errors
that the automated app experiences. But I guess not.

N
"John Nurick" <j.*************@dial.pipex.com> wrote in message
news:7m********************************@4ax.com...
Hi Neil,

It sounds as if you need to beef up the error trapping in the Word
macro.

For instance, before trying to open a document in Word, try to open it
as a binary file in a mode that will lock it. If that fails, you'll know
that Word won't be able to open it either, and you can either skip the
file or try making a copy of it and opening that.

If you're not familiar with this article, it's worth reading, as are
some of the articles it links to:
Considerations for Server-Side Automation of Office
http://support.microsoft.com/?id=257757
On Mon, 09 May 2005 09:16:29 GMT, "Neil" <no****@nospam.net> wrote:
No, that's not what I'm saying. I'm saying that I *already* call the macro
via Automation from Access, but don't get error messages in Access to
trap.

In one particular example, if the file's already open, a dialog box
appears
in Word, "File is locked for editing" or something like that, which screws
up the whole process. As I note below, perhaps if I move the file open
portion of the code to Access, then I'll be able to trap an error (right
now
it's in the macro).

But it seems that when one runs a macro via automation, that any errors
that
happen through the macro execution are not trappable by the calling
application (in this case, Access). Or do you know of a way of doing that?

Thanks,

Neil
"Steve Jorgensen" <no****@nospam.nospam> wrote in message
news:la********************************@4ax.com. ..
That's a pretty common way to do it. Write the Macro in Word, but call
it
via
Access automation, and trap errors returned from the call.

On Mon, 09 May 2005 04:42:36 GMT, "Neil" <no****@nospam.net> wrote:

Because it was hideously slow when I did it that way. When the Word
document
was sent through the pipe to Access for Access to parse, it was very
slow.
When I moved the code to a Word macro, allow Word to parse it itself
without
sending to Access, and then have Word write to an Access table, it was
much
faster (though it still takes a fair amount of time).

But I suppose I could open the Word doc from Access and then just use
the
Word macro to parse it. That might work.

Neil
"Chuck Grimsby" <c.*******@worldnet.att.net> wrote in message
news:11**********************@o13g2000cwo.goog legroups.com...
> Why not move the Word Macro to Access VBA code?
>


--
John Nurick [Microsoft Access MVP]

Please respond in the newgroup and not by email.

Nov 13 '05 #9

P: n/a
What will go faster? You haven't seen my code, so how do you know how fast
it should go?

Basically the code goes through the Word document one character at a time
and writes strings of characters to a table record when there's a change in
formatting. When Access opened the Word document and then, via the object
variable, parsed the document, looking at each character, it was very slow.
When the process was moved to a Word macro that was called from Access, it
was much faster.

I mean, sure, opening a doc and maybe getting the text is pretty quick. But
this had to look at each character's formatting, etc. Each process of
getting the character's information took x amount of time. When added
together for an entire document, and then multiplied over a couple thousand
documents, it was very slow. Much performance gain when done on the Word
side.

Neil
"Chuck Grimsby" <c.*******@worldnet.att.net> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...
"hideously slow"?!? Then you're doing something wrong, more then just
error trapping.

Usually, it'll go faster.

Nov 13 '05 #10

P: n/a
I agree with what you wrote. The act of calling the Word doc, over and over,
once for each character, was hideously slow.

I would have preferred to keep everything Access-side, but I don't see how I
could accomplish the parsing of the document without a loop, having to look
at each character's formatting.

Neil

"Steve Jorgensen" <no****@nospam.nospam> wrote in message
news:ep********************************@4ax.com...
On 9 May 2005 16:04:52 -0700, "Chuck Grimsby" <c.*******@worldnet.att.net>
wrote:
"hideously slow"?!? Then you're doing something wrong, more then just
error trapping.

Usually, it'll go faster.


That's not my experience. Every COM call that passes across an
application
barrier has a lot of overhead. If you're running a loop in Access, making
calls to libraries in Word, there's a real performance hit. The
documentation
even says so, and recommends ways to mitigate the problem like calling
functions that take array parameters rather than making individual calls
in a
loop.

Nov 13 '05 #11

P: n/a
"Neil" <no****@nospam.net> wrote in
news:rG**************@newsread1.news.pas.earthlink .net:
Basically the code goes through the Word document one character at a
time and writes strings of characters to a table record when there's a
change in formatting.


Perhaps, we should see your code. If you are examining a file byte by byte
then one assumes there is some reason for opening it with a Word Macro, or
processing it with a Word Macro.

If the string of characters is converted to a byte array there might be
considerable improvement in performance.

If the file is opened with low-level file procedures there might be might be
considerable improvement in performance.

--
Lyle
Nov 13 '05 #12

P: n/a
On Tue, 10 May 2005 05:31:03 GMT, "Neil" <no****@nospam.net> wrote:
Basically the code goes through the Word document one character at a time
and writes strings of characters to a table record when there's a change in
formatting. When Access opened the Word document and then, via the object
variable, parsed the document, looking at each character, it was very slow.
When the process was moved to a Word macro that was called from Access, it
was much faster.


If that's what you're having to do, Neil, the thought of saving the
document as XML and then using an XML parser (or maybe just a regex) to
find characters between certain tags sounds pretty appealing.

--
John Nurick [Microsoft Access MVP]

Please respond in the newgroup and not by email.
Nov 13 '05 #13

P: n/a
Right. But the point is that I need to see the formatting of the characters
and place identically formatted characters in the same parsings record.

So, for example, If the document had "My dog" where "dog" was in bold, I'd
end up with "My " in one entry (with values specifying point size, font
name, font weight, etc.) and "dog" in another entry (with same values,
except it would be noted as bold).

In order to accomplish that I need to be able to see the formatting, which
can only be (as far as I can see) done through Word automation. If I open it
with low-level file procedures or store in a byte array, I'll lose the
formatting.

Or am I missing something?
"Lyle Fairfield" <Lo******@FFDBA.Com> wrote in message
news:Xn*******************@216.221.81.119...
"Neil" <no****@nospam.net> wrote in
news:rG**************@newsread1.news.pas.earthlink .net:
Basically the code goes through the Word document one character at a
time and writes strings of characters to a table record when there's a
change in formatting.


Perhaps, we should see your code. If you are examining a file byte by byte
then one assumes there is some reason for opening it with a Word Macro, or
processing it with a Word Macro.

If the string of characters is converted to a byte array there might be
considerable improvement in performance.

If the file is opened with low-level file procedures there might be might
be
considerable improvement in performance.

--
Lyle

Nov 13 '05 #14

P: n/a
Would I be able to read the document in Access directly via an add-in, or
how would I read the documents?
"John Nurick" <j.*************@dial.pipex.com> wrote in message
news:m3********************************@4ax.com...
On Tue, 10 May 2005 05:31:03 GMT, "Neil" <no****@nospam.net> wrote:
Basically the code goes through the Word document one character at a time
and writes strings of characters to a table record when there's a change
in
formatting. When Access opened the Word document and then, via the object
variable, parsed the document, looking at each character, it was very
slow.
When the process was moved to a Word macro that was called from Access, it
was much faster.


If that's what you're having to do, Neil, the thought of saving the
document as XML and then using an XML parser (or maybe just a regex) to
find characters between certain tags sounds pretty appealing.

--
John Nurick [Microsoft Access MVP]

Please respond in the newgroup and not by email.

Nov 13 '05 #15

P: n/a
You're right, I haven't seen you code, nor have you seen mine!

I have a routine I use to convert a Word docuemnt to an HTML file,
which I prefer to use, since I *really* dislike what Word does when you
save a file as an HTML document. Nearly the world's ugliest HTML code,
as far as I'm concerned. But then again... it's trying to be all
things for all things, and the result is probably the best that could
be come up with given those circumstances.

Anyways, it's been a long time since I timed my code, so I just did.
Just under a minute to convert a Word document (with several tables
embedded, but mostly text and a few pictures) to an HTML page. The
word document says it was 36 pages if printed. I haven't had a printer
hooked up to my system from over a decade, so who knows how accurate
that count is.

The code "cheats" a bit by looking at each Word paragraph to determine
if there are any changes to the "standard" font. Just FYI, I guess,
but if you look at each font property, Word will tell you if the
property is the same all the way through the paragraph. The property
returns 0 or -1 if it's the same all the way through the paragraph, if
not, then it returns something that's not 0 or -1. (usually 999999.)
When that's detected, I switch to looking at each word in the
paragraph, doing the same thing with the font properies, and if it
doesn't come back 0 or -1, then it's time to look at each character.

Sure, I suppose I could of looked at each charater from the start, but
why? My goal was mass-processing of word documents to HTML pages, so
the fact that one character was the same as the last didn't really
matter to me, as long as it was the same though the whole paragraph
(which, with the documents I tend to deal with is more often the case
then not. Your milage, as always, may vary.).

Now, mind you, I'm doing this all from Access, using late binding to
Word, since I never know what version my client will be using. But
feel free to do whatever you feel you need to do to accomplish your
goal.

Nov 13 '05 #16

P: n/a
That's an interesting concept. I'm not sure I follow with how you determine
if a font is the same all the way through a paragraph. Perhaps you could
elaborate.

FWIW, I look at font name, font size, font color, bold, italic, and
underline (though, in reality, bold, italic, and underline are really all
that's needed).

Neil
"Chuck Grimsby" <c.*******@worldnet.att.net> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...
You're right, I haven't seen you code, nor have you seen mine!

I have a routine I use to convert a Word docuemnt to an HTML file,
which I prefer to use, since I *really* dislike what Word does when you
save a file as an HTML document. Nearly the world's ugliest HTML code,
as far as I'm concerned. But then again... it's trying to be all
things for all things, and the result is probably the best that could
be come up with given those circumstances.

Anyways, it's been a long time since I timed my code, so I just did.
Just under a minute to convert a Word document (with several tables
embedded, but mostly text and a few pictures) to an HTML page. The
word document says it was 36 pages if printed. I haven't had a printer
hooked up to my system from over a decade, so who knows how accurate
that count is.

The code "cheats" a bit by looking at each Word paragraph to determine
if there are any changes to the "standard" font. Just FYI, I guess,
but if you look at each font property, Word will tell you if the
property is the same all the way through the paragraph. The property
returns 0 or -1 if it's the same all the way through the paragraph, if
not, then it returns something that's not 0 or -1. (usually 999999.)
When that's detected, I switch to looking at each word in the
paragraph, doing the same thing with the font properies, and if it
doesn't come back 0 or -1, then it's time to look at each character.

Sure, I suppose I could of looked at each charater from the start, but
why? My goal was mass-processing of word documents to HTML pages, so
the fact that one character was the same as the last didn't really
matter to me, as long as it was the same though the whole paragraph
(which, with the documents I tend to deal with is more often the case
then not. Your milage, as always, may vary.).

Now, mind you, I'm doing this all from Access, using late binding to
Word, since I never know what version my client will be using. But
feel free to do whatever you feel you need to do to accomplish your
goal.

Nov 13 '05 #17

P: n/a
As previously mentioned, "if you look at each font property, Word will
tell you if the property is the same all the way through the paragraph.
The property returns 0 or -1 if it's the same all the way through the
paragraph, if not, then it returns something that's not 0 or -1.
(usually 999999.) "

Additional hints:
ObjWord.ActiveDocument.Paragraphs(lngP).Range.Form attedText.Font.Bold
ObjWord.ActiveDocument.Paragraphs(lngP).Range.Word s(lngW).FormattedText.Font.Italic
ObjWord.ActiveDocument.Paragraphs(lngP).Range.Word s(lngW).Characters(lngC).FormattedText.Font.Color

Oh, and remember the 0 = False, -1 = True.

It occured to me, after my post, that this code was written for Word97,
and that since that version things might have changed, but I just
checked and it seems to work fine in Word 2003, although I didn't
bother doing any sort of a time test, I just confirmed it works.

Nov 13 '05 #18

P: n/a
I wasn't clear on what was being referred to when you said, "if you look at
each font property." But I see now that you're referring to the font
property of each paragraph. That's a strange and interesting concept, being
able to see if the font changes in the paragraph. Thanks for the tip.

"Chuck Grimsby" <c.*******@worldnet.att.net> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...
As previously mentioned, "if you look at each font property, Word will
tell you if the property is the same all the way through the paragraph.
The property returns 0 or -1 if it's the same all the way through the
paragraph, if not, then it returns something that's not 0 or -1.
(usually 999999.) "

Additional hints:
ObjWord.ActiveDocument.Paragraphs(lngP).Range.Form attedText.Font.Bold
ObjWord.ActiveDocument.Paragraphs(lngP).Range.Word s(lngW).FormattedText.Font.Italic
ObjWord.ActiveDocument.Paragraphs(lngP).Range.Word s(lngW).Characters(lngC).FormattedText.Font.Color

Oh, and remember the 0 = False, -1 = True.

It occured to me, after my post, that this code was written for Word97,
and that since that version things might have changed, but I just
checked and it seems to work fine in Word 2003, although I didn't
bother doing any sort of a time test, I just confirmed it works.

Nov 13 '05 #19

P: n/a
I'm not an XML expert, Neil, so I can't give much practical help. An XML
file is just a text file so it can be read in any number of ways,
although usually it's simplest to use an XML parser. As far as I know
Access 2003's XML capabilities aren't flexible enough for this and it
would be necessary to get some sort of add-in or library.

I'd hoped that you'd be able to rely on the fact that all the formatting
in an XML document is done with tags enclosed in <angle brackets>, while
the text is enclosed by the tags, e.g.
<tag>this is the text.</tag>
Hence any change in formatting is marked by a tag.

The complication is that when Word saves a document as XML it also uses
tags for many things that don't amount to a change in formatting in the
ordinary sense of the word, such as smart tags. This means it's not
sufficient just to look for text between tags, it's also (I guess,
though I don't know exactly what you're trying to do) necessary to
ignore tags that don't correspond to changes in formatting.

I hope this gives you enough to decide whether you should investigate
XML in more detail.
On Tue, 10 May 2005 21:15:08 GMT, "Neil" <no****@nospam.net> wrote:
Would I be able to read the document in Access directly via an add-in, or
how would I read the documents?
"John Nurick" <j.*************@dial.pipex.com> wrote in message
news:m3********************************@4ax.com.. .
On Tue, 10 May 2005 05:31:03 GMT, "Neil" <no****@nospam.net> wrote:
Basically the code goes through the Word document one character at a time
and writes strings of characters to a table record when there's a change
in
formatting. When Access opened the Word document and then, via the object
variable, parsed the document, looking at each character, it was very
slow.
When the process was moved to a Word macro that was called from Access, it
was much faster.


If that's what you're having to do, Neil, the thought of saving the
document as XML and then using an XML parser (or maybe just a regex) to
find characters between certain tags sounds pretty appealing.

--
John Nurick [Microsoft Access MVP]

Please respond in the newgroup and not by email.


--
John Nurick [Microsoft Access MVP]

Please respond in the newgroup and not by email.
Nov 13 '05 #20

P: n/a
<11**********************@o13g2000cwo.googlegroups .com>
<0T*****************@newsread1.news.pas.earthlink. net>
<11**********************@f14g2000cwb.googlegroups .com>
<rG**************@newsread1.news.pas.earthlink.net >
<m3********************************@4ax.com>
<wv**************@newsread2.news.pas.earthlink.net >
Newsgroups: comp.databases.ms-access,microsoft.public.access,microsoft.public.ac cess.interopoledde,microsoft.public.office.develop er.automation,microsoft.public.officedev
NNTP-Posting-Host: 154.196.62.81.cust.bluewin.ch 81.62.196.154
Path: number1.nntp.dca.giganews.com!border1.nntp.dca.gig anews.com!nntp.giganews.com!newshub.sdsu.edu!msrtr ans!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP14.phx.gbl
Lines: 1
Xref: number1.nntp.dca.giganews.com comp.databases.ms-access:821053 microsoft.public.access:174437 microsoft.public.access.interopoledde:10079 microsoft.public.office.developer.automation:9855 microsoft.public.officedev:15703

Hi Neil,
Would I be able to read the document in Access directly via an add-in, or
how would I read the documents?

The documents would be saved as plain text, so theoretically, they could be
opened in Notepad.

This means you could open them in Access same as any other text file and
process them (the old Open and Close commands). That would be one possibility
that's "built into" Office VBA.

Another could be to parse them using MSXML. In either case, though, you'd need
to contend with the WordProcessingML, which could be a real bear, depending on
what you really need to do.
Basically the code goes through the Word document one character at a time
and writes strings of characters to a table record when there's a change
in
formatting. When Access opened the Word document and then, via the object
variable, parsed the document, looking at each character, it was very
slow.
When the process was moved to a Word macro that was called from Access, it
was much faster.


If that's what you're having to do, Neil, the thought of saving the
document as XML and then using an XML parser (or maybe just a regex) to
find characters between certain tags sounds pretty appealing.


Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 8 2004)
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 :-)

Nov 13 '05 #21

P: n/a
Thanks for the note, Cindy. I like the idea of being able to open the files
directly via Open; but parsing through the XML doesn't look like fun. :-)
Either way, I'd still have to open Word via automation to save each file as
XML. So it seems that just continuing to parse it in Word via automation
might still be the best way.
"Cindy M -WordMVP-" <C.*********@hispeed.ch> wrote in message
news:VA.0000ace1.00978704@speedy...
Hi Neil,
Would I be able to read the document in Access directly via an add-in, or
how would I read the documents?

The documents would be saved as plain text, so theoretically, they could
be
opened in Notepad.

This means you could open them in Access same as any other text file and
process them (the old Open and Close commands). That would be one
possibility
that's "built into" Office VBA.

Another could be to parse them using MSXML. In either case, though, you'd
need
to contend with the WordProcessingML, which could be a real bear,
depending on
what you really need to do.
>>Basically the code goes through the Word document one character at a
>>time
>>and writes strings of characters to a table record when there's a
>>change
>>in
>>formatting. When Access opened the Word document and then, via the
>>object
>>variable, parsed the document, looking at each character, it was very
>>slow.
>>When the process was moved to a Word macro that was called from Access,
>>it
>>was much faster.
>
> If that's what you're having to do, Neil, the thought of saving the
> document as XML and then using an XML parser (or maybe just a regex) to
> find characters between certain tags sounds pretty appealing.
>


Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 8 2004)
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 :-)

Nov 13 '05 #22

This discussion thread is closed

Replies have been disabled for this discussion.