Macro exe's steal focus

[hpkhpk]

I have a perl script that starts a window application, and then runs macros to interact with the application. It works fine when I invoke the macros with "msched.exe macro.scp". But if I compile the macro to an executable, when the perl script runs the executable, the macro steals the focus and messes up my automation. How can I prevent this?

I can't solve this by putting a "SetFocus" in the macro because I don't always know the name of the window that I'm interacting with.

[JRL]

I can think of a couple of reasons the compiled script might steal focus but it would be easier if you told us what the macro does. Is there a dialog box that comes up, is the macro opening other windows? What does the macro do that might be stealing focus? What does the macro cause to be displayed on the screen?

Something that might work. If you compile with the /HIDE /NOSYSTRAY settings the compiled macro might not remove focus from the window that you're trying to work in since it would have nothing of its own displayed on the screen.

Hope this helps,
Dick

[hpkhpk]

Adding /HIDE fixed the problem. But I noticed that I have no control over the icon in the system tray when running an exe macro. Left or right clicking has no effect. Is there any way to kill a runaway macro?

By the way, you can reproduce the problem with a simple macro that has one line:
>wait 100

If you run the macro from a cmd window, the cmd window looses focus when running this macro compiled into an exe. Doesn't happen when run from msched or running the .exe with /HIDE

[pgriffin]

a "runaway" macro can be stopped with Shift+Esc unless you clicked "Disable Shift+Esc" while compiling.

[jpuziano]

I have a perl script that starts a window application, and then runs macros to interact with the application. It works fine when I invoke the macros with "msched.exe macro.scp". But if I compile the macro to an executable, when the perl script runs the executable, the macro steals the focus and messes up my automation. How can I prevent this?

I can't solve this by putting a "SetFocus" in the macro because I don't always know the name of the window that I'm interacting with.

Hi hpkhpk,

I noticed that compiled macros steal focus as well. My solution has always been to add these lines...

Code: Select all

Press ALT
Press TAB
Release ALT

...to the beginning of the script before compiling. The compiled macro would still steal focus but the Alt-TAB would flip it quickly back to the window that originally had focus and the rest of the macro would take it from there.

I tried just compiling it with /HIDE and that worked just as well, better actually, less code to add or comment out, thanks for that.

Interestingly, even compiled with /HIDE, the focus seems to be lost for a bit before it returns. You can see this by compiling a one line macro like this:

Code: Select all

Send>some text

- I compiled it and created a desktop icon that points to the .exe
- I set a shortcut key in Properties for the icon to be able to trigger it
- I opened up a Notepad window, made sure Notepad had focus
- Tap the shortcut key to trigger the /HIDE compiled macro and you can see Notepad get dim (loose focus) for a 1/2 second, then regain the focus and the macro types the text into Notepad.

Marcus, is there any way to run a compiled macro without that "loss of focus" effect? Is it due to the way I'm triggering it, with a shortcut key? Any way around this or is it just an inherent limitation of Microsoft Windows itself?