Re: Strange PowerPoint Automation interface failure

OK, I found it. And it isn't a pretty sight.

Here's what happened: one of the file names had a space instead of an
underbar in the
name. As I hovered over the filename, I mistook the name. So the "error"
was not
E_DISP_DISPATCH, it should have been something INFORMATIVE, like "File not
found". Because
this code was apparently never tested (oledisp2.cpp), it was not seen that
a dispatch
error can result in an error that makes the conversion call fail, CHANGING
THE ERROR CODE.

So the obvious solution, you would think, would be to test the file for
existence before I
do the OLE call! So I did something like

DWORD attr = ::GetFileAttributes(filename);
if(attr == INVALID_FILE_ATTRIBUTES)
   { /* failed */
    DWORD err = ::GetLastError();
    ... some stuff to trace the event
    ::SetLastError(err);
    return FALSE;
   } /* failed */

AH, but THIS doesn't work, either! When I return to the caller, the
::GetLastError code
is S_OK (0). Why is this? Because
COleDispatchDriver::~COleDispatchDriver DOES NOT
PRESERVE THE LAST ERROR CODE!!!!!!!!!!!!!! The various OLE interfaces it
calls violate
the principle that "Only a failing API will change the last error code",
and therefore
they always set it to 0. So if you have any class derived from
COleDispatchDriver in the
scope of your function, its destructor changes the error code. This is
obviously a design
failure in the OLE handlers.

I ended up having to throw an exception so I could get the error code back
across the
boundary.

Of course, NONE of this is documented....except it will be in my "errors
and omissions"
document...