From: Shannon Fang <xrfang@...>
Date: 2002-12-02T08:50:23+09:00
Subject: Re: WIN32OLE

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?

Shannon
On Mon, 2 Dec 2002 05:24:51 +0900
"MikkelFJ" <mikkelfj-anti-spam@bigfoot.com> wrote:

> 
> "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