Automate Windows GUI apps with AutoIt

This article showcases some of our experiences with the automation of Windows GUI applications, featuring the open source tool – AutoIt.

Why automate Windows applications?

We recently had to convert a number of about 250.000 files by using a Windows GUI application that had batch capabilities (thankfully) but no command line interface to take advantage of in a more fruitful manner.

We needed to automate the conversion of files in already classified batches, having 2 distinct process flows that involved going through fixed wizard questions, changing source and destination paths and marking files, while taking care of the output and monitoring the progress, also handling application errors and hangs.

By automating interaction for run configuration, decision taking and reconfiguring in error cases, we drastically reduced this side time to a few minutes.
As we now only needed to keep a distant eye on it, we migrated from human work hours and possible overtime, to continuous runs.

We almost tripled the work speed by also having overnight action.

Although the licensing in our case wouldn’t permit it, just think what you can do when you can use it in a parallel environment…

Scripting our conversion flows

We tried to keep the solution tight, sending commands only to targeted specified controls and keep the automation mechanism locked in. Unfortunately, this wasn’t always possible and we weren’t afraid to use backwoodsman, cut-through barbarisms to complete the given objective.

Having to pick from a range of Windows application automation tools, we settled on using AutoIt to create 2 scripts, one for each of our sequential conversion process. Each script treated a given batch of files, being parameterized by source and destination paths and an optional offset, and closed with specific exit codes depending on success or the types of errors that were commonly happening.

Supervising and monitoring the scenario outcomes

On top of the aforementioned scripts, we created a PHP tool that would take care of the whole process, starting and supervising the AutoIt scripts, taking decisions based on the exit codes (like restarting the conversion, or passing an offset to skip already converted files in case of errors).

Creating the PHP script was pretty straight forward as it could be summed up to parsing source folders, counting files, executing command line scripts, passing directories and tending for exit code cases.

Hands down with AutoIt

Building the AutoIt automation scripts did not prove to be very demanding, having a short learning curve and an abundance of online documentation and forums to get inspiration from. This allowed us to get on track quickly and to implement the solution in a couple of days, including time to test-drive the conversion software, trial and error, and catch the types of failures and hangs.

The actual scripting could be aided by the nice AutoIt Window Information Tool, which helped identifying controls instantly by simply pointing at them. Afterwards, you could easily manipulate the targeted control by simulating key presses and mouse clicks, or even changing it’s attributes directly.

The language was well documented and provided ways to do just about anything we needed, from starting an application with administrator credentials, waiting for windows to come into focus, parsing folders and files, to killing windows, pausing the script’s execution and multiple methods of sending instructions to a control.

The story and takeaways

Handling the success or errors in the conversion software was done by combining an infinite loop with checks for active windows and timeouts. Success was defined by a particular window being inactive, another being active, and no activity for a small period of time. Errors on the other hand were more unstable and couldn’t always be detected by window titles or active focuses, so we also monitored the number of output files in a particular time frame, a way to catch files that would generate hangs and successfully skip past them on the next iteration.

User friendly can be troublesome

Some kind of controls were weird to manipulate, for instance, the file explorer in the newer Windows 7 turns the address bar into a series of folder drop-downs. While we already had the path as a string, we found that simply typing it there did not work, as it was changing focus to the drop-downs along with the letters typed.

In order to get over this behavior and get a text type input, giving focus to the control’s first element and sending an ENTER or SPACE first did the trick.

Some painful controls were avoided, like using a tree type browse window to select a path.

Luckily for us, some paths were easily configurable in text config files and we could skip the extra struggle of searching through this list. 🙂

Technical difficulties…

Other controls we couldn’t get to manipulate at all because they were made unavailable(to AutoIt at least), for example by being used in an [AfxWnd90] type container, which veiled every control inside. This was the case for a long check-box list that contained files we needed to mark. We managed to move beyond by counting the source files and then sending a {SPACE, DOWN} sequence for each file, in order to mark the check-box for all files. In case of conversion failures or application hangs, we counted the output files and skipped a number of marks, already converted files, taking benefit of the list order.

That felt like clubbing the control into submission and obedience, but it worked.

To conclude,

AutoIt proved to be capable of providing a solid automated solution that secured a successful conversion outcome. We also got to build a reusable tool which could easily be integrated into a service, for future use.

Overall, we efficiently avoided a lot of strenuous work-days that would have been necessary to manually complete the task.

Leave a Reply

Your email address will not be published. Required fields are marked *