Re: [comtypes-users] Problem on access propput and propget functions
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
>
st.HeadCount = 1
> Traceback (most recent call last):
> File "", line 1, in
> 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 "", line 1, in
> TypeError: 'int' object is not callable
st.CommPort
> 0
st.CommPort[1]
> Traceback (most recent call last):
> File "", line 1, in
> 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,
> ##
> ##def SetSV(self):
> ##'-no docstring-'
> ###return Head, NewSetPoint,
> ##
> ##def GetSV(self):
> ##'-no docstring-'
> ###return Head,
> ##
> ##@property
> ##def Connected(self):
> ##'-no docstring-'
> ###return Head,
> ##
> ##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
-
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
Re: [comtypes-users] Events from IUnknown interfaces
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 - 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
Re: [comtypes-users] dyndispatch branch
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 - 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
[comtypes-users] Events from IUnknown interfaces
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
-
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
