blogging pywinauto

I guess this little blog will get lost in the flood of PyCon blog stuff - or else everyone will be so busy at PyCon that this entry will stand out (whether that's a good thing or not I am not sure :-)

It sounds like there are one or two people actively using pywinauto - and I am getting some feedback, some bug reports, some suggestions - It's great - but I need to be organized so I don't loose it. So I am going to put some of it here...

First of all there is a Python meetup in Boston on Thursday 9th of March, and if I can get my act together (a Powerpoint presentation and a good demo I guess?) then I will be presenting pywinauto.

So here are the things I want to track

• Some applications implement menu's as Toolbars (Internet Explorer for one) and of course MenuSelect() or MenuClick() doesn't work on those. I need to research if there is some style or setting that says a toolbar button will actually popup a menu. If there is I can update the MenuSelect/MenuClick function to use them, but if not they you will have to document to use one of the following methods:
  app.dlg.TypeKeys("%FWF") # &File->Ne&w->&Folder
  or
  # this functionality is not implemented yet - still
  # need to change the interface to Toolbar buttons.
  app.dlg.Toolbar.Button("File").Click()
  app.PopupMenu.MenuSelect("New->Folder")
  
  For now I should just update the documentation (as I feel that will be the final outcome anyway). Especially as the example given was a control with class WTL_CommandBar (which is a different kettle of fish completely!)
  
• I wanted to add my reasoning for creating pywinauto to the documentation and say why I think it is better then a lot of automation tools out there (the idea at least - I hope the implementation doesn't let it down!)
• Some way of specifying unique text when looking for a control. For example if you look for a control with the text "Click this button to save as PNG" (maybe there are other buttons "Click this button to save as XXX", etc), then it would be nice if app.dlg.PNG.Click() would work - but it doesn't :-(. The reason is that the matching algorithm I use (using difflib) takes the overall text match - and the match of PNG in the overall text is low.
  The reason that I do not just select the best match (original code did do this) is that it matches sometimes when you don't want to. For example if you want to check if a dialog exists for example you could write
  
  if app.dlg.Exists():
  # do something because this dialog exists
  
  but if the searching is not strict enough it will find other dialogs and the script will be broken (and it might be hard to fix). Currently the way around is either specify more of the text:
  app.dlg.ClickbuttontosaveasPNG.Click()
  or use the window_ method...
  app.dlg.window_(title_re =".*PNG$").Click()
  
  One idea was possibly to allow something like
  app.dlg.PNG_IN_.Click()
  or maybe
  app.dlg[".*PNG$_RE_"].Click()
  where the _IN_ and _RE_ specify that the text should be 'in' or should be tested using a regular expression. I am not sure about either of these as they appear to be a bit 'magic'.
• Finish off the Wait* functions. Currently in application.WindowSpecification (which is the class you get if you do app.dlg, or app.dlg.ctrl) there are the following methods:
  Exists(self, timeout = exists_timeout))
  WaitReady(self, timeout = window_find_timeout, wait_interval = window_retry_interval)
  WaitNotEnabled(self, timeout = window_find_timeout, wait_interval = window_retry_interval)
  WaitNotVisible(self, timeout = window_find_timeout, wait_interval = window_retry_interval)
  
  These should all have the same signature, and then I need to fill out the rest of the methods ^Wait(Not)?(Enabled|Visible|Ready)$. Though just writing that and thinking of duplicated lines of code - maybe I should just have a Wait() method e.g.
  app.dlg.control.Wait(enabled = True, Visible = False)
  
  would return the control being waited for once it is both Enabled and Hidden (unlikely to be very useful :-) or return None on timeout (or should it raise an exception?)
  
• Clear up where to look for appropriate methods. Most methods are in the control wrapper for that particular control (or it's base class(es)) but some (important) methods are in WindowManager. So to be clear the available methods for a particular window are the union of
  - methods of WindowSpecification
  - methods of the Wrapper for this control
  - methods of the base class(s) of the wrapper
• Look into pyAA to help getting information from 'difficult' controls (and possibly other uses for it too!)
  
• Then all my various ToDo items:
  - Implement 'application data' that will allow the same script to run on many languages
  - Implement basic Recording functionality
  - Lots more of everything (wrapped controls, tests, examples, documentation, etc)