Hi Mark, I am able to run MakePy successfully, at least as far as I can tell. Does that affect your conclusion?
Is there any way I can figure out what library it is looking for when I call the following (from your earlier example)? >>> d.GetTypeInfo(0) As that also raises the "library not registered" exception. I've been in some contact with the vendor who supplies us with this, mostly when I started trying to use Python for this purpose. I've recently updated them on my progress, and I'm waiting for a response. Thanks again. Alec On Wed, Sep 17, 2008 at 9:45 PM, Mark Hammond <[EMAIL PROTECTED]> wrote: >> I've taken a look, and I can't say I had an "aha" moment, or anything >> like that, but perhaps I have learned something important. >> >> Setting up the COM object seems very straightforward: >> >> Type t = Type.GetTypeFromCLSID("{e04f970b-53ce-420a-86f8- >> 55374677703d}") >> >> component = (basic.I1)Activator.CreateInstance(t) >> >> component_2 = component as I2 > > Note that many compiled languages only need the typelib at compile time - > once built, they don't need the typelib to be installed and registered on > the target system. This is in contrast to Python, where the typelib is > needed at runtime (unless makepy has been successfully run - the typelib is > then needed at makepy time - which is still at "runtime" unless py2exe etc > is involved). Indeed, the typelib may not even need to be registered on the > build system - just a reference to it on disk by the build process would be > enough. > > So - it still sounds to me that one of the 2 typelibs you rely on aren't > registered, and that your other compiled applications don't notice this. > Have you tried asking the people who supply the binaries you are using? > > Mark > > _______________________________________________ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32