Re: How to return a pointer to a com interface via an event handler

"Impert, Nicky P" <nicky.p.impert <at> boeing.com> writes:

> I have a python com server that implements an interface where one method
> returns a pointer to a different com interface.  Thomas showed me that
> I could implement it by:
>
>   def CMyClass2_MakeMyClass1(self, this, outptr):
>     # Check against client code passing bad pointers:
>     if not outptr:
>       return E_POINTER
>     iid = obj._com_interfaces_[0]._iid_
>     return obj.QueryInterface(None, ctypes.pointer(iid), outptr)
>
> Instead of returning the pointer to a com interface as an out
> parameter, I would like to return it via an event handler.  I was not
> sure if I should still return a pointer to pointer like I do when the
> com interface is returned as a return value.  So I tried implementing
> it two ways (as a pointer to an interface and as a pointer to pointer
> to an interface), but was not able to get either way to work.  If
> anyone knows how to get this to work (either by fixing one of my
> approaches or by some other method), I would be grateful. --Nicky
>
> ---- idl ----
>     dispinterface _IMyEvent
>     {
>         properties:
>         methods:
>         [id(1000), helpstring("method GetMyClass1a")]
>         HRESULT GetMyClass1a(IMyInterface1 *result);
>         [id(1001), helpstring("method GetMyClass1b")]

Re: Can a coclass implement more than one event handler (dispinterface)?

"Impert, Nicky P" <nicky.p.impert <at> boeing.com> writes:

> Lets say I define the following idl:
>     coclass CMyClass1
>     {
>         [default] interface IMyInterface1;
>         [default, source] dispinterface _IMyEvent1;
>         [source] dispinterface _IMyEvent2;
>     }
>
> Can ctypes.com implement the coclass such that it supports both event
> handlers (dispinterfaces)?  So far, I am under the impression the answer
> is no, but I just wanted that confirmed.  The python ctypes.com code
> would like:
>
> class CMyClass1(DualObjWithEventsImpl):
>     _com_interfaces_ = [IMyInterface1, IConnectionPointContainer]
>     _outgoing_interface_ = _IMyEvent1 # default event handler
>     _outgoing_interfaces_ = [_IMyEvent1, _IMyEvent2]
>
> If I want to send an event using an outgoing interface that is not the
> default outgoing interface (_IMyEvent2), how do I do this?  I know I can
> instead just add the methods of _IMyEvent2 to _IMyEvent1 and thus be
> able to access all the potential outgoing events, but that requires me
> to dirty my idl.

ctypes.com does not support this (unless you implement it yourself).
comtypes will allow this - _outgoing_interfaces_ is a sequence there.

To 'trigger' an event in the source interfaces you will have to call

Python 2.3.5 for Windows CE / ARM (Pocket PC 2003)

A new release of Python for Windows CE is available. Download it here:

http://sourceforge.net/project/showfiles.php?group_id=104228

The release notes are linked from this page, but a direct link is:

http://sourceforge.net/project/shownotes.php?group_id=104228&release_id=382495

Luke

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Thoughts on windows and windows CE

Some thoughts on windows/windows CE:

1. CE doesn't support/require the stdcall calling convention.  To write
'cross-platform' programs, the easiest would be to define 'windll = cdll'
on CE.

(Maybe the distinction between stdcall and cdecl calling convention
should vanish completely.  ctypes is able to detect the wrong calling
convention, so probably it would be better if it would silently be
handled.  The only downside would be that it could no longer detect
passing the wrong number of arguments to stdcall functions.)

2. It seems that CE exports most basic functions from the coredll
library, while windows (NT/2k/XP) exports them from kernel32, user32,
and gdi32.  So it looks like it would be a good idea to define an
object, say 'winapi', 'windows' or however it would be named, that
exposes all the functions in these libraries depending on the platform.

3. It seems that CE has only the wide string ...W variants of most (?)
functions while windows (NT) has both the ...A and ...W versions.
Personally I don't care about win95/98/ME any more, which have only the
...A function variants, so maybe it would be a good idea to have string
arguments to function calls automatically converted to unicode - even
when the .argtypes attribute is not set.  I'm not sure if this should
only be done if the function names ends with a 'W' letter.

Thomas

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files

Re: Thoughts on windows and windows CE

----- Original Message ----- 
From: "Thomas Heller" <theller <at> python.net>
To: <ctypes-users <at> lists.sourceforge.net>
Sent: Wednesday, January 04, 2006 8:21 PM
Subject: [ctypes-users] Thoughts on windows and windows CE

> Some thoughts on windows/windows CE:
>
> 1. CE doesn't support/require the stdcall calling convention.  To write
> 'cross-platform' programs, the easiest would be to define 'windll = cdll'
> on CE.
>
> (Maybe the distinction between stdcall and cdecl calling convention
> should vanish completely.  ctypes is able to detect the wrong calling
> convention, so probably it would be better if it would silently be
> handled.  The only downside would be that it could no longer detect
> passing the wrong number of arguments to stdcall functions.)

By this do you mean that after calling the function, ctypes would check 
whether the stack pointer has changed, and if so then it must be a stdcall 
function because the callee has removed its arguments from the stack? It 
seems a bit strange but I suppose it would work. The stdcall distinction 
still matters for callbacks of course.

> 2. It seems that CE exports most basic functions from the coredll
> library, while windows (NT/2k/XP) exports them from kernel32, user32,
> and gdi32.  So it looks like it would be a good idea to define an
> object, say 'winapi', 'windows' or however it would be named, that
> exposes all the functions in these libraries depending on the platform.

Re: Thoughts on windows and windows CE

"Luke Dunstan" <coder_infidel <at> hotmail.com> writes:

> ----- Original Message ----- 
> From: "Thomas Heller" <theller <at> python.net>
> To: <ctypes-users <at> lists.sourceforge.net>
> Sent: Wednesday, January 04, 2006 8:21 PM
> Subject: [ctypes-users] Thoughts on windows and windows CE
>
>
>> Some thoughts on windows/windows CE:
>>
>> 1. CE doesn't support/require the stdcall calling convention.  To write
>> 'cross-platform' programs, the easiest would be to define 'windll = cdll'
>> on CE.
>>
>> (Maybe the distinction between stdcall and cdecl calling convention
>> should vanish completely.  ctypes is able to detect the wrong calling
>> convention, so probably it would be better if it would silently be
>> handled.  The only downside would be that it could no longer detect
>> passing the wrong number of arguments to stdcall functions.)
>
> By this do you mean that after calling the function, ctypes would
> check whether the stack pointer has changed, and if so then it must be
> a stdcall function because the callee has removed its arguments from
> the stack? It seems a bit strange but I suppose it would work.

Something like that.  I have to check what I hacked into libffi_msvc
months (or years) ago.

> The stdcall distinction still matters for callbacks of course.

Re: Thoughts on windows and windows CE

"Luke Dunstan" <coder_infidel <at> hotmail.com> writes:

> From: "Thomas Heller" <theller <at> python.net>

>> (Maybe the distinction between stdcall and cdecl calling convention
>> should vanish completely.  ctypes is able to detect the wrong calling
>> convention, so probably it would be better if it would silently be
>> handled.  The only downside would be that it could no longer detect
>> passing the wrong number of arguments to stdcall functions.)
>
> By this do you mean that after calling the function, ctypes would
> check whether the stack pointer has changed, and if so then it must be
> a stdcall function because the callee has removed its arguments from
> the stack? It seems a bit strange but I suppose it would work.

libffi_msvc\win32.c, in ffi_call_STDCALL and ffi_call_SYSV save the esp
value into esi before the actual function call.  After the foreign
function call and possible parameter cleanup, they function compare the
current esp value with the previous value in esi, and eventually return
the difference.  Instead of returning and later complaining about a
possible difference, they could as well (after a sanity check) restore
the previous stack value and all should be fine.

Thomas

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Building on OS X 10.4

A questoin for the Mac people:

I'm getting warnings when building the current CVS branch_1_0 on my
(brand new  OS X 10.4 box, about multiply defined symbols: _dlclose,
_dlerror, _dlopen, _dlsym.

When I don't compile in the source/darwin/dlfcn_simple.c file these
warnings disappear.  I cannot remember whether these warnings were also
there on the SF compilefarm 10.2 box, but I don't think so.

Can this source file be removed, or do I have installed something
special that I don't remember?

Thomas

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Building on OS X 10.4

On Jan 6, 2006, at 8:49 AM, Thomas Heller wrote:

> A questoin for the Mac people:
>
> I'm getting warnings when building the current CVS branch_1_0 on my
> (brand new  OS X 10.4 box, about multiply defined symbols:  
> _dlclose,
> _dlerror, _dlopen, _dlsym.
>
> When I don't compile in the source/darwin/dlfcn_simple.c file these
> warnings disappear.  I cannot remember whether these warnings were  
> also
> there on the SF compilefarm 10.2 box, but I don't think so.
>
> Can this source file be removed, or do I have installed something
> special that I don't remember?

Those functions are present in libSystem (libc) on Mac OS X 10.3 and  
later.  It's probably safe to drop it and just say that Mac OS X 10.2  
is no longer supported, the alternative requires a bunch of work.

You can also, of course, just leave it in and live with the  
warning... or modify dlfcn_simple.c and change its function names to  
something else, and use a set of #defines in ctypes to determine  
which names to use.

-bob

-------------------------------------------------------

New Windows automation testing framework using ctypes (similar idea to Watsup/winGuiAuto)