Windows Desktop Applications Automation using AutoIt

[r0ash]

This write up target developers who want to automate Windows Desktop Applications but either do not know the right tool or want to enhance their skills using AutoIt.

Just like with any thing, there is either informed or amateur approach towards solving a problem. Developers who have never written Windows GUI applications will write AutoIt code that will depend too much on interactions with active GUI. While we can get maximum out of AutoIt when we rely less over such interactions. This amateur approach creates real issue when we have to interact with multiple desktop applications within same AutoIt script.

One solution to address these issues is to use _WinAPI_PostMessage function, where applicable. We will primarily use this function to interact with menus, otherwise our interactions may occur on wrong window.

Intent:

Want to automate Notepad;

• change display font
• write some text and
• save file

Downloads:

• AutoIt Full Installation
• AutoIt Script Editor
• GUI Inspection Tools:
  • AutoIt Window Info (part of AutoIt Full Installation)
  • Inspect

GUI Inspection:

In order to control GUI elements we will need the Windows Name, Controls ClassNameNN & Automation Ids of Notepad application. If you dont know how to find them using AutoIt Window Info and Inspect tools, watch this video (enable captions, if you want).

Windows GUI Inspection using AutoIt Window Info & Inspect Tools

 

expandcollapse popup

#include "WinAPI.au3"
#include "WindowsConstants.au3"
 
 
; #INDEX# =======================================================================================================================
; Title .........: Windows Desktop Applications Automation using AutoIt
; AutoIt Version : 3.3.14.2
; Description ...: Automate Notepad for changing display font, writing some text and save file
; Author(s) .....: Ahmed Shaikh Memon (ahmedshaikhm)
; ===============================================================================================================================
 
 
; #VARIABLES# ===================================================================================================================
Local $hWnd, $hWndFont, $hWndSaveAs
Global $sFontName = "Arial"
Global $sFileName = "tutorial_1"
 
; #CONSTANTS# ===================================================================================================================
Global Const $__IDM_FONT = 33
Global Const $__IDM_SAVE = 3
Global Const $__IDC_FONT_NAME = 1001
 
; Open Notepad
Run("notepad.exe")
Sleep(1000)
 
; Get Notepad's handle
$hWnd = WinGetHandle("[Class:Notepad]")
 
;
; Display Font Change
;
 
; Click Format > Font menu
_WinAPI_PostMessage($hWnd, $WM_COMMAND, $__IDM_FONT, 0)
Sleep(1000)
 
 
; Handle Font window
$hFontWin = WinGetHandle("Font")
Sleep(1000)
 
; Select display font
ControlSend($hFontWin,"", $__IDC_FONT_NAME, $sFontName)
Sleep(2000)
 
; Save display font
ControlClick($hFontWin, "", "Button5")
Sleep(1000)
 
;
; Write text in Notepad
;
ControlSend($hWnd, "", "Edit1","This is informed approach towards solving a problem")
 
;
; Save file
;
 
; Click File > Save menu
_WinAPI_PostMessage($hWnd, $WM_COMMAND, $__IDM_SAVE, 0)
Sleep(1000)
 
; Enter file name in the file open dialog box
$hWndSaveAs = WinGetHandle("Save As")
ControlSend($hWndSaveAs, "", "Edit1", $sFileName)
Sleep(1000)
 
; Press the Save button on Save As prompt
ControlClick($hWndSaveAs, "", "Button1")
Sleep(1000)

The complete blog post can be found at Teemya Blog.

[JLogan3o13]

So your "professional" approach has zero error checking. If, for some reason, your initial program fails to launch, you continue on through the script throwing error after error (unbeknownst to the user as there is nothing catching those errors). There are already threads on this forum dedicated to best practices when coding in AutoIt:

https://www.autoitscript.com/wiki/Best_coding_practices

 

[qwert]

@r0ash: thanks for this.  It brings several window control methods together in a clear example.

But there's one area that I don't quite follow.  You make this statement on your blog:

Quote

$__IDM_FONT & $__IDM_SAVE are Menu IDs for sub-menus Font and Save respectively. We’ve identified them using Inspect tool. $__IDC_FONT_NAME is the Control ID for text field for font name.

I can't match up with any feature in the standard inspect tool (which, I'll admit, I don't use all that often). 

Can you explain which feature you've used to determine those identifiers?

.

[r0ash]

On 6/17/2018 at 8:12 PM, qwert said:

But there's one area that I don't quite follow.  You make this statement on your blog:

I can't match up with any feature in the standard inspect tool (which, I'll admit, I don't use all that often). 

Can you explain which feature you've used to determine those identifiers?

.

Hey @qwert Thanks for liking.

I've used Inspect tool (https://github.com/blackrosezy/gui-inspect-tool).

Though AutoIt Window Info Tool can be used to get Automation ID (or just ID) for majority of controls, but for sub-menus it do not display it.

While Inspect tool can show you the Automation ID very easily;

[r0ash]

On 6/17/2018 at 5:47 PM, JLogan3o13 said:

So your "professional" approach has zero error checking. If, for some reason, your initial program fails to launch, you continue on through the script throwing error after error (unbeknownst to the user as there is nothing catching those errors). There are already threads on this forum dedicated to best practices when coding in AutoIt:

https://www.autoitscript.com/wiki/Best_coding_practices

 

The intent of write-up is to highlight key areas (as depicted in first image), I completely agree that I should have referred to Best Practices wiki & specifically mentioned error-checking as one of best practices, thank you for that, will keep that in mind next time.

[junkew]

• The comparison you make will have many exceptions and certainly I feel sleep is one of the last choices for an experienced developer.
  If you do GUI automation (end user testing) then the only most close way to enduser will be with active window (that's how the enduser is doing it).
  To easy developers say call the click event directly (having risk bypassing a disabled button)
  check an image exists instead of checking the actual pixels at a location (then you will observe the button is behind another image).
• A professional would make use of constants so when testing notepad thru GUI in different languages you can directly change it at 1 place instead of scattered around.
• Please also check FAQ 31 to see the other spying tools around and ways of automating thru AutoIt (FAQ 4x I believe)

[r0ash]

10 hours ago, junkew said:

• A professional would make use of constants so when testing notepad thru GUI in different languages you can directly change it at 1 place instead of scattered around.

Yeah completely agree, however the intent of write-up was not to come up with definite list of best practices nor we can place everything on a small image. But error-checking is a must, managing code is definitely 1+.

Thanks for your critical analysis, really appreciated.

[JLogan3o13]

As you can see, @r0ash, when you start a post by touting your way as "professional" over others' "amateur" programming, it helps to be sure what you're doing.

As pointed out there are some holes in your logic, which is why we prefer users to refer to the Best Preactices, as agreed on by the community, on the wiki.

[r0ash]

On 6/20/2018 at 3:22 PM, JLogan3o13 said:

As you can see, @r0ash, when you start a post by touting your way as "professional" over others' "amateur" programming, it helps to be sure what you're doing.

As pointed out there are some holes in your logic, which is why we prefer users to refer to the Best Preactices, as agreed on by the community, on the wiki.

Apart from word touting, you and others who responded are really appreciated.

Just for your information there was none *my* way, I learned this approach here on AutoIt forums, implemented at my job, the piece of software runs in production, helped my company grab couple more clients, so I tried to share it with community. Even the write-up clearly says who is my target audience. As I said earlier, I've never claimed that its a definitive guide, so I think I've covered myself.

However the valuable inputs from experienced members here, helped to make it more clear to those readers who are new to AutoIt that my writeup is just an encouragement to strive for best practices.