An update on where I am at the moment. I managed to find the library that
holds the definition for the GetComponents call. When I run makepy on
this library I get:
def GetComponents(self, oAxisComponentsArray=defaultNamedNotOptArg):
return self._ApplyTypes_(1611005953, 1, (24, 0), ((8204, 3),),
u'GetComponents', None,oAxisComponentsArray)
The problem is that early binding does not work anymore once I have run
makepy on this library (I have no idea why). It seems I end up in Python
with objects that are too high in the type hierarchy. Let me explain. In
order to get to the Position object that holds the calls I need to get
the so-called PartDocument. This PartDocument adds two properties which
don't exist on its parent (Document). When I use early binding before
I used makepy on the library that contains the interface description of
the GetComponents call everything is fine (except of course that the
GetComponents call does nothing). If I run makepy and to the same, I
get back a Document which does not have the property I need to get to
the Position object.
I also tried to use comtypes. The first step is to run GetModule(..) on
the typelibrary. The result I get is as follows:
class Position(Move):
_case_insensitive_ = True
_iid_ = GUID('{50884DF4-9405-11D1-A5E2-00A0C95AF74C}')
_idlflags_ = ['dual', 'oleautomation']
Position._methods_ = [
COMMETHOD([dispid(1611005952)], HRESULT, 'SetComponents',
( ['in'], _midlSAFEARRAY(VARIANT), 'iAxisComponentsArray' )),
COMMETHOD([dispid(1611005953)], HRESULT, 'GetComponents',
( ['in', 'out'], _midlSAFEARRAY(VARIANT),
'oAxisComponentsArray' )),
]
################################################################
## code template for Position implementation
##class Position_Impl(object):
## def SetComponents(self, iAxisComponentsArray):
## '-no docstring-'
## #return
##
## def GetComponents(self):
## '-no docstring-'
## #return oAxisComponentsArray
##
Recipients._methods_ = [
COMMETHOD([dispid(1610940416)], HRESULT, 'Add',
( ['in'], POINTER(BSTR), 'iRecipient' )),
COMMETHOD([dispid(1610940417)], HRESULT, 'RemoveAll'),
]
Afterwards I tried to interact with it as follows:
>>> from comtypes.client import CreateObject
>>> app = CreateObject('Catia.Application')
>>> app.Visible = True
>>> # I then interactively open a document in the application
>>> p1 = app.Documents.Item(2)
>>> p1
<POINTER(Document) ptr=0x577f24 at 4049490>
So again, I get the "wrong" document type. If I do the same
but using late binding (by providing the "dynamic=True"
parameter) I get the following:
>>> p1
<comtypes.client.lazybind.Dispatch object at 0x028387B0>
So I am stuck in a kind of "chicken or egg" problem.
I cannot use the makepy/GetModules generated code,
because it does not allow me to use early binding. If
I use late binding, the calls I am interested (Get/Set
Components) do not work.
What might be an option is to figure out the proper
definition of VARIANT that gets accepted by the
GetComponents call. So after a long post I come to
the following question:
Based on the information provided above generated by
makepy and GetModule(..) can you decipher what the
corresponding VARIANT should look like?
Marco
On Thu, Jul 17, 2014 at 10:51 PM, Marco Nawijn <naw...@gmail.com> wrote:
> Hi Tim,
>
> Ok. I will give it a try and report back. I did a quick search and
> found the TLB files. Never worked with them though, but I will
> take a look.
>
> Marco
>
>
> On Thu, Jul 17, 2014 at 10:22 PM, Tim Roberts <t...@probo.com> wrote:
>
>> Marco Nawijn wrote:
>> > Ok. Another clue (slightly blushing that I didn't notice this before..).
>> > I focus on the Position.GetComponents(...) for the moment.
>> > Recall that this should set the orientation (9 values) and the
>> > position (3 values) by means of an array passed in by reference.
>> >
>> > To my surprise, it returns the same numbers as I put in. So, the
>> > following is happening in the terminal:
>> > >>> l = range(12)
>> > >>> res = p1.Position.GetComponents(l)
>> > >>> print res
>> > (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11)
>> >
>> > The values though are incorrect, I also tried with floats, but the
>> > result is the same. I get back an exact copy of what I put in.
>>
>> That's too bad. That should have been able to work.
>>
>>
>> > Regarding the workaround, can I mix comtypes and win32com?
>> > So, can I only (try) to use comtypes to let this call succeed?
>> > All other calls I have tried work flawlessly with win32com.
>>
>> I'm not sure I can give you a definitive answer. There is a fair amount
>> of overlap between them. You do see sample code on the web that mixes
>> the two, but you're talking about passing an interface between them, and
>> that seems awkward. You probably have experimentation ahead of you.
>>
>> I don't know how extensive is the code you've already done. Comtypes
>> can do everything Pythoncom can do; you may find that it is not that
>> hard to convert, especially if you have a TLB.
>>
>> --
>> Tim Roberts, t...@probo.com
>> Providenza & Boekelheide, Inc.
>>
>> _______________________________________________
>> python-win32 mailing list
>> python-win32@python.org
>> https://mail.python.org/mailman/listinfo/python-win32
>>
>
>
_______________________________________________
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32
