> But, in Imodel, the 'feSelector' attribute is defined as follows:
> "feSelector": (10349, 2, (9, 0), (), "feSelector", None)
> That 'None' at the end is the "resultCLSID" entry, and apparently
> that's how 'feSelector' is supposed to be connected to 'ISelector'.
> I edited PyFemap.py and manually replaced that 'None' with the
> CLSID from the ISelector definition shown above:
> "feSelector": (10349, 2, (9, 0), (), "feSelector",
'{8A3498F7-A383-419E-8117-86A0305175FF}')
> Problem solved! The code starts using the ISelector class, and I can get
my output argument!
> Swell. Imodel has 315 (three hundred and fifteen) such entries, and there
are hundreds more
> on dozens of other objects, so manual editing to correct all of them is
not feasible.
Eek. So there are 315 map entries you need to adjust?
Note that in the general case, you can probably do:
>>> mod = win32com.client.gencache.EnsureModule(...) # see 'makepy -i' for
details...
>>> selector = some_object.feSelector # now a 'generic' object.
>>> selector = mod.ISelector(selector) # convert to a real ISelector object
But this doesn't really scale either.
> Question: can something be done to makepy to fix this, or this an
> inherent and hopeless flaw in the TLB?
There's not much win32com can do by itself if the typelib doesn't indicate
the type of the param and *also* doesn't provide its CLSID at runtime.
Obviously, you are dealing with a normal python module and normal python
classes, so you could programatically update the dictionaries - but you are
still faced with the problem of knowing what to update the dictionaries
with!
Cheers,
Mark
_______________________________________________
python-win32 mailing list
python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
