The Focus Window Action (under the UI/Windows folder) provides us with the option to find a window using its title and/or class.

This can be extremely useful since, this option gives us the ability to use wildcards instead of the exact name of the window.

Lets say for example that the title of the window of our application is "WinAutomation Console - Professional Edition"

We could simply search for "WinAutomation Console*" and that would still allow us to capture the desired window. This makes the title more generic, therefore even when the exact title differs (eg: "WinAutomation Console - Professional Plus Edition"), it still focuses the window.

*The Focus Windows action only allows us to "Focus" or "Bring a window to front", whereas in order to grab the control of the window, the Get Window action needs to used.

Another example would be the following

Wildcards are also very useful in those cases, where you have to adjust the window names in the window-related actions (such as Focus Window), since names sometimes tend to change between different machines. The difference is usually subtle, e.g. a “[Compatibility Mode]” appended on the window title. One such difference is the reason you are getting the “Window not found” error. Normally, the message includes the Action which produced the error, so you can double click on it and see the exact window name it was looking for and didn’t find.


When correcting it, you can use wildcards (*,?) and variables in the title, making it much more flexible and portable. For instance, assume we have an Excel window open with the following name:


AutomationOptions.xlsx  [Read-Only] – Excel


The [Read-Only] part for instance, as well as the extension (.xlsx) are results of user's personal preferences and customization of the OS. As long as the file name is always the same, you should better use:




Which would work on most computers! In the case we needed a variable filename, we could write:




where %MyFile% is a file variable, which is set earlier in the Process.