RE: OLE Issue while Porting from Perl 5.6 to Perl 5.8

On Tue, 17 Jul 2007, Frank Merrow wrote:
> I suspect this is not so much a Perl 5.8 issue as a "OLE> Upgrade" issue.>> Our Perl 5.6 installation has version 0.1601 of OLE.pm, while the Perl> 5.8 installation installs 0.1707.>> I have an existing COM function that returns a BSTR.>> Under Perl 5.6 if the BSTR is "empty" then Perl returned undef.>> However, under Perl 5.8 if the BSTR is empty then Perl returns the> null string ("").

This is an intentional change in Win32::OLE 0.17 and later. The
vbNullString value from VB is supposed to be treated as an empty string
and not an undefined value. Ideally you should be using VT_NULL and not
VT_BSTR with a NULL pointer to signal an out-of-band value (or VT_ERROR
when you return an error code).

> Unfortunately, the software counts on the undef behavior and returned> empty on error and "" as a valid value (in some cases).>> I'm have multiple inherited classes that I am trying to wade my way> through, but it isn't clear to me at what level the error even occurs.>> I was hoping something as simple as Win32::OLE->Options("Variant")> would fix it, but it doesn't seem to.>> If anyone has any insight to how OLE was changed in these versions I> would appreciate some guidance.

The only workaround I can think of right now (if you cannot
adjust the COM server) is to put the return value into a variant
and then check it:

    my $retval = $obj->method(@args);

would become:

    my $retval = Win32::OLE::Variant->new;
    $obj->Dispatch("method", $retval, @args);
    if ($retval->IsNullString) {
        # V_VT(retval) is VT_BSTR and V_BSTR(retval) is NULL
    }

This will only work with Win32::OLE 0.17 and later, because the
Win32::OLE::Variant::IsNullString() method doesn't exist in earlier
versions.

Cheers,
-Jan