Some doc updates in preparation for next release

This commit is contained in:
markm 2006-02-06 23:33:24 +00:00
parent 78ed13aad3
commit 5ab3a06f26
2 changed files with 52 additions and 20 deletions

View File

@ -1,6 +1,6 @@
0.2.0 Significant refactoring
------------------------------------------------
XX-Feb-2006
06-Feb-2006
* Changed how windows are searched for (from application)
This chage should not be a significant change for users
@ -21,14 +21,20 @@ XX-Feb-2006
* Added functionality to associate 'non-text' controls with the 'text' control
closest to them. This allows controls to be referenced by::
app.dlg.ClosetextWindowclass
app.dlg.<Nearby_text><Window_class>
e.g. to reference the "Footer" edit control in the Page Setup dialog you could
use::
app.PageSetup.FooterEdit
* Added a MoveWindow method to HwndWrapper
* Did some more cleanup (fixing pylint warnings) but still not finished
* Added some better support for .NET controls (not to be considered final)
0.1.3 Many changes, few visible

View File

@ -1,19 +1,18 @@
============================================================================
APPLICATION TODO's
PYWINAUTO TODO's
============================================================================
* Need to make Menu items into classes so instead of Dlg.MenuSelect we should
be doing ::
dlg.Menu("blah->blah").Select()
or even ::
dlg.Menu.Blah.Blah.Select()
To do this we need to change how menu's are retrieved - rather than get all
menuitems at the start - then we just get the requested level.
* Maybe supply an option so that scripts can be run by using::
pywinauto.exe yourscript.py
This would work by creating a Py2exe wrapper that would import the script
(and optionally call a particular function?)
This way pywinauto could be made available to people without python
installed (whether this is a big requirement or not I don't know
because the automation language is python anyway!.
* Message traps - how to handle unwanted message boxes popping up?
@ -21,8 +20,8 @@ APPLICATION TODO's
b) set a trap waiting for a specific dialog
c) on calls to window specification, if we fail to find our window then we can
run quickly through the available specified traps to see if any of them apply
- then if they do we can run the associated actions - then try our original
dialog again
- then if they do we can run the associated actions - then try our original
dialog again
* Implement an opional timing/config module so that all timing can be
customized
@ -30,7 +29,7 @@ APPLICATION TODO's
* Handle adding reference controls (in that they should be the controls used
for finding windows)
* Find the reference name of a variable .e.g so that in Dialog._write() we
* Find the reference name of a variable e.g so that in Dialog._write() we
can know the variable name that called the _write on (this we don't have
to repeat the XML file name!)
@ -58,6 +57,7 @@ APPLICATION TODO's
* Investigate using any of the following
- BringWindowToTop: probably necessary before image capture
- GetTopWindow: maybe to re-set top window after capture?
@ -65,9 +65,16 @@ APPLICATION TODO's
- GetGUIThreadInfo
* Make it easy to work with context(right click) menu's
* Make it easy to work with context(right click) menu's
* Look at supporting the Sytem Tray (e.g. right click on an icon)
* Further support .NET controls and download/create a test .NET application
**LOW PRIORITY**
passLOW PRIORITY
* Create a class that makes it easy to deal with a single window (e.g. no
application)
@ -90,6 +97,25 @@ passLOW PRIORITY
dependencies on the various packages
* Need to make Menu items into classes so instead of Dlg.MenuSelect we should
be doing ::
dlg.Menu("blah->blah").Select()
or even ::
dlg.Menu.Blah.Blah.Select()
To do this we need to change how menu's are retrieved - rather than get all
menuitems at the start - then we just get the requested level.
This would also enable things like ::
dlg.Menu.Blah.Blah.IsChecked() IsEnabled(), etc
============================================================================