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 regis
> 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
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.CreateIn
If you hear a loud slapping sound, that's my hand and forehead. :)
I just recalled that the third-party gives us a test application that
uses the COM component. Including source.
It's in C#, which is new to me, but looks pretty straightforward. I'm
going to figure out how they do, then see if I c
I'm back.
I've taken a crack at rewriting the DLL to export the methods I need
through IDispatch. Unfortunately, what I discovered (and I'm probably
describing this in the wrong way), is that the class is declared
ATL_NO_VTABLE, and as far as I can tell, the third-party app relies on
the interface
(I just noticed my last two responses only went to Mark. They were
intended for the Mailing List and Tim as well. Sorry for the
oversight.)
So I just ran some tests, fruitlessly. Here is what I did:
- Removed all gen_py stuff
- Set registry entries for both interfaces to point to the BASICUHI t
I'm still a little lost too, but:
> * I maintain a dll that defines a class that implements I1 and I2. I
> use regsvr to register this dll.
> * I1 and I2 come from a third party, and in order for my dll to work
> properly, it has to implement them (actually I2 is optional).
> * I don't know how
Alec Munro wrote:
> I've searched through the registry for the GUIDs I found associated
> with the CLSIDs of the classes. They seem to be IIDs of type
> libraries.
>
> The first one, associated with I1, seems to refer to a _basicUHI.tlb
> file that was distributed with SDK the third-party provides
Alec Munro wrote:
> Thanks for the clarification Tim.
>
> My root problem is still the "Library not registered" issue. As far as
> how it was registered:
>
> * I maintain a dll that defines a class that implements I1 and I2. I
> use regsvr to register this dll.
> * I1 and I2 come from a third par
Thanks for the clarification Tim.
My root problem is still the "Library not registered" issue. As far as
how it was registered:
* I maintain a dll that defines a class that implements I1 and I2. I
use regsvr to register this dll.
* I1 and I2 come from a third party, and in order for my dll to w
Alec Munro wrote:
> Ok, perhaps this will be useful.
>
> (Neither of these examples include the core arguments of the methods,
> just the ones specific to InvokeTypes)
>
> What I call a method from I1, it calls _oleobj_.InvokeTypes with the
> following arguments:
>
> 18, 0x0, 1, (24, 0), ((8, 1),)
Ok, perhaps this will be useful.
(Neither of these examples include the core arguments of the methods,
just the ones specific to InvokeTypes)
What I call a method from I1, it calls _oleobj_.InvokeTypes with the
following arguments:
18, 0x0, 1, (24, 0), ((8, 1),)
When I use the method from I2, i
I'm guessing, based on the lack of responses, and the consistency of
error messages, that my problem has more to do with getting the right
library registered, which isn't a python-win job.
So, can anyone recommend where I might go to try to solve this
problem? Also, is there a way to determine whi
Thanks Mark.
After a couple of misfires, I think I figured out how to get CastTo to
work (the docstring is practically non-existent in the version I have,
perhaps it's been updated?).
However, that puts me back at the same place I was with some of the
other attempts:
>>> obj_i2 = CastTo(obj, "In
Look at the docstring for win32com.client.CastTo (and googling for that will
probably help too)
Cheers,
Mark
> I just discovered a third possibility, and subsequent failure:
>
> >>> obj_i2 = Dispatch(obj, None, Interface_2.CLSID)
> >>> obj_i2.secondaryMethod()
> Traceback (most recent call last
I just discovered a third possibility, and subsequent failure:
>>> obj_i2 = Dispatch(obj, None, Interface_2.CLSID)
>>> obj_i2.secondaryMethod()
Traceback (most recent call last):
...
File "C:\Python25\lib\site-packages\win32com\client\__init__.py",
line 449, in _ApplyTypes_
dispid, 0, wFlags
Oh, and on re-reading, I do realize that the DLL itself doesn't
implement those interfaces. There's a class within the DLL that does
that. :)
On Thu, Aug 28, 2008 at 10:32 AM, Alec Munro <[EMAIL PROTECTED]> wrote:
> Hi List,
>
> Hopefully I have my terminology right, I'm pretty new to COM and C++.
Hi List,
Hopefully I have my terminology right, I'm pretty new to COM and C++.
My problem is that I have a COM DLL written in C++, that I would like
to call from Python. This DLL implements 3 important interfaces, each
of which is also an IDispatch implementation, like the following:
IDispatchIm
18 matches
Mail list logo
