Saturday, February 25, 2006

Wow - lots of stuff to try and remember...

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
    # this functionality is not implemented yet - still
    # need to change the interface
    to Toolbar buttons.

    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:

    or use the window_ method...
    app.dlg.window_(title_re =".*PNG$").Click()

    One idea was possibly to allow something like
    or maybe
    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)


  1. Great software! I've been trying to achieve some of this with pyWin32 but I soon get lost, depressed and close-to-suicidal from all the low-level Windows API stuff. pyWinAuto fills the gap! Keep on the good work!

  2. Enough time to create a blog but not enough to create a simple interface doc. Gee, thanks.


  3. Hi anonymous,

    It's not like I waste an inordinate amount of time blogging now is it? :-)

    And if you have some constructive feedback on the documentation provided with pywinauto - I would love to hear it. What do you mean by a "simple interface doc"?

    Maybe "Typical" is people using stuff, complaining about it, not doing the slightest thing to help, and not even giving enough information to enable the author to change anything!


  4. Well put Mark! I love this package! I have been working with other automation software in another language *VB* sucks! I have been playing around with pywinauto for a bit as well as IEC. I'm looking to get the functionality of both in one package and extend both for custom purposes in my scripts. Please don't stop here! pywinauto is just what I've been looking for. I'd like to help if I'm able.

  5. Hi Tim,

    I am interested as to what IEC is. I have not heard of it - and a google search shows up lots of stuff.