Marcus' Macro Blog

Tips and News on Macro Recording and Automating Windows with Macro Scheduler
October 18th, 2016 by Marcus Tettmar

Just a quick update – Macro Scheduler 14.3.05 is now available for download from the usual places.

This version fixes an issue for people running Non-English versions of Windows who found they had to set the “Language for non-Unicode programs” option to English in Regional Settings in order for the SendText/Send functions to work correctly. This is no longer necessary.

As that is the only change there is no need to download if your Windows is set to English. Feel free to skip this update.

Get it Now: Trial DownloadsRegistered Updates/UpgradesNew Licenses

September 15th, 2016 by Marcus Tettmar

Someone emailed today saying they were having problems trying to automate Internet Explorer 11 because it didn’t seem to have a window title.

Actually IE11 does have a window title. Each tab has a different window title. But you don’t see the title in the main title bar of the application.

By default applications show the window title in the title bar. Hence it’s name. But some apps manipulate the appearance of their title bar so that it doesn’t look like a regular Windows title bar. Indeed some apps have all borders removed so that you can’t SEE the title bar. But in all cases, the window will still have a title (unless it’s an empty string!).

So if you can’t see the window title, how do you find out what it is? Well, with Macro Scheduler there are several ways to find it. One is with the View System Windows Tool, which shows a list of all the windows currently available on the system, showing their captions and class names. Another is to use the Code Builders.

Here’s a video demonstrating these two methods. It also shows how I use a substring window match:

September 9th, 2016 by Marcus Tettmar

We have today updated the MacroScript SDK packages with the latest Macro Scheduler script engine (14.3.02). Those of you with the SDK and valid maintenance wil find the downloads in your account.

If you are not aware of the MacroScript SDK you might find this article useful.

September 7th, 2016 by Marcus Tettmar

We have today released Macro Scheduler 14.3.01

This update includes a number of improvements and small fixes, as well some new functionality:

  • Added: Ability to create a default script template (put it in \Templates\default.scp under main data folder)
  • Added: ArrayCopy function
  • Added: ArrayRename function
  • Added: Code folded If commands now show condition in top line
  • Added: Ifs tab to variable/code explorer
  • Added: If result variable omitted from Base64, Crypt, StringReplace, UpperCase, LowerCase, Trim, LTrim and RTrim input is used
  • Added: Assigned function can now check variables with embedded variables (e.g. array type variables)
  • Added: INPUT_BROWSE_FILTER variable to set file filter in input filebrowse dialog
  • Added: First line of script shows in new column in macro list (or second line if first line is compile opts)
  • Added: Undefined variables within complex expressions automatically resolved to empty strings
  • Added: TelnetClearLog function
  • Added: XLGetSheetNames function
  • Fixed: Minor UI issues under UHD monitor resolutions
  • Fixed: Column positions sometimes loaded incorrectly
  • Fixed: Editor goto gosub menu not stripping out optional parameters
  • Fixed: Compiler not updating target BMP_DIR with new images
  • Fixed: Save On Run option ignored (always saves) when macro run from standalone editor
  • Fixed: Code folded While statements show full condition in top line
  • Fixed: Tab length and block indent length inconsistent in editor
  • Fixed: Code builder now respects current indentation level

Get it Now: Trial Downloads | Registered Updates/Upgrades | New Licenses

September 7th, 2016 by Marcus Tettmar

Over in the forums dtaylor has posted a script library which allows you to show a small notification window in the lower right of your screen. Useful for reporting on progress during your script, in loops etc.

Grab it here.

August 17th, 2016 by Marcus Tettmar

This is a repost. The original article is here.

Most of the time when we are automating a process we are able to predict the sequence of events. We are working with a deterministic process and a linear flow of actions. But there are occasions when things can happen during a process that we cannot predict precisely. E.g.:

  • We might know that a dialog or window may appear sometime during the process, but we cannot predict exactly when that will happen.
  • We may have a situation where after entering some data into a text field a dialog may, or may not appear.
  • There might be some other software running on the PC which randomly pops up an error box. And we need a way to clear that when it happens.

There are a number of ways we can deal with such situations.

Window Event Schedules

If you have a situation where a known window can randomly appear – say a known error box – which always has the same window title, the simplest approach is to use the Window Event schedule in the Advanced Scheduling properties. Simply create a macro which closes the box – perhaps all it has to do is press enter – and specify the window title under Advanced Options in the macro properties. Then whenever Macro Scheduler sees this window it will run the macro and clear it.

Synchronous Coding

In the case where a window may, or may not appear after entering some data into a field, say a data validation dialog, we could just deal with this after sending the text, in regular fashion – something like:

IfWindowOpen>Verification Alert
  Press Enter

So we simply send the data then IF the verification window appears, close it. But what if you have hundreds of data fields to enter? Dealing with each one would involve a lot of extra code.

OnEvent Window Event Handlers

Another way is to use the OnEvent function to create an event handler in your main script. There are three types of window events that can be monitored with OnEvent:

  • WINDOW_OPEN – monitors a specific known window title, or window title substring
  • WINDOW_NOTOPEN – fires the event handler when specified window closes
  • WINDOW_NEWACTIVE – fires the event handler when there’s a new foreground window

