Dear Robin,
"Robin Houston via RT" <bug-PadWalker@rt.cpan.org> wrote on 21.02.2008
19:04:18:
Show quoted text>
> <URL:
http://rt.cpan.org/Ticket/Display.html?id=33211 >
>
> Hi Oliver,
>
> I am quite interested in getting to the bottom of this, but there is
> not much
> hands-on debugging I can do, without a machine that can run
> Win32::OLE. It may
> well be that you do not have time to pursue this further, which I
> understand.
I know, that you are fully committed to solve the issue and I'm very
thankful for it.
And I'm willing too to do my very best to help in finding the source of the
problem.
Show quoted text> Unfortunately I don't have any specific idea of what the problem
> might be.
> I did wonder whether it could be related to the Win32::OLE module's
> use of
> tied variables. (Simply printing the value of a tied variable can invoke
> arbitrary behaviour, of course.) However, I can't see any specific
> way that
> this would be a problem. Win32::OLE used tied hashes, and the EPIC code
> does not seem to try and print the actual keys and values of a hash.
> (However I don't completely understand how the EPIC system works, and
> I must confess that I haven't used it myself, so perhaps I could be
> mistaken on this point? I suspect not, from what I do understand of the
> code.)
Neither do I, that's reason why I sent the issue to the EPIC (#1898659) and
the Win32::OLE (#33485) team, too.
I created a more general example making use of Excel's COM object instead
of Visual Source Safe.
I think someone from the Win32::OLE team should try to debug the example to
get an idea, whether it's an internal problem, something special with the
EPIC debugger or maybe with the padwalker module.
Unfortunately, I neither have the knowledge nor the debug experience to do
this own my own.
Show quoted text> It is not clear to me, from what you've said, whether the error code
> is being
> inappropriately set, or whether in fact the OLE call is failing, and
> the error
> response is correctly reflecting that.
I think, this is clear, because the OLE calls are executed correctly, but
the return values from LastError() aren't accordingly.
Show quoted text> It seems unlikely to me that the LastError() method plays any part in
> what
> you're seeing, but I could be wrong. You could eliminate the possibility
> by printing the error variable $Win32::OLE::LastError directly,
> rather than
> using the method.
I just tried this, but it didn't change anything. But I agree, that
LastError() maybe just discovers, that there was something wrong
(different) during the last OLE call.
Show quoted text> I think the changes you've made have eliminated the obvious ways that
> the debugging could interfere with your program. What is happening must
> therefore be something I haven't considered yet. If I were debugging
> this
> myself, the next thing I would try would be to recompile Win32::OLE with
> the _DEBUG symbol defined, which will make it print lots of detailed
> information about what it's doing. Comparing the output with and without
> the debugger might yield some new clues.
I agree, that this should be the next step, but I don't feel
instrumented/prepared to do this. So I think, it's more promising, that the
Win32::OLE team have a look on his.
Regards,
Oliver
