Preventing hotkey from running an already running macro

MikeB941 · Post by **MikeB941** » Mon Jul 09, 2007 2:23 am

Was wondering if there was a convenient way to test when a hotkey is hit again for an already running macro.

I have a menu macro that is started with cntl-alt-m and just hangs out (modal)to start other macros.

Sometimes the user reduces the menu macro window and forgets about it and then tries to start it again with cntl-alt-m (the results are messy).

Is there any easy check at the start of a macro to see if an instance is already running?

Thanks a million for any help.

JRL · Post by **JRL** » Mon Jul 09, 2007 4:57 am

This is also a problem when running compiled scripts. The trick that I like to use is create a dialog positioned far off screen, which the sole purpose is to exist as an open window. I then test for the open window early in the script. If the window is open, jump to the end of the script. You can also put in a message informing the user that the script is already active.

Code: Select all


IfWindowopen>MacroName_test_window,AlreadyActive

Dialog>MacroName_test_window
   Top=-10000
   Left=-10000
EndDialog>MacroName_test_window

Show>MacroName_test_window

//The rest of the macro

Goto>EOF

Label>AlreadyActive
MessageModal>The script MacroName is already running.

Label>EOF

MikeB941 · Post by **MikeB941** » Mon Jul 09, 2007 6:18 am

Thanks a million! This worked GREAT! Really appreciate the help!

Post by **Marcus Tettmar** » Mon Jul 09, 2007 6:44 am

Other solutions: Store a flag in an INI file, or in the registry, or in a text file, or use an environment variable. Check for existence of flag at start of script, if present, jump to end, if not, set flag and continue.

Me_again · Post by **Me_again** » Mon Jul 09, 2007 2:38 pm

JRL wrote:This is also a problem when running compiled scripts. The trick that I like to use is create a dialog positioned far off screen, which the sole purpose is to exist as an open window. I then test for the open window early in the script. If the window is open, jump to the end of the script. You can also put in a message informing the user that the script is already active.

I have some that count the number of processes, if >1 then abort.

JRL · Post by **JRL** » Mon Jul 09, 2007 3:34 pm

I have some that count the number of processes, if >1 then abort.

Another good idea.

The main reason I like the open window scenario is that when the script completes the window is gone. the problem I have with the methods such as a registry setting, an Ini file flag or a text file is that the script needs to deal with the flag or file on exit. If the script terminates unexpectedly such as a power outage, the flag is now set to prevent the script and manual intervention is required in order to change or remove the flag or file before the script will run again.

I think I like the environment variable idea. I'll have to experiment with it. Off hand I think that when the program that creates an environment variable terminates, the environment variable is also terminated. If this is correct, setting an environment variable using the SetEnvVar> function would be a simple and ideal method for preventing a program from having multiple instances.

Post by **Marcus Tettmar** » Mon Jul 09, 2007 3:37 pm

If using a compiled EXE check how many instances of the process are running:

http://www.mjtnet.com/forum/viewtopic.php?t=1652

JRL · Post by **JRL** » Mon Jul 09, 2007 5:49 pm

I think I like the environment variable idea. I'll have to experiment with it. Off hand I think that when the program that creates an environment variable terminates, the environment variable is also terminated. If this is correct, setting an environment variable using the SetEnvVar> function would be a simple and ideal method for preventing a program from having multiple instances.

After a little experimentation with the SetEnvVar> and GetEnvVar> commands, I think that I still like the dialog window test or the count the processes test. The environment variables in windows are not global to the operating system, they are local to the program shell. this means that they will work fine to prevent multiple script instances within the program shell of Macro Scheduler, but they will not work at all to prevent the same compiled executable from running more than once.

jpuziano · Post by **jpuziano** » Tue Jan 04, 2011 10:37 pm

Hi JRL,

I just wanted to say thanks for posting this... the dialog window test is working great for me to make sure only one instance of a compiled macro can be run at any one time.

I had thought of looking at processes but this method seems easier (less code) and I would agree its superior to methods that write to files, ini files, etc. because you have to cleanup/delete the file on the way out and if you get an unexpected powerdown, it can leave the file around... and you'd have to deal with that starting up as well. No so with this method... there's nothing to cleanup on the way out because when the macro is no longer running, the dialog window is gone.

Thanks again... for all the great stuff you post and all the best in 2011.