OnEvent is used to create an “event handler” which is just a subroutine which will be executed whenever the event occurs. So, for example, using OnEvent you can tell the script to run a subroutine whenever a specified window appears, whenever that may be, while the rest of the script is executing.

So let’s say we are working with an application which could, at any time, pop up a warning box titled “Connection Error”, and this can be cleared just by pressing enter to hit the default OK button:

OnEvent>WINDOW_OPEN,Connection Error,2,CloseWarning

.. rest of script here

  Press Enter

Of course there are a whole load of other things you can do. We may have a window whose title is always the same but the content differs and we need to react according to the content. In this case our event handler subroutine would have extra code in it to determine which type of dialog it is. We might do this using the text capture functions to read the text from the dialog, or using Screen Image Recognition to check for the presence of an object.

Maintaining Focus

Here’s an idea for an event handler which ensures the target application is always focused. If another application should steal focus at any point during the running of the script, it just grabs focus back again. It’s always good advice to use SetFocus before sending text. But if you have thousands of Send commands and want to slim down your script and make it more readable you could use this approach. Anyway, it’s just an example:

.. your code here to start and focus the app you want to automate, e.g.:
WaitWindowOpen>Untitled - Notepad

//assuming the target window is now focused, get it's handle and process name

//now set up the event that is fired when a new window appears

.. rest of script here

//When a new window that does not belong to our process appears,
// set focus back to our window

Note how this code gets the window handle and process name of your target window. Then whenever a new window appears the HandleNewWindow subroutine is fired which gets the process name of the active window. If the process name of the new active window is not the process name of your target window (i.e. the new window belongs to some other application) it sets focus back to your original window.

I hope this gives you a useful introduction to OnEvent event handlers and how they can be used to run code at any point during the script in response to events. OnEvent can also be used to detect files, dialog events, dialog changes and keyboard and mouse actions. For further information please see OnEvent in the help file.

August 5th, 2016 by Marcus Tettmar

Here’s a way to get screen text from any application – even from an image – using OCR and a free open source tool called Tesseract.

First, you need to download and install Tesseract. You can get it here.

Tesseract is a command line utility. The most basic syntax is:

tesseract.exe input_image_file output_text_file

So you could call it from a Macro Scheduler script something like this:

//Capture screen to bmp file - you could instead capture only a window or use FindObject to get coordinates of a specific object

//run tesseract on the screen grab and output to temporary file
Run>"C:\Program Files (x86)\Tesseract-OCR\tesseract.exe" "%SCRIPT_DIR%\screen.bmp" "%SCRIPT_DIR%\tmp"

//read temporary file into memory and delete it

//Display the text in a message box

This example simply captures the entire screen. You probably wouldn’t normally want to do this. Instead you could capture a specific window:

//Capture just the Notepad Window
SetFocus>Untitled - Notepad
GetWindowPos>Untitled - Notepad,X1,Y1
GetWindowSize>Untitled - Notepad,w,h

Or even a specific object:

//capture just the editor portion of notepad ...
SetFocus>Untitled - Notepad
GetWindowHandle>Untitled - Notepad,hWndParent

Either way you then have a screen bitmap you can pass into Tesseract.

Once you’ve retrieved the text you would probably want to parse it, using e.g. RegEx. Here’s an article on a RegEx expression useful for parsing out data.

August 4th, 2016 by Marcus Tettmar

Recently someone asked in the forums how to “Automatically Detect MS Office Install Location” so that they could run an Access macro.

Well, there are ways to get the path of an installed Office application, but it isn’t necessary in order to run an Access macro. This is a rehash of my forum answer:

You can run an Access macro via the command line using the /x switch. The ExecuteFile command lets you pass parameters. So you could just do this:

ExecuteFile>%USERDOCUMENTS_DIR%\MyDb.accdb,/x Macro1

This will open the DB and run macro “Macro1″. Note my DB is in my documents folder here so I’m just using USERDOCUMENTRS_DIR but this could be any path.

Here’s a list of other command line switches.

For more control you could use VBScript:

  Sub RunMacro(accessfile,macroname)
    dim accessApp
    set accessApp = createObject("Access.Application")
    'comment next line out if you don't want access to be visible
    accessApp.visible = true
    accessApp.DoCmd.RunMacro macroname
    'you can run a subroutine or function in module code instead if you want:
    ' "routinename"
    set accessApp = nothing
  End Sub


This gives you more control – you could make it invisible, and as you can see you could run VBA code instead if you want – or access any of the other methods. Anything you can do inside Access you can do here – by converting VBA to VBScript:

But if you do really want to get the path, how about querying the mime-type in the registry:



July 25th, 2016 by Marcus Tettmar

Are your macros reading from other files? Find out how to avoid hard coding file paths and use relative folders:

July 20th, 2016 by Marcus Tettmar

What would you like to see added to Macro Scheduler? Comment below.


    • Categories