Somethings are hard and something weren't mean to be easy - but nothing is impossible ;-)

Well I finally managed it. (well 80% of it!).

What am I talking about? 'Application data' where you save information from one run of an automated GUI run and use that information next time to work with changed software (in my case Translated to a different spoken language!).

There is still one small part that I want to implement before I release a 0.3.0 release. Currently it works for dialogs, controls and menu's - but I still need to implement looking up appdata for selecting items in controls (listboxes, treeviews, etc)

The implementation is very basic - and certain things will not work without some form of user override (e.g. selecting the correct item in a sorted listbox/combobox). Unfortunately there is no override available (but I think I will need to look into that soon).

The internal handling of appdata may well change (almost certainly) - but there is very little that a user uses at the moment - so not a big impact I think!

This code does not affect normal operation - so I am not worried about this code causing regressions in the normal use case if just automating a GUI.

So for now I feel I have a working proof of concept - but I think I need to put more work into making it a robust, workable solution.

Passionate users, marketing and screencasts,

Wow - seems like I have at least one passionate user.

Jeff has been helping my make my wiki suck less :-) and he put together a nice little screencast of using pywinauto to automate Notepad.

Please go watch it at: http://pywinauto.pbwiki.com.

He has been coaching me a bit on marketing too - though I can't say pywinauto has the same problem as Python ;-). Though I feel that pywinauto is on the same level as many commercial automation tools, and it uses Python which is so far beyond many automation scripting languages.

Have a good weekend everyone.

Setting the foreground window

Ever found it annoying when you start an application that takes a long time to start up , start working on other things and the application decides to popup and annoy you after/while it starts up?

Well you can now do the same with pywinauto :-)

I had tried to get this right before and hadn't succeeded - but I managed it today. HwndWrapper.SetFocus will now make the window the foreground window - even if it is not the current foreground window.

This was easy enough really - and I had thought that I had tried this already - but obviously hadn't :-(

Here is the new SetFocus method...

    def SetFocus(self):
      """Set the focus to this control

      Activate the window if necessary"""

      # find the current foreground window
      cur_foreground = win32functions.GetForegroundWindow()

      # if it is already foreground then just return
      if self.handle != cur_foreground:

          # get the thread of the window that is in the foreground
          cur_fore_thread = win32functions.GetWindowThreadProcessId(
              cur_foreground, 0)

          # get the thread of the window that we want to be in the foreground
          control_thread = win32functions.GetWindowThreadProcessId(self, 0)

          # if a different thread owns the active window
          if cur_fore_thread != control_thread:
              # Attach the two threads and set the foreground window
              win32functions.AttachThreadInput(
                  cur_fore_thread, control_thread, True)

              win32functions.SetForegroundWindow(self)

              # detach the thread again
              win32functions.AttachThreadInput(
                  cur_fore_thread, control_thread, False)

          else:   # same threads - just set the foreground window
              win32functions.SetForegroundWindow(self)

          # make sure that we are idle before returning
          win32functions.WaitGuiThreadIdle(self)

          # only sleep if we had to change something!
          time.sleep(.06)

      return self

And here is a short bit of code you can test it with

from pywinauto.application import Application
import time

app = Application.start("Notepad.exe")
app.UntitledNotepad.MenuSelect("Format->Font")

for i in range(4):
  time.sleep(2)
  app.Font.Edit1.SetFocus()

If you run that code and work with other windows - then the Notepad Font dialog will popup (annoyingly :-) ) every 2 seconds.

All is left now is to add a call to this method in those other methods that REQUIRE the window to have focus (TypeKeys() for sure, maybe the ...Input() methods - but they probably require a WindowFromPoint/RealChildWindowFromPoint/ChildWindowFromPoint call first to ensure it's necessary).

(all happy with myself for getting that off the todo list - except it wasn't on the todo list :-D )

Released 0.2.5 prior to Boston-PIG meeting

I wanted to roll up my various changes before I give my presentation to Boston-Pig meeting this Thursday.

Also I will be traveling next Monday to Europe for work, that might mean that I can do more work on pywinauto - but it also might mean that I can do much less.

Going forward I have more refactoring to do (probably code breaking - but I can leave methods in and deprecate them for a release or two), and I still need to work on the functionality that allows a script to work unchanged on different langauges.

Have fun :-) - and don't worry about asking me questions or letting me know if you are using pywinauto - I really really don't get a lot of mails :-) (It is only since releasing my own package that I notice how little feedback I have given to others in the past!).

Usability, Consistency - RULES!

I just read an interesting list of "new laws" at http://pfeifferreport.com/trends/trend_userexperience.html (found from http://pyre.third-bit.com/blog/archives/000414.html (found from http://planet.python.org/index.html) .

I find that a number of these resonate strongly with me, and put in words some of what I am trying to achieve with pywinauto.

I should print the list and post it above my desk - then when I go to refactor or add new code I can ask myself if the changes obey the rules :-) (I think 6, 8 and 9 are the ones that will be most useful day to day).

Getting the text of a container control is maybe not that critical for the everyday user of pywinauto - but it should be easy to find if they do need it. Here are some examples of how inconsistent this is at the moment...

  listbox.ItemTexts()[item_index]
  ListView.GetItem(item_index, subitem_index)['text']  # returned item is just a dict
  TreeView.GetItem(0,2,4).Text()
  Header.GetColumnText(col_index)
  Statusbar.GetPartText(part_index) # at least these last two are similar
  Rebar.GetBand(band_index).text # attribute set in returned ctypes structure!

These kinds of inconsistencies do not help anyone learn pywinauto (I hadn't realized it was so bad :-) )

Just as a counter point to above - it's not all so bad.
control.Select() is defined for most classes and behaves (hopefully) more or less as expected.

So - going forward I am going to try and ensure usability and consistency of pywinauto.

The other point is documentation - there IS documentation for pywinauto - but I definitely do not consider myself a tech writer. From reading the rules - it also occurred to me that my documentation is lacking in a major way - it is not easy to find what you are looking for.
I think a new set of pages which describe in a succinct way how to work with controls will help.

E.g.
Operations on controls:

ListBox
     Select
     SetFocus
     GetFocus
ListView
     Select
     IsSelected
     IsChecked
     Check
     UnCheck
     IsFocused
TreeView
     Select
     ...

Even the list by itself helps - in that it would allow you to see what is available more easily then browsing the current documentation.