Why your Windows macros break, and what to use instead

You record the routine that opens your tracking sheet, exports the report, and files it in the right folder. It works the first time. The next day, you have resized the browser by a few pixels, or the window opens on your second screen. The macro clicks on empty space, types the file name in the wrong place, and you only notice at the end, when the report is nowhere to be found.

The scene is ordinary. The cause is specific.

A recorder keeps gestures, not intentions

When you start a recorder, it notes three things: where the pointer is, which keys you press, and how long you wait between two actions. It does not know that the “Export” button sits at the bottom right of the window. It only knows that a click happened 1,240 pixels from the left edge of the screen.

As long as the window stays there, the gesture does what you meant. As soon as it moves, the same gesture lands somewhere else.

That is where the confusion starts. You think you are automating a task (“export the report”), but you are automating a mouse movement (“click there”). The two stay tied together as long as the screen does not change. They separate at the first surprise.

The real cost is checking, not repairing

You can record the macro again, add pauses, make the delays longer. That holds until the next variation. The real cost is somewhere else: verification.

A macro that fails now and then has to be watched every time you use it. You look at the screen while it runs, you re-read the result, you doubt it. It frees nothing. In their work on automation, Raja Parasuraman and Victor Riley call this “disuse”: you keep the tool, but you do the work by hand because you no longer trust it.

A ten-minute test before you repair anything

Before you touch the macro, run this test. Record a routine of three or four actions in one window. Close it, reopen it, and place it somewhere else on the screen. Replay the macro.

If it still works, the problem was a delay or a one-off position. You can keep it for occasional use, with a check at the end. If it fails, do not fix a coordinate. The principle does not hold, and every correction adds a new point of fragility.

Target the window, not the spot

The replacement rule fits in one sentence: a command should rely on whatever identifies the target and does not change when the window moves. The name of the process that opened it does that well. A position on screen identifies nothing.

AutoHotkey does this in a few lines. The WinExist function looks up a window from its properties and returns a result if it exists. WinActivate brings it to the front, wherever it is. If it does not exist, the script launches it.

#Requires AutoHotkey v2.0

; Ctrl + Alt + B: bring Notepad to the front, or open it
^!b:: {
    if WinExist("ahk_exe notepad.exe")
        WinActivate
    else
        Run "notepad.exe"
}

Replace notepad.exe with your tool’s process name, and ^!b with the shortcut you prefer. The principle is the same for a reporting tool, an editor, or accounting software.

What to do today

Install AutoHotkey v2 if you have not already: the Automation lesson covers the installation and the .ahk file. Create a file called bring-back.ahk, paste the script, then double-click it to run.

Open Notepad, drag it into a corner of the screen, then press Ctrl + Alt + B: the same window comes back, at its new position. Close it and press again: it reopens. If nothing happens, open Task Manager, go to the Details tab, and check the exact process name.

This script does not cover everything. In a browser, a page title changes with the tab, so a rule that targets the title becomes fragile. For the web, look at Automa instead, which works on pages rather than pixels.

What to keep

A recorded macro is a good starting point, not a foundation. If it breaks the first time a window moves, repairing a coordinate fixes nothing: target what identifies the window. A rule written once costs less than a macro you have to keep watching.

What this changes for you: take a macro you use and run the ten-minute test. If it fails, replace one of its gestures with a command that targets the window. To go further, the Automation lesson connects this to snippets and launchers.

Sources

Last checked: 1 November 2026.

See the 3 sources for this article

• AutoHotkey, v2 documentation: WinExist
• AutoHotkey, v2 documentation: WinActivate
• Raja Parasuraman and Victor Riley (1997), Humans and Automation: Use, Misuse, Disuse, Abuse, Human Factors