>Message: 4 >Date: Mon, 27 Oct 2008 20:52:09 +0100 >From: Thomas Heller <[EMAIL PROTECTED]> >Subject: Re: [comtypes-users] Problem on access propput and propget > functions >To: comtypes-users@lists.sourceforge.net > >Sorry for this too late reply - I must somehow have overlooked this all the >time.
Well, it's fine. I am glad that you replied my email. In the mean time, we are using the win32com now. But I hope to be able to convert it to comtypes soon because most of the others com object we have are using comtypes. >There is probably a problem with property accesses that use [in, out] >parameters. >Is the com object that you use publicely available somewhere? No, this is a com object use internally in our company. However, I have the source code and I can create some prototype for the com object for testing. I am busy with other stuff now and it is working with win32com now. I will retry again later. and update you if I have any problem. Thanks in advance. Regards, Shin Guey >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:comtypes-users- >[EMAIL PROTECTED] >Sent: Tuesday, October 28, 2008 6:58 PM >To: comtypes-users@lists.sourceforge.net >Subject: comtypes-users Digest, Vol 14, Issue 4 > >Send comtypes-users mailing list submissions to > comtypes-users@lists.sourceforge.net > >To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/comtypes-users >or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > >You can reach the person managing the list at > [EMAIL PROTECTED] > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of comtypes-users digest..." > > >Today's Topics: > > 1. Events from IUnknown interfaces (Erik Wilsher) > 2. Re: dyndispatch branch (Thomas Heller) > 3. Re: Events from IUnknown interfaces (Thomas Heller) > 4. Re: Problem on access propput and propget functions > (Thomas Heller) > 5. Re: Events from IUnknown interfaces (Erik Wilsher) > 6. Re: Events from IUnknown interfaces (Erik Wilsher) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Mon, 27 Oct 2008 14:37:13 +0100 >From: "Erik Wilsher" <[EMAIL PROTECTED]> >Subject: [comtypes-users] Events from IUnknown interfaces >To: comtypes-users@lists.sourceforge.net >Message-ID: > <[EMAIL PROTECTED]> >Content-Type: text/plain; charset="iso-8859-1" > >I have a problem with Fire_Event that I can't figure out, and some help >would be appreciated. The "problem" is probably from my lack of >understanding of COM. > >I have a server with three interfaces, one outbound event interface, and >two >inbound interfaces > > >import "oaidl.idl"; >import "ocidl.idl"; > >[ object, oleautomation, uuid(...),helpstring("The event >interface") ] >interface IServerEvents : IUnknown { > > [id(10)] > HRESULT RunState([in] BSTR app, [in] long state); > > >[object, oleautomation,uuid(...),helpstring("First inbound interface") ] >interface Itest1 : IDispatch { > [id(10), helpstring("Connect the system")] > HRESULT connect([in] BSTR system); > > } > >[ object,oleautomation,uuid(...),helpstring("second interface")] >interface Itest2 : IUnknown { > > [id(30)] > HRESULT register([in] BSTR appname); > > }; > > > > >/*------------ The library interface -------------*/ > >[ > uuid(...), > version(1.0), > helpstring("Test interfaceType library") > ] >library interfaceLib >{ > importlib("stdole2.tlb"); > /*typedef enum deleted, not relevant here*/ > > [ > uuid(...), > helpstring("nterface class object") > ] > coclass testInterface { > [default] interface ITest1; > [default, source] interface IServerEvents; > interface Itest2; > }; >}; > > >---- >The problem is that events fired from Itest2 methods (i.e using a >Fire_Event >within the register method) is never propagated and never reaches clients >that are listening with ShowEvents, while events fired from Itest1 is. The >server is running as a local server, STA. > >I have tried the following combinations on the server side: >self.Fire_Event(0, 'RunState', 'test', 3) >self.Fire_Event(...IServerEvents, 'RunState', 'test', 3) > >Watching the debug output, I can see that the >.connectionpoints._call_sinks(...) is always executed when I call >Fire_Event(), but the object addresses of the ConnectionPointImpl object >are >different depending on where the Fire_Event originates (from Itest1 or >Itest2) > > >-- > -e >-------------- next part -------------- >An HTML attachment was scrubbed... > >------------------------------ > >Message: 2 >Date: Mon, 27 Oct 2008 20:06:58 +0100 >From: Thomas Heller <[EMAIL PROTECTED]> >Subject: Re: [comtypes-users] dyndispatch branch >To: comtypes-users@lists.sourceforge.net >Message-ID: <[EMAIL PROTECTED]> >Content-Type: text/plain; charset=ISO-8859-15 > >Michael Curran schrieb: >> Hi Thomas, >> >> The new changes to the dyndispatch branch sound great. >> >> I'm definitely still interested in the branch, and am hoping that once >> its stable enough that it can be merged in to trunk so I can start using >> it properly in the NVDA project. >> >> I havn't fully tested out all the changes you mentioned yet, but from >> what you have written, they all sound ok to me. I'm also glad you >> decided against any early binding, as they really would have limited >> performance, specially if the user was not going to use a lot of the >> methods on a particular interface. >> >> One thing: comtypes.client.lazybind.NamedProperty. You ask in the >> comments whether or not to support __call__. I would definitely say yes, >> but I don't quite understand what you are doing with __getitem__. >> >> I assume that NamedProperties in COM can have more than one optional >> argument, and if this os so, then calling would be the only way to pass >> more than one argument. From what I can see, at the moment we're >> supposed to do something like bla.accName[0] rather than bla.accName(0)? >> Also, what happens if you want to not provide the optional argument at >all? >> Obviously in python you can't write bla.accName[], but with __call__ you >> could at least do bla.accName() > >The idea was to use always use [...] notation for property accesses with >arguments >(what I call NamedProperties). This is because of the symmetry between >getting and setting: > >print foo[a, b, c] >foo[a, b, c] = something > >Normal properties (not taking arguments) are accessed in the usual way: > >print foo.attr >foo.attr = something > >Ok, so the problem occurs when accessing a property which takes optional >arguments, and you don't want to pass any. Obviously 'foo.attr()' does >work, >but how to set it - 'foo.attr() = something' is invalid syntax, >but 'foo.attr[] = something' and 'print foo.attr[]' are invalid as well. > >AFAIK pywin32 solves that by creating separate setter functions like >'foo._setattr(something)' but I don't like this. > >So I decided to do it differently in comtypes (the approach I describe here >is already implemented for the usual early bound COM calls, but not yet for >the comtypes.client.lazybind or comtypes.client.dynamic module): > >Python lets you call __getitem__(self, index) with any number of arguments, >although the syntax is a little bit strange first. It becomes clearer when >you think of the signature __getitem__(self, *args). Here is an >interactive >session; it shows that you can call x[...] with more one or more arguments: > >>>> class X(object): >... def __getitem__(self, *args): >... print "__getitem__", args >... def __setitem__(self, *args): >... print "__setitem__", args >... >>>> x = X() >>>> >>>> x[()] >__getitem__ ((),) >>>> x[1] >__getitem__ (1,) >>>> x[1, 2] >__getitem__ ((1, 2),) >>>> x[1, 2, 3] >__getitem__ ((1, 2, 3),) >>>> > >The strange thing is that calling 'x[()]' behaves in the same way as the >hypothetical call 'x[]' had been made. >BTW: the same holds for __setitem__(self, *args): > >>>> x[()] = 42 >__setitem__ ((), 42) >>>> x[1] = 42 >__setitem__ (1, 42) >>>> x[1, 2] = 42 >__setitem__ ((1, 2), 42) >>>> x[1, 2, 3] = 42 >__setitem__ ((1, 2, 3), 42) >>>> >>>> > >>>> x[()] = 42 >__setitem__ ((), 42) >>>> x[1] = 42 >__setitem__ (1, 42) >>>> x[1, 2] = 42 >__setitem__ ((1, 2), 42) >>>> x[1, 2, 3] = 42 >__setitem__ ((1, 2, 3), 42) >>>> >>>> > >One obvious fault of the above is that it is impossible to access >properties >with named arguments (but comtypes.client.dynamic and >comtypes.client.lazybind >does not accept named arguments anyway in methods currently). > >Thomas > > > > >------------------------------ > >Message: 3 >Date: Mon, 27 Oct 2008 20:08:51 +0100 >From: Thomas Heller <[EMAIL PROTECTED]> >Subject: Re: [comtypes-users] Events from IUnknown interfaces >To: comtypes-users@lists.sourceforge.net >Message-ID: <[EMAIL PROTECTED]> >Content-Type: text/plain; charset=ISO-8859-15 > >Erik Wilsher schrieb: >> I have a problem with Fire_Event that I can't figure out, and some help >> would be appreciated. The "problem" is probably from my lack of >> understanding of COM. >> >> I have a server with three interfaces, one outbound event interface, and >two >> inbound interfaces >[...] >> ---- >> The problem is that events fired from Itest2 methods (i.e using a >Fire_Event >> within the register method) is never propagated and never reaches clients >> that are listening with ShowEvents, while events fired from Itest1 is. >The >> server is running as a local server, STA. >> >> I have tried the following combinations on the server side: >> self.Fire_Event(0, 'RunState', 'test', 3) >> self.Fire_Event(...IServerEvents, 'RunState', 'test', 3) >> >> Watching the debug output, I can see that the >> .connectionpoints._call_sinks(...) is always executed when I call >> Fire_Event(), but the object addresses of the ConnectionPointImpl object >are >> different depending on where the Fire_Event originates (from Itest1 or >> Itest2) > >Are you writing both the server and the client code in comtypes? Are you >able to strip it down to a small selfcontained test case, and post the code? > >-- >Thanks, >Thomas > > > > >------------------------------ > >Message: 4 >Date: Mon, 27 Oct 2008 20:52:09 +0100 >From: Thomas Heller <[EMAIL PROTECTED]> >Subject: Re: [comtypes-users] Problem on access propput and propget > functions >To: comtypes-users@lists.sourceforge.net >Message-ID: <[EMAIL PROTECTED]> >Content-Type: text/plain; charset=ISO-8859-15 > >Wong, Shin Guey schrieb: >> I am still new to comtypes. Now, I am facing some problems on >> accessing com dll with propput and propget. All other methods is >> working fine as along as it it not a propput and propget methods. How >> do I access those methods, am I doing something wrong? >> > >Sorry for this too late reply - I must somehow have overlooked this all the >time. >There is probably a problem with property accesses that use [in, out] >parameters. >Is the com object that you use publicely available somewhere? > >> Here is the python console I use to call those methods: >> =================================================================== >>>>> from comtypes.client import CreateObject st = >>>>> CreateObject("vbSiThermalCOM.clsVBSiThermalClass") >>>>> st.HeadCount >> <comtypes.bound_named_property object at 0x00C772F0> >>>>> st.HeadCount = 1 >> Traceback (most recent call last): >> File "<stdin>", line 1, in <module> >> File "c:\python25\lib\site-packages\comtypes\__init__.py", line 238, in >__setattr__ >> value) >> TypeError: __set__() takes exactly 2 arguments (3 given) >>>>> st.CommPort(1) >> Traceback (most recent call last): >> File "<stdin>", line 1, in <module> >> TypeError: 'int' object is not callable >>>>> st.CommPort >> 0 >>>>> st.CommPort[1] >> Traceback (most recent call last): >> File "<stdin>", line 1, in <module> >> TypeError: 'int' object is unsubscriptable >=================================================================== >> >> >> Here is the generated python script by comtypes: >> =================================================================== >> COMMETHOD([dispid(1745027074), 'propput'], HRESULT, 'HeadCount', >> ( ['in', 'out'], POINTER(c_short), 'None' )), > COMMETHOD([dispid(1745027074), 'propget'], HRESULT, 'HeadCount', >> ( ['retval', 'out'], POINTER(c_short), 'None' )), > > COMMETHOD([dispid(1745027073), 'propput'], HRESULT, 'CommPort', >> ( ['in', 'out'], POINTER(c_short), 'Head' ), >> ( ['in', 'out'], POINTER(c_short), 'None' )), >> >> ################################################################ >> ## code template for _clsVBSiThermalClass implementation ##class >_clsVBSiThermalClass_Impl(object): >> ## def _get(self): >> ## '-no docstring-' >> ## #return >> ## def _set(self): >> ## '-no docstring-' >> ## CommPort = property(_get, _set, doc = _set.__doc__) >> ## >> ## def Disconnect(self): >> ## '-no docstring-' >> ## #return >> ## >> ## def GetPV(self): >> ## '-no docstring-' >> ## #return Head, <unnamed> >> ## >> ## def SetSV(self): >> ## '-no docstring-' >> ## #return Head, NewSetPoint, <unnamed> >> ## >> ## def GetSV(self): >> ## '-no docstring-' >> ## #return Head, <unnamed> >> ## >> ## @property >> ## def Connected(self): >> ## '-no docstring-' >> ## #return Head, <unnamed> >> ## >> ## def Connect(self): >> ## '-no docstring-' >> ## #return >> ## >> ## def _get(self): >> ## '-no docstring-' >> ## #return >> ## def _set(self): >> ## '-no docstring-' >> ## CommDevice = property(_get, _set, doc = _set.__doc__) >> ## >> ## def _get(self): >> ## '-no docstring-' >> ## #return >> ## def _set(self): >> ## '-no docstring-' >> ## HeadCount = property(_get, _set, doc = _set.__doc__) >> ## >=================================================================== >> > >-- >Thanks, >Thomas > > > > >------------------------------ > >Message: 5 >Date: Tue, 28 Oct 2008 11:44:34 +0100 >From: "Erik Wilsher" <[EMAIL PROTECTED]> >Subject: Re: [comtypes-users] Events from IUnknown interfaces >To: comtypes-users@lists.sourceforge.net >Message-ID: > <[EMAIL PROTECTED]> >Content-Type: text/plain; charset=ISO-8859-1 > >After some further digging and testing with other COM-servers, I found >out that I was creating new objects in my client code, rather than >connecting to the active object. So the hurdle now is to register an >instance of my COM-server (written using comtypes) as the active >object in the ROT. This is quite challenging, and I've tried various >combinations of RegisterActiveObject without any success. Any clues >on how to register an instance would be most welcome. > > > >------------------------------ > >Message: 6 >Date: Tue, 28 Oct 2008 11:44:34 +0100 >From: "Erik Wilsher" <[EMAIL PROTECTED]> >Subject: Re: [comtypes-users] Events from IUnknown interfaces >To: comtypes-users@lists.sourceforge.net >Message-ID: > <[EMAIL PROTECTED]> >Content-Type: text/plain; charset=ISO-8859-1 > >After some further digging and testing with other COM-servers, I found >out that I was creating new objects in my client code, rather than >connecting to the active object. So the hurdle now is to register an >instance of my COM-server (written using comtypes) as the active >object in the ROT. This is quite challenging, and I've tried various >combinations of RegisterActiveObject without any success. Any clues >on how to register an instance would be most welcome. > > > >------------------------------ > >------------------------------------------------------------------------- >This SF.Net email is sponsored by the Moblin Your Move Developer's >challenge >Build the coolest Linux based applications with Moblin SDK & win great >prizes >Grand prize is a trip for two to an Open Source event anywhere in the world >http://moblin-contest.org/redirect.php?banner_id=100&url=/ > >------------------------------ > >_______________________________________________ >comtypes-users mailing list >comtypes-users@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/comtypes-users > > >End of comtypes-users Digest, Vol 14, Issue 4 >********************************************* ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ comtypes-users mailing list comtypes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/comtypes-users
