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
