From: MikkelFJ <mikkelfj-anti-spam@...>
Date: 2002-12-02T10:05:43+09:00
Subject: Re: WIN32OLE


"Shannon Fang" <xrfang@hotmail.com> wrote in message
news:20021201234814.B9E0.XRFANG@hotmail.com...
> Hi,
>
> Thanks for the info. However, what I want is not to find out the com dll,
> but what did the win32ole obj used. for example,
>
> conn=WIN32OLE.new("ADODB.Connection")
> xl=WIN32OLE.new("Excel.Application")
>
> conn.class==xl.class  >> True
>
> In RUBY program, how can I know if a win32ole object is an instance of
> adodb or excel?

I don't know the details of WIN32OLE, but it could cache the intial argument
to new.
You can easily subclass WIN32OLE to handle this in the case where WIN32OLE
creates the object. However, many objects are not created that way. You
create the top level document object, and the this object creates sheet,
table, cell objects etc. which are just returned to you as if they are
properties or similar. You have no easy way to identify what these returned
objects are.

You can do two things with a COM object: You can see if two objects are
physically identical (comparing IUnknow pointers). And you can ask what
interfaces the object supports (using Query interface).

In dynamic scripting languages like Ruby, it is difficult to work with
multiple interfaces because these are binary interfaces using vtable
function pointers. Instead the functionality of an object is typically
reflected into a single interface IDispatch which WIN32OLE (and other
scripting language COM bindings) understands. IDispatch is (essentially) a
way to execute methods by supplying a name as a string and arguments as an
array. This means that to Ruby all objects are the same type (IDispatch)
except each object may generate error on different method names.

Note that even though objects look the same to Ruby, any COM object,
receiving a reference to another COM object from Ruby, will be able pick the
interface of interest from that object. If such an object doesn't get what
it wants, it'll be upset and either crash, or more likely generate an error
that can be interpreted in Ruby. Therefore you can indirectly check for a
type by spamming a COM object with other objects and see if it gets upset
assuming you can find an appropriate method to do so with. For example,
there may be a method AddSpreadsheet, which will get upset if doesn't
receive spreadsheet objects (of course it has the unfortunate sideeffect of
adding the object in case of success ...).

Perhaps WIN32OLE supports providing info on what interfaces an object
supports, even if you can't use the interfaces directly in Ruby, but I doubt
it. On the other hand, I'd expect WIN32OLE to be able to compare objects for
physical identity.

It is possible to write a COM object in C++ or VB 6.0 which can be operated
from Ruby and provide some of the information you require - this task can be
fairly easy of you write objects that recognizes specific hardcoded
interfaces. This is a cleaner variant of the spamming method described
above.

Mikkel