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
_______________________________________________
python-win32 mailing list
python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
