Thomas Heller | 2 Jan 20:21 2006
Picon

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")]
(Continue reading)

Thomas Heller | 2 Jan 20:27 2006
Picon

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
(Continue reading)

Luke Dunstan | 3 Jan 13:33 2006
Picon

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
Thomas Heller | 4 Jan 13:21 2006
Picon

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
(Continue reading)

Luke Dunstan | 4 Jan 16:01 2006
Picon

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.
(Continue reading)

Thomas Heller | 4 Jan 16:53 2006
Picon

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.
(Continue reading)

Thomas Heller | 4 Jan 17:06 2006
Picon

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
(Continue reading)

Thomas Heller | 6 Jan 17:49 2006
Picon

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
Bob Ippolito | 6 Jan 18:04 2006

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

-------------------------------------------------------
(Continue reading)

Mark Mc Mahon | 6 Jan 23:50 2006
Picon

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

Hi,

I had a look at Watsup and winGuiAuto a while ago and was interested in using it.

I found the non object oriented way of working difficult.

Around the same time I was working on a testing application (not automation) where I was querying many attributes of windows.

I wrote an automation wrapper and built up the code I was using for testing.

I can make this available (as of now I have absolutely no web presence so I could email it - or post it to someone else's server). The zip if around 200kb.

Requirements:
ctypes       http://starship.python.net/crew/theller/ctypes/
Sendkeys     http://www.rutherfurd.net/python/sendkeys/index.html
(Optional)  PIL          http://www.pythonware.com/products/pil/index.htm
(Optional)  elementtree  http://effbot.org/downloads/

Some of the main things that I wanted to avoid were:
 - explicit waits (or waiting when necessary)
 - having to read the dialog first (some automation testing langauges)
 - localization unfriendlyness (as I work in localization mainly) (Not Implemented fully yet)

I am still looking for a name - I am using pywinauto as a temporary one for now.

This is the first time I would have ever released anything so please be gentle.

Here is an example of driving notepad - on my laptop it takes about 1.6 seconds.

---------- :< -----------------------
 import application

 app = application.Application()
 app._start(ur"c:\windows\system32\notepad.exe")
 
 app.Notepad.MenuSelect("File->PageSetup")

 # ----- Page Setup Dialog ----
 # Select the 4th combobox item
 app.PageSetupDlg.ComboBox1.Select(4)

 # Select the 'Letter' combobox item
 app.PageSetupDlg.ComboBox1.Select("Letter")

 # ----- Next Page Setup Dialog ----
 app.PageSetupDlg.Printer.Click()  

 app.PageSetupDlg.Network.Click()
 
 # ----- Connect To Printer Dialog ----
 # Select a checkbox
 app.ConnectToPrinter.ExpandByDef.Check()
 # Uncheck it again - but use Click this time!
 app.ConnectToPrinter.ExpandByDef.Click ()
 
 app.ConnectToPrinter.OK.Click()

 # ----- 2nd Page Setup Dialog again ----
 app.PageSetupDlg2.Properties.Click()

 # ----- Document Properties Dialog ----
 docProps = app._window(title_re = ".*Document Properties")
 
 # Two ways of selecting tabs
 docProps.TabCtrl.Select(2)
 docProps.TabCtrl.Select("Layout")

 # click some Radio buttons
 docProps.RotatedLandscape.Click()
 docProps.BackToFront.Click()
 docProps.FlipOnShortEdge.Click()

 docProps.Portrait.Click()
 docProps._None.Click() # need to disambiguate from keyword None
 docProps.FrontToBack.Click()

 # open the Advanced options dialog in two steps
 advbutton = docProps.Advanced
 advbutton.Click()

 # ----- Advanced Options Dialog ----
 # close the 4 windows
 app._window(title_re = ".* Advanced Options").Ok.Click()

 # ----- Document Properties Dialog again ----
 docProps.Cancel.Click()
 # ----- 2nd Page Setup Dialog again ----
 app.PageSetupDlg2.OK.Click()
 # ----- Page Setup Dialog ----
 app.PageSetupDlg.Ok.Click ()

 # type some text
 app.Notepad.Edit.SetText(u"I am typing säme text to Notepad\r\n\r\nAnd then I am going to quit")
 
 # the following shows that Sendtext does not accept accented characters - but does allow 'control' characters
 #app.Notepad.Edit.TypeKeys(u"{END}{ENTER}SendText döés not süppôrt àcceñted characters", with_spaces = True)
 
 # exit notepad
 app.Notepad.MenuSelect("File->Exit")
 app.Notepad.No.Click ()

---------- :< -----------------------

Future areas for development:
 - Allow saving a dialog and using it as a reference on localised software (so you would run first on English and then you would be able to use the same script on translated software as English)
 - Allow non text controls (comboboxes, listboxes to be referenced by closest Static above and to the left of the control)

Thanks
 Mark

 

Gmane