[python-win32] COM question

[Mark Hammond]

> Robert Olson wrote:
>
> > I've tried on and off to use pythonCOM to access the control software
> > for a Gentner AP device (cf www.clearone.com). I ran into problems,
> > and ended up getting the following response from the vendor:
> >
> >> We have looked at the problem and and it relates to how
> automation works
> >> with late binding languages such as VB. APServe was not written to be
> >> friendly with these languages.  The call "Unit.CreateMeter(CHANNEL_1,
> >> METERTYPE_LVL, GRP_I, Meter)" last argument (meter) is passed in
> >> "ByVal".
> >> VB's code completion sees this APServe COM interface method as ByVal
> >> because
> >> VB does not allow the Interface pointer, Meter, to be "Set" through the
> >> argument list via instantiation of the COM object, COMAPMeter.
> >>
> >> The call will work fine with launguges such as Visual C++ or Delphi.
> >> We did
> >> not intend to have users writing software utilizing that interface and
> >> therefore did not add the support in APServe.  Unfortunutly, I do not
> >> know
> >> of a work around for this problem.  I am not familiar enough with
> >> Python to
> >> make any recomendations there either.
> >
> >
> > I'm wondering if that explanation makes sense, and if there's a way
> > python could still be used (I'm pretty shaky on the actual details of
> > COM under the covers).
>
> Python could certainly still be used. I'm pretty COM-savvy and I'm not
> sure I understand at all the explanation above.

I think it may be saying that as the param is "ByVal", VB uses normal object
assignment "Let" semantics rather than "Set" for the param.  Eg, kinda like
saying:
ob = Param
CallFunc(ob)

Rather than:
Set ob = Param
CallFunc(ob)

People unlucky enough to be familiar with VB will recognise the sad, subtle
difference.

However, if this is true, I can see no reason why Python would fail - what
error did you get?

> However if you want to
> get it working in Python you could always write a C++ extension module.
> That should work just dandy. Naturally the problem is that if the
> interface above is complex (and I'm guessing it is) you'll have a lot of
> code to write although none of it should be that difficult.

If you want to get dirty enough, you can coerce pythoncom to pass *any* type
through IDispatch interfaces.  makepy generated code calls _ApplyTypes_ - a
cleverly crafted call to this function can almost certainly pass the object
with the correct semantics, even if the IDL does not match the way the code
actually operates.  Of course, it is simply possible that win32com has never
ever seen a "byval object" before.

Mark.