Poster forgot to CC the list...
--- Begin Message ---
So in the case of the object I'm working with this is "a" correct method of
early binding.
Having all of the possible correct methods of early binding, depending upon
the object implementation, for common object implementations, all laid out
somewhere on a webpage might be handy: then the answer is "use one of these
in this order and it will succeed"!
I still haven't found where I got the method that is working for me. I
failed to document the source. I'm sticking with it.
In the case of your posting quoted here with the object "forced" to what
should be a known implementation does snot actually work for me..
So I have encapsulated the working method and have been able to extend my
implementation to several other objects. For the benefit of others, here
was my final solution (which included all of of the prototype solutions):
import sys
import win32com.client
import traceback
class ComClass:
"""
acquire an object to access COM object from FalconView
Note many different approaches here of which only one works
"""
@staticmethod
def getCom(progId):
com = None
try:
if True: # best working static dispatch
progIdClass =
win32com.client.gencache.GetClassForProgID(progId)
com = progIdClass()
elif False: # from Pg 204 PPW book - complains that manual
methods are required here
win32com.client.gencache.EnsureModule('{CBF10611-4814-11CE-A650-02608C3F42B7}',
4, 0, 8)
com = win32com.client.Dispatch(progId)
elif False: # suggested by mh on webpage - does not work here
dispatch = win32com.client.Dispatch(progId)
progIdClass =
win32com.client.gencache.GetClassForProgID(progId)
com = progIdClass(dispatch)
elif False: # gets dynamic dispatch
com = win32com.client.Dispatch(progId)
else:
raise Exception("no com acquire method selected for
prodId=%s")
except:
traceback.print_stack(file=sys.stderr)
raise
return com
And this is called thusly:
class Map:
...
self.com = ComClass.getCom("FalconView.Map")
...
class Layer:
...
self.com = ComClass.getCom("FalconView.Layer")
self.com2 = ComClass.getCom("FalconView.Layer2")
self.com3 = ComClass.getCom("FalconView.Layer3")
self.com4 = ComClass.getCom("FalconView.Layer4")
self.com5 = ComClass.getCom("FalconView.Layer5")
...
Again, thank you for pywin32. My colleague recently said:
"I don’t envy working COM from Python. I looked into this some time back
and ran away shrieking like a little girl."
You've given me the ability to be brave and to speak confidently in a manly
voice...
, one of which might work for a person given commonSo I think what you're
saying is the prescribed method of static binding since the object does not
describe itself, the dynamic binding takes effect, and since my working
workaround to static is the method of specifying what kind of object is it
a priori that I get a static binding.
On Sun, May 11, 2014 at 7:39 PM, Mark Hammond <skippy.hamm...@gmail.com>wrote:
> On 9/05/2014 1:14 AM, Red Gator wrote:
>
>> Sure I can do that. But after this debacle I find I need to know "why".
>>
>> * Why does my object come up as "win32com.gen_py.None.Map" when it
>>
>> should come up as 'win32com.gen_py.<<fiddly-GUID-bits>>.Map or even
>> "win32com.gen_py.<<library-descriptiojn-with-dots>>.Map. There was
>> some comment that in this state the object would be unusable,
>> whereas this is the object that I have found actually usable.
>> * Pg 203 "Dispatch() [checks] to see if MakePy support exists for the
>>
>> object". Well, I KNOW that the MakePy file is being referenced
>> because I've made manual changes to it and have had those changes
>> show up as new behavior in the application. So why doesn't the
>> Layer.com = Dispatch() work as described?
>>
>
> Unfortunately, these 2 are always down to the implementations of the
> object. When win32com gets an object (eg, as the result of calling some
> function or getting a property) there are ways to ask the object what type
> it is - but this is optional. In short, if the object doesn't describe
> itself, we don't know what it is. As that is all down to the
> implementation of the object, there is no single answer to why that is
> sometimes the case.
>
>
> * What is the necessity in the posting where the COM object class is
>>
>> derived from the Dispatch() object, which I don't appear to be doing
>> in the working case?
>>
>
> I'm not sure I understand the question correctly, but the example you
> refer to is a way for you to say "hey - *I* know what type the object is
> even if the object itself doesn't, so use this for the object"
>
> HTH,
>
> Mark
>
>
--- End Message ---
_______________________________________________
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32
