Have you looked at what the Win32::OLE documentation has to say about _Unique? I don't see how I could provide more information than what its author wrote on the subject.
| [reply]
[d/l] |
from the POD of win32 ole
=item _Unique
The C<_Unique> options guarantees that Win32::OLE will maintain a
one-to-one mapping between Win32::OLE objects and the native COM/OLE
objects. Without this option, you can query the same property twice
and get two different Win32::OLE objects for the same underlying COM
object.
Using a unique proxy makes life easier for tree traversal algorithms
to recognize they already visited a particular node. This option
comes at a price: Win32::OLE has to maintain a global hash of all
outstanding objects and their corresponding proxies. Identity checks
on COM objects can also be expensive if the objects reside
out-of-process or even on a different computer. Therefore this option
is off by default unless the program is being run in the debugger.
Unfortunately, this option doesn't always help. Some programs will
return new COM objects for even the same property when asked for it
multiple times (especially for collections). In this case, there is
nothing Win32::OLE can do to detect that these objects are in fact
identical (because they aren't at the COM level).
The C<_Unique> option can be set to either 1 (enabled) or 0 (disabled,
default).
Its pretty self explanatory. Change it back to 0 if you see a reason.
| [reply] |
So you mean: Eclipse defines &DB::sub, but neglects to define: "$_Unique"?
It seems so. Eclipse has no idea of what Win32::OLE does, and it definitively should not mess with the internals of Win32::OLE. It's worse enough that Eclipse messes with perl at all. It uses some debugger hooks, one of them is &DB::sub (documented in perldebguts). One could discuss if it should do so, but it makes some sense if you want to single-step a perl program from within Eclipse. Win32::OLE also uses debugger hooks. But Win32::OLE is no debugger, not even remotely. It does so because there seems to be no other way to get some information. This is not nice, and the only way to prevent this collision is seems to be to use either Eclipse or Win32::OLE, but not both. You can still write perl code in Eclipse, but use a clean perl from outside Eclipse to run your code. On Windows, a double click on the *.pl file may be sufficient, else open a command prompt and type perl yourscript.pl.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply]
[d/l]
[select] |