Exception 0x800ac472 when accessing Excel

L

Les Spiro

We have an application that is polling an Excel sheet on
a timer using COM.

On overnight runs we often see OLE Exception with error
code = 0x800ac472.

These often coincide with clicking into Excel from a
screen saver or Windows XP switch to user screens.

If we trap the error and continue things seem OK, but I
was wondering if there is anything we can do to avoid the
exception.

We are running on Excel 2002 under Windows XP SP1

Les
 
B

Bill Lunney

One problem with driving Excel through COM is the unknown state in which
Excel could be in. For example if you want to interact with an Excel
session which is in use by the user some COM calls will not work at certain
times. Can't remember the specific examples I came across but some dialogs
being open etc. would cause the COM call to fail. I never found a way to
trap all of these cases and ended up using workarounds.

You mention 'user screens'. Do you mean Excel forms? Can you also clairfy
if your interacting with an existing Excel session or in your code you are
instantiating a fresh Excel object and using it to load your file etc.

What I did was to trap all known/available errors as best I could and if
when, say getting data from a cell, failed I would just have to assume that
the user was doing something which was blocking the COM call and carry on.

This may account for what you say about trapping the error and continuing.
By doing so you're ignoring the failed call and on the next pass it's
possible Excel is back in a state where it can process the calls as normal.


--

Regards,


Bill Lunney
www.billlunney.com
 
L

Leslie Spiro

Bill,

We're writing to an existing instance, and the code is full of logic to
trap the cases in which it is not safe to write to Excel, this is just
an error code I haven't seen before.

The user screen refers to the logging in after a Switch User on XP.

Thanks for your comments

Les
 
Joined
Mar 10, 2010
Messages
1
Reaction score
0
How to detect failing COM call and carry on regardless?

Bill,

How do you detect when a COM call fails, and manage to carry on regardless? We have a Web server written in Java, to which customers can upload spreadsheets. Other users can then interact with these via a simple Web interface. This interaction may invoke macros in the spreadsheets: like the rest of the interaction, these are called via a Java-COM bridge. Unfortunately, the spreadsheets sometimes have bugs in their VBA, which provoke dialog boxes such as the divide-by-zero one. The spreadsheet then hangs, waiting for someone to press the End button on the dialog box. We're looking for a way to either prevent these dialog boxes occurring (without editing the VBA code: we never see that, because uploads are automatic); or to detect that a dialog box has occurred and remove it. I've described this in detail on the PerlMonks forum at Win32::OLE: how to call Excel VBA macros and catch all VBA errors without dialog boxes appearing?, where I've listed a Perl script that demonstrates the problem, and linked to the (intentionally) buggy spreadsheet it runs. I also link to a post on the Xtreme Visual Basic Talk forum at How to Catch An Excel Runtime Error From a WinForm? . Here, a reply by Microsoft MVP Mike Rosenblum says that when one calls a macro, its VBA code is run in a separate thread, and that therefore, error trapping will not work because the caller cannot trap the error thrown on the callee (the VBA macro)'s thread.

Which language and libraries do you program your COM interface in?

Kind regards
Jocelyn Paine
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top