[python-win32] COM and Makepy when DLL and TLB are separated

[Mark Hammond]

> I checked and the DLL does have its own typelib, however am
> told that this
> is a side effect of the build process and is not needed or
> used.

Note there are 2 main ways tylelibs are used - they are registered, and an
IDispatch object can ask for the type info.  Are you sure the internal one
isn't used at runtime?

It seems strange to bother with the .tlb - I wonder why they don't simply
use the one in the DLL, and not bother shipping the .tlb.

> What I am
> trying to do is use a COM interface built for VB applications
> to access a C
> DLL. We are exploring the possibility of allowing the construction of
> plug-ins to our system in Python instead of VB, which is how
> they currently
> are constructed.

Consider using ActiveScripting.  This will give you VB, VBScript, Python,
JS, Perl, etc ;)  You could even implement this *in* Python, but that is
unlikely to fit your app (ie, you would then *require* Python)

> First step is to make sure that we can
> access the "core" C
> libraries to retrieve and analyse data then step two will be
> to form this
> into a plug-in with exports COM interface to VB master application.
>
> Today: VB Master Application ->COM-> VB plugin ->COM-> COM
> wrapper to C DLL
> Future: VB Master Application ->COM-> Python plugin ->COM->
> COM wrapper to C
> DLL

So from the above, I take it you are currently just trying to do the
"Python -> COM -> COM wrapper to C DLL" part?  The interfaces you need to
define are in the "COM" typelib.  From above, it sounds like you are saying
that there is also a .tlb that goes with the .DLL implementing this "COM"
part.  I also assume that the part implementing "COM wrapper to C DLL" is
yet another DLL, without any COM typeinfo embedded.

So even in this little part, we have Python, the COM dll Python calls, a
.tlb that goes with this DLL, and a final DLL which the COM object calls.

> Eventually we can get this to work we will eliminate the COM
> interface to
> the C DLL, but we will still need the COM interface back to
> the master VB
> application.

I'm not exactly sure what you mean by that - but note that if you want
Python to directly call a C DLL, without COM, you will need the 'ctypes'
module for Python.  Ditto for VBScript (as opposed to VB)

> Given that the wrapper for the DLL is not needed, as a further test, I
> deleted files in the gen_py directory and rebuilt the file
> using makepy from
> the type library only. I can then call create an object from
> the progid
> thus:
>
> tnt = win32com.client.Dispatch("TntCore5_0.DataFilePreprocessor")

The code above will also work with an empty gen_py directory - and I
suspect, will be exactly the same.  If you print repr(tnt), you will find it
is a "dymanic" COM object - ie, late bound, and not using gen_py.

If you try:
tnt = win32com.client.gencache.EnsureDispatch(tnt)

You should find that something in the gen_py directory is generated.  I
suspect you will find this is a *different* typelibrary than the TLB you
expect it is.  As at the top of this mail, the "EnsureDispatch()" will be
asking the object at runtime for the type info.

> However an attempt to invoke the init method produces:
>
> tnt.Initialize()
> Traceback (most recent call last):
>   File "<interactive input>", line 1, in ?
>   File
> "E:\Programs\Python22\lib\site-packages\win32com\client\dynamic.py",
> line 454, in __getattr__
>     raise AttributeError, "%s.%s" % (self._username_, attr)
> AttributeError: TntCore5_0.DataFilePreprocessor.Initialize

Note the exception references "dynamic.py" - if gen_py was being used, the
traceback would reference the gen_py module.

> However I notice that the CLSIDToClassMap is empty:

I suspect this type library does not define the objects, but only the
interfaces.  I suspect the object definitions are in the DLL's typelib, and
you will find them if you select this DLL, or use the EnsureDispatch() code
above.

> Is there an issue because there is no CLSIDToPackageMap? Also
> I notice that
> the Class name is IDataFilePreprocessor. I know that I is for
> interface but
> am not sure when COM used I interface and when it uses the
> method directly.

In general, this is all up to the typelib.  It looks like we have the
interface definitions, but not the CoClasses.

Mark.