Hi,

I'm experiencing some unusual behaviour trying to use VB COM through win32ole in Ruby, and I'm hoping someone might
be able to help. I'm using Ruby 1.84-19 (final) here.

I've included the contents of the files I'm using to reproduce these issues below. Note that you need VB6 to build the
COM DLL, but hopefully you'll be able to see what it's doing without this. I've supplied a pre-built version, but it
will need registering on the computer before it works.

If you run the script, you'll find that it calls a VB subroutine that raises an error, and just before this it displays
a dialog window saying "About to raise error...". However, despite the script only containing one call to
this subroutine, when you click OK to dismiss the window it appears again. Is this a bug or is there an explanation
for it?

The script then calls a VB function that returns an empty variant and an uninitialised array in a variant. However,
when Ruby tries to display the contents of the return value it gives different results, namely 'nil' and 'false'. I
was expecting it to display 'nil' in both cases since there is no data available, but perhaps I've misunderstood
something.

Note that until the most recent version, this final call would actually generate a segmentation fault, and although
it seems to work correctly most of the time now, we're still occasionally experiencing this problem (but we can't reproduce
it as example code).

Thanks,

Andrew.

Date: 2007-05-29 17:39
Sender: Andrew Wroe

Hi,

It seems the that in Ruby 1.86-25 at least, the first of 
the problems above has now been resolved.

The second problem is still occuring through, and seems to 
generate a segmentation fault more frequently in fact.

However, I've managed to work around the issue by 
returning a variant containing an array explicitly 
initialised with no elements, rather than a variant 
containing a completely uninitialised array (this amounts 
to the same thing in our application).

I still think this is bug though because VB handles the 
same data gracefully.

If anyone out there has delved into the win32ole code, I 
believe the fix should be relatively easy: it just needs 
to check for the OLE safe array pointer being zero, and 
treat this as being empty. My guess is the segmentation 
fault arises from trying to dereference this pointer.

Anyway, this is no longer a priority for me. I've only 
commented to give someone else a chance at resolving it if 
they choose to do so.

Regards,

Andrew.

Date: 2006-11-02 06:12
Sender: Ryan Davis

We need someone to own the windows platform bugs... anyone?