171 lines
6.4 KiB
Plaintext
171 lines
6.4 KiB
Plaintext
|
|
============================================================================
|
|
PYWINAUTO TODO's
|
|
============================================================================
|
|
|
|
* Add tests for SendInput click methods
|
|
|
|
* Implement findbestmatch using FuzzyDict.
|
|
|
|
* Find a way of doing application data in a better way. Currently if someone
|
|
even adds a call to print_control_identifiers() it will break the matching
|
|
algorithm!
|
|
|
|
* Need to move the checking if a control is a Ownerdrawn/bitmap control out
|
|
of __init__ methods and into it's own method something like
|
|
IsNormallyRendered() (Why?)
|
|
|
|
* Give example how to work with Tray Window
|
|
|
|
* Fix ToolbarWrapper.PressButton() which doesn't seem to work (found wile working
|
|
on IE example script)
|
|
|
|
* 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?
|
|
|
|
a) Wait for an Exception then handle it there
|
|
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
|
|
|
|
* 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
|
|
can know the variable name that called the _write on (this we don't have
|
|
to repeat the XML file name!)
|
|
|
|
* If we remove the delay after a button click in controlactions then
|
|
trying to close two dialogs in a row might fail because the first
|
|
dialog hasn't closed yet and the 2nd may have similar title and
|
|
same closing button e.g PageSetup.OK.Click(), PageSetup2.OK.Click().
|
|
A possible solution to this might be to keep a cache of windows in the
|
|
application and no two different dialog identifiers (PageSetup and PageSetup2
|
|
in this case) can have the same handle - so returning the handle of PageSetup
|
|
when we call PageSetup2 would fail (and we would do our usual waiting until
|
|
it succeeds or times out).
|
|
|
|
* Investigate using any of the following
|
|
|
|
- BringWindowToTop: probably necessary before image capture
|
|
- GetTopWindow: maybe to re-set top window after capture?
|
|
|
|
- EnumThreadWindows
|
|
- GetGUIThreadInfo
|
|
|
|
|
|
* Make it easy to work with context(right click) menu's
|
|
|
|
* Further support .NET controls and download/create a test .NET application
|
|
|
|
* Look at supporting the Sytem Tray (e.g. right click on an icon)
|
|
|
|
* supply SystemTray class (singleton probably)
|
|
|
|
* Look at clicking and text input - maybe use SendInput
|
|
|
|
* Support Up-Down controls and other common controls
|
|
|
|
* Find out whether control.item.action() or control.action(item) is better
|
|
|
|
* Create a Recorder to visually create tests (being worked on right now)
|
|
|
|
|
|
**LOW PRIORITY**
|
|
|
|
* Create a class that makes it easy to deal with a single window (e.g. no
|
|
application)
|
|
|
|
* Allow apps to be started in a different thread so we don't lock up
|
|
|
|
- this is being done already - the problem is that some messages cannot
|
|
be sent across processes if they have pointers (so we need to send a
|
|
synchronous message which waits for the other process to respond
|
|
before returning)
|
|
|
|
- But I guess it would be possible to create a thread for sending
|
|
those messages?
|
|
|
|
* Liberate the code from HwndWrapper - there is very little this add's beyond
|
|
what is available in handleprops. The main reason this is required is for
|
|
the FriendlyClassName. So I need to look to see if this can be moved
|
|
elsewhere.
|
|
|
|
Doing this might flatten the heirarchy quite a bit and reduce the
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
============================================================================
|
|
CLOSED (in some way or the other)
|
|
============================================================================
|
|
* Allow delay after click to be removed. The main reason that this is needed
|
|
at the moment is because if you close a dialog and then try an action on
|
|
the parent immediately it may not yet be active - so the delay is
|
|
needed to allow it to become active.
|
|
To fix this we may need to add more magic around calling actions on dialogs
|
|
e.g.
|
|
on an attribute access for an ActionDialog do the following:
|
|
|
|
- Check if it is an Action
|
|
- If it is not enabled then wait a little bit
|
|
- If it is then wait a little bit and try again
|
|
- repeat that until success or timeout
|
|
|
|
The main thing that needs to be resolved is that you don't want two of these
|
|
waits happening at once (so a wait in a function at 1 level, and another wait
|
|
in a function called by the other one - because this would mean there would
|
|
be a VERY long delay while the timeout of the nested function was reached
|
|
the number of times the calling func tried to succeed!)
|
|
|
|
* Add referencing by closest static (or surrounding group box?)
|
|
|
|
* Need to modularize the methods of the common_controls because at the moment
|
|
they are much too monolithic.
|
|
|
|
* Finish example of saving a page from IE
|
|
|
|
* Document that I have not been able to figure out how to reliably check
|
|
if a menu item is enabled or not before selecting it. (Probably FIXED NOW!)
|
|
|
|
For Example in Media Player if you try and click the View->Choose Columns
|
|
menu item when it is not enabled it crashes Media Player. Theoretically
|
|
MF_DISABLED and MF_GRAYED should be used - but I found that these are not
|
|
updated (at least for Media Player) until they are dropped down.
|
|
|
|
* Implement an opional timing/config module so that all timing can be
|
|
customized
|
|
|