Win32::OLE and VT_INT
just running some quick COM code in perl and I notice this: if I call a property or method that returns VT_I4, Win32::OLE maps that to a perl integer in scalar context. When I call a property or method that returns VT_INT, however, it gets mapped to a perl string. Is this deliberate? Is it correct behavior? I can work around my current issue by just doing int() around my values, but it seemed strange to me that these two cases produced slightly different scalars. Thanks, Mike Ellery ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Win32::OLE and VT_INT
On Wed, 09 Jan 2008, Michael Ellery wrote: just running some quick COM code in perl and I notice this: if I call a property or method that returns VT_I4, Win32::OLE maps that to a perl integer in scalar context. When I call a property or method that returns VT_INT, however, it gets mapped to a perl string. Is this deliberate? Is it correct behavior? I can work around my current issue by just doing int() around my values, but it seemed strange to me that these two cases produced slightly different scalars. It is a bug in Win32::OLE: it doesn't handle VT_INT (nor VT_UINT) explicitly and therefore tries to coerce it into VT_BSTR (using VariantChangeTypeEx) before turning it into a Perl scalar. At the Perl level this shouldn't really matter though, as strings are converted back to integers/numbers automatically whenever needed. I don't know why it was never handled explicitly; I just checked, and even the wtypes.h from VC98 lists VT_INT as a valid type for a VARIANT. I'll fix it in a future Win32::OLE release. Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Win32::OLE and VT_INT
Jan Dubois wrote:
On Wed, 09 Jan 2008, Michael Ellery wrote:
just running some quick COM code in perl and I notice this: if I call
a property or method that returns VT_I4, Win32::OLE maps that to a
perl integer in scalar context. When I call a property or method that
returns VT_INT, however, it gets mapped to a perl string. Is this
deliberate? Is it correct behavior? I can work around my current issue
by just doing int() around my values, but it seemed strange to me that
these two cases produced slightly different scalars.
It is a bug in Win32::OLE: it doesn't handle VT_INT (nor VT_UINT)
explicitly and therefore tries to coerce it into VT_BSTR (using
VariantChangeTypeEx) before turning it into a Perl scalar. At the Perl
level this shouldn't really matter though, as strings are converted back
to integers/numbers automatically whenever needed.
I don't know why it was never handled explicitly; I just checked, and
even the wtypes.h from VC98 lists VT_INT as a valid type for a VARIANT.
I'll fix it in a future Win32::OLE release.
Cheers,
-Jan
Jan,
Thanks for the quick response. In my case, I only noticed the behavior
because I am passing the output to another property - and that property
put wasn't expecting a string. It went something like this:
my $foo = $oleObject-Some_VT_INT_Property;
$oleObject-{Some_VARIANT_Property} = $foo;
The VT_TYPE coming into my put_Some_VARIANT_Property was actually
VT_BSTR in this case, which I was not expecting. Simply wrapping int()
around the get call works fine, but a fix to Win32::OLE would be great.
I think I'll also update my VARIANT processing on the put.
Thanks,
Mike
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Win32::OLE and VT_INT
On Wed, 09 Jan 2008, Michael Ellery wrote: The VT_TYPE coming into my put_Some_VARIANT_Property was actually VT_BSTR in this case, which I was not expecting. Simply wrapping int() around the get call works fine, but a fix to Win32::OLE would be great. I think I'll also update my VARIANT processing on the put. I think you should do that. I don't know if there is some normative text about this, but I've seen several references that say that the IDispatch::Invoke implementation is responsible for the coercion of all parameters to the expected type (if possible). E.g. the remarks section of the VariantChangeTypeEx() documentation says: | Typically, the implementer of IDispatch::Invoke determines which | member is being accessed and then calls VariantChangeType to get the | value of one or more arguments. | | For example, if the IDispatch call specifies a SetTitle member that | takes one string argument, the implementor would call | VariantChangeTypeEx to attempt to coerce the argument to VT_BSTR. [from http://msdn2.microsoft.com/en-us/library/aa909107.aspx] Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
