[python-win32] Client side COM problems with ByRef parameters

[Mark Hammond]

On 24/08/2010 11:56 PM, mark ferguson wrote:
> and it still didn't change anything! I'd have expected an 'Attribute
> Error' or something like that as I've changed the method name. As a last
> resort I deleted the contents of the gen_py directory, still with no
> effect. So, I'm left thinking that this type lib can't or won't use the
> win32com magic Dispatch support and it's falling back to dynamic
> support. Can anyone suggest what's actually happening here, and any way
> forward?

That seems likely.  The usual reason for this is that the object doesn't 
support runtime calls for the type info, so win32com can't determine the 
makepy object to use.  If you change the Dispatch call to a 
win32com.client.gencache.EnsureDispatch call you will possibly get an 
error informing you about that.  Also, printing the repr of 'lr' should 
give you a clue.

You can probably make things work by manually "wrapping" the Dispatch 
returned object in a generated class.  One approach would be to use 
makepy to generate the code, then move the generated file somewhere else 
then do something like:

import generated_file # the makepy generated file.
lr = win32com.client.Dispatch("wlrun.LrEngine")
lr = generated_file.LrEngine(lr) # wrap it.

The above assumes the class name in the generated file is also LrEngine. 
  You could probably also do it using gencache with something like:

from win32com.client import gencache
klass = gencache.GetClassForCLSID("{clsid-of-the-object}")
lr = win32com.client.Dispatch("wlrun.LrEngine")
lr = klass(lr) # wrap it.

Note that even then, to get reasonable byref behaviour the IDL file for 
the object will need to have specified the "in/out" semantics correctly.

HTH,

Mark