Mon Mar 09 14:52:03 2009: Request 33485 was acted upon.
Transaction: Correspondence added by j...@activestate.com
Queue: Win32-OLE
Subject: RE: [rt.cpan.org #33485] Problem with EPIC debugger and Win32::OLE
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: oliver.k...@linde-le.com
Status: new
Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=33485 >
On Mon, 09 Mar 2009, oliver.k...@linde-le.com via RT wrote:
> So, I had again a look at the bug report #33485 at rt.cpan.org and
> found accidentally, that was added a very brief note: "JDB - Queue von
> libwin32 in Win32-OLE geändert "
No, that was not a bug fix; it just means that all Win32::OLE related
tickets are being copied to the libwin32@perl.org mailing list in
addition to be sent to the maintainers.
> This messages looks like a bug fix, but I'm not sure, because the bug
> status is still on new. What does this message mean? Is the status
> really still on "new"? Should I do something?
I'm not sure there is anything that can be done about this, so I'm not
sure that this really classifies as a bug, and not just as an unwelcome
side-effect.
It is similar to displaying the value of the expression ++$i without
changing the value of $i. You have to save the state of $i, evaluate
"++$i", record the result and then restore $i to its old value.
Similarly accessing any object properties via Win32::OLE will change the
value of Win32::OLE->LastError(). If you don't want that, then you have
to save the value before accessing the properties, and restoring it
afterwards:
my $last_error = Win32::OLE->LastError();
# ... try to display the properties
Win32::OLE->LastError($last_error);
This is the activity the debugger would need to take every time it
displays the value of a property w\of a Win32::OLE object if it doesn't
want to destroy the value of Win32::OLE->LastError(). There is nothing
Win32::OLE can do about this, as it doesn't know if the code is being
called by the user program, or by the debugger.
An OLE property access is not just a simple memory dereferencing
operation; it will typically involve a remote procedure call to a
different process, or possibly even to a remote machine, which can
result in any number of errors. So a property access definitely needs to
set Win32::OLE->LastError.
Note that this problem is not unique to Win32::OLE->LastError() either;
any tied hash or array implementation that has side effects will have
similar problems when a debugger accesses its elements.
I guess I should close this bug as a "known limitation", as any kind of
work-around will have to go into the debugger anyways.
Cheers,
-Jan
