From: MikkelFJ <mikkelfj-anti-spam@...>
Date: 2002-12-02T05:24:51+09:00
Subject: Re: WIN32OLE


"Shannon Fang" <xrfang@hotmail.com> wrote in message
news:20021201171642.EBC5.XRFANG@hotmail.com...
> Hi,
>
> Is there any way to know the oleserver a WIN32OLE object is using? For
> example:
>
>   conn = WIN32OLE.new("ADODB.Connection")
>   p conn.class
>
> which will ouput WIN32OLE, but not ADODB.Connection. How can I tell in
> program what oleserver an ole object is using?

Generally you can't do this easily - not unless the COM object supports an
interface to provide that information.

Typically a COM object is implemented in-proc as a dll. It basically works
exactly like Ruby extensions except different conventions for calling and
discovering methods.
It's a bit like asking what ruby extension does my Ruby object live in.

Below I'll show how you find that dll - it's indirectly also what WINOLE32
does to locate the component.
You ask what "program" it calls. COM generally doesn't call programs -
rather programs call COM components. Thus you won't find any references to
Access2000, Excell or whatever. Basically Excell is a large pile of COM
components with a tiny GUI layer on top.

To find out more about the objects you have to inspect the registry. It's
fairly messy in general, but I'll give you two lookups that will handle most
cases:

My qualified guess is that WINOLE32 calls CoCreateInstance behind the
covers. CoCreateInstance depends on COM classes being registered in a
certain way. The following is how most components are registered:

The registry lookup is in pseudo notation - you'd have to figure out exactly
how to operate the registry from Ruby using som WIN32 API functions or
similar, I'd rather not be bothered with the details but here is the general
approach (you can do this manually using regedit).

First you look up

myclsid = \HKEY_CLASSES_ROOT\ADODB.Connect\CLSID

where you replace "ADODB.Connection" with whatever you want to know about.
This is called the version independent ProgID. You may also specify a
version, for example "ADODB.Connection.1" - this won't change when you
installa new MDAC components, but the first one will be updated to the
latest version.

Anyway, know you have a unique CLSID (128 bit identifier in a common string
format) which maps directly to the physical location of the component. In
order to get this info you execute a second lookup:

\HKEY_CLASSES_ROOT\CLSID\<myclsid>

This yields a directory, where one key is probably "InprocServer32".
The default value in this subkey is the directory to the inproc server, i.e.
the dll.

Mikkel