pywinauto/doc_src/TODO.txt

============================================================================
APPLICATION TODO's
============================================================================
* Allow delay after click to be removed. The main reason that this is needed
  at the moment is because if you close a 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!)

* 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()
  

* 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

* 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?

* 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

* Implement an opional timing/config module so that all timing can be 
  customized

* Handle adding reference controls (in that they should be the controls used 
  for finding windows)

* Add referencing by closest static (or surrounding group box?)

* 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).


* 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.
  
  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.

* Need to modularize the methods of the common_controls because at the moment
  they are much too monolithic.


* Investigate using any of the following
   - BringWindowToTop: probably necessary before image capture
   - GetTopWindow: maybe to re-set top window after capture?

   - EnumThreadWindows
   - GetGUIThreadInfo