Word giving bogus error message "Insufficient memory"

[Fly Girl]

Hi,

Hope someone has figured out a way around this one. I've
seen lots of posts, but no solutions.

Access 2K to Office 2K.

I'm messing with embedded OLE objects with the following
code:

Dim obj As Control
Dim app As Word.Application
Dim doc As Word.Document

Set obj = Me!ctlOLE ' OLE container control on form
obj.Action = acOLEActivate 'opens the file in Word

Set app = GetObject(, "Word.Application")
Set doc = app.ActiveWindow.Document 'errors on this line

doc.SaveAs strFilePath & ".doc"

Set app = Nothing
Set doc = Nothing

Error message: "There is insufficient Memory. Save the
document now"


Sometimes this works perfectly, once. Then all further
calls fail.

This just started after updating my system on office and
windows service packs--GRRRR!

Any suggestions?

 

[Jonathan West]

Hi Fly Girl

Before Set app = Nothing I would recomemnd you also have the following line

app.Quit SaveChanges:=wdDoNotSaveChanges

I suspect that what is happening is that there are copies of Word being left
over, which are not closed simply by deleting the reference to them

 

[Fly Girl]

Thanks for the idea, but actually the application is
closed when I run the line

obj.Action = acOLEClose

which I didn't include in my code snippet below.

It is my general assumption that if you use OLE to open
the instance, it's nicer to use OLE to close it than to
close the app via other mechanisms. Just for kicks I tried
putting an app.Quit after the obj.Action = acOLEClose and
that didn't improve the situation at all. Also Task
manager does not show Winword.exe running when it
shouldn't.

Any other ideas?

G

 

[Jonathan West]

Thanks for the idea, but actually the application is
closed when I run the line

obj.Action = acOLEClose

which I didn't include in my code snippet below.

It is my general assumption that if you use OLE to open
the instance, it's nicer to use OLE to close it than to
close the app via other mechanisms. Just for kicks I tried
putting an app.Quit after the obj.Action = acOLEClose and
that didn't improve the situation at all. Also Task
manager does not show Winword.exe running when it
shouldn't.

Any other ideas?

Memory errors in Word are rarely caused by anything as simple & obvious as
running out of memory. They are normally cause because Word has got itself
confused for reasons it can't quite fathom, so out of memory is its standard
"Help, I'm stuck!" call.

Document corruption can be a common cause, so it would be worth closing Word
and then renaming the normal.dot file. Word will create a new one
automatically when you restart it.

If your application uses an existing document or template, it might be worth
rebuilding that document, by creating a fresh blank document and then
copying the content of the old document (not including the final paragraph
mark) into it.

You might also want to explore the possible problems described in this
article

Problems opening Word
http://www.mvps.org/word/FAQs/AppErrors/ProbsOpeningWord.htm

Finally, I'm not that familier with OLE container controls in Access, but
I'm wondering whether you are sure that the object contained in the OLE
container control is actually a Word document object?

 

[Fly Girl]

I had found this thing about a corrupt normal.dot. I'll
give it a try. Right now I'm just testing this process on
a clean Win2K machine (new installation, no service packs)
where everything works fine.

One thing I should mention is that all this started after
the IT guys here got overzealous and pushed out all the
windows and office updates. After that a lot of my OLE
code started going splat where it interfaces with other
applications, e.g. Imaging for Windows and Acrobat, Word
still ran this code at that point. Worse, they then tried
to uninstall service packs to see if things would start
working again... Probably not a great idea but some code
did start to work again. Unfortunatly that's when Word
started to get cranky. I've tried to re-install the
windows and office updates but that has not restored Word
for this automation hiccup.

The issue is not that Word won't open, just that I can't
assign the open document to a variable in order to force a
save as. Since the updates, the file menu in Word
has "Save Copy As" instead of "Save As" when the embedded
object opens. I think I know why they changed this, and
it's a good thing, but if I can no longer pull off my
automation it's just a tad awkward.

Thanks for the input. Have a great holiday!

 

[Cindy M -WordMVP-]

Hi Fly,

Dim app As Word.Application
Dim doc As Word.Document

Set obj = Me!ctlOLE ' OLE container control on form
obj.Action = acOLEActivate 'opens the file in Word

Set app = GetObject(, "Word.Application")
Set doc = app.ActiveWindow.Document 'errors on this line

doc.SaveAs strFilePath & ".doc"

Set app = Nothing
Set doc = Nothing

Error message: "There is insufficient Memory. Save the
document now"

I think part of your problem is that you shouldn't need to do
both acOLEActivate AND GetObject. Based on my experience with
OLE-object in Word and Excel, you should be able to pick up
the actual Word OLE object (probably a document) through the
obj properties, once it's been activated. In Word, it would
be something like set doc = obj.OLEFormat.Object.

You then say you release the Word application through OLE,
because that's how you activated it. But having used
GetObject in addition *may* still be interfering with this.

In any case, when I automate say, an Excel worksheet embedded
in a Word document, I *do* have to explicitly end the
application using app.Quit to avoid leaving Excel running in
the background. OTOH, Word has no equivalent of the
acOLEClose you mention. (Also: "app.Quit after the obj.Action
= acOLEClose". Since you used GetObject AFTER activating the
OLE object, you should use app.Quit BEFORE acOLEClose)

What I'm trying to say is, you do need to explore this path,
as well as "corrupt files". I tend to think the problem does
lie more in the OLE. Have you checked in the Windows Task
Manager for stray winword.exe after you've run the code?

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

 

[Fly Girl]

Hi Cindy,

Thanks for the post. Actually the problem was completely
resolved by running a restore process on MS Office.
Everything works fine. Regarding your post, GetObject will
just grab an open instance of Word. Do you have any source
for the "doc = obj.OLEFormat.Object"? This doesn't look
like anything I've seen for automating OLE objects. To use
the control object to grab the application you can use

set obj = ctrl.object.application

However, I've had some problems with this. The utility
that this code belongs to is run on an isolated machine so
I don't have to worry about grabbing the wrong instance of
an application. If I know I'm looking for a particular
object it seems to be better to specifically grab that
object.

Regarding obj.action = acoleclose, realize that the object
in question is the OLE container control that is holding
the database Word file object, not the Word application or
document object. This is a perfectly legitimate way of
closing the application associated with the OLE control on
the form. Adding app.quit is just gratis and is does not
actually do anything unless OLE fails to close and destroy
the application object.

When I was receiving the error, there were never any stray
winword.exe's running.

Doing all of this from a form while using file OLE objects
that are contained in a database is a little different
than automating the objects from within one of the
applicaitons.

 

[Cindy M -WordMVP-]

Hi Fly,

Actually the problem was completely
resolved by running a restore process on MS Office.
Everything works fine.

Good, I'm relieved to hear it

My other thoughts were based on my experience working with
OLE object in Word (and a little in Excel). It's quite
possible that the interface works quite differently in
Access; seems it must be somewhat easier to handle, from
what you describe! We have to be very careful, when
automating embedded objects (especially in a loop) to make
sure the underlying applications are properly released or
we do run into massive memory problems.

Cindy Meister