Using Global Hotkey for Multiple Applications

[KenHadley]

I have written a simple macro for one application and assigned Ctrl-1 as the global hotkey. I now have another (unrelated) application that, out-of-the-box, uses Ctrl-1 as a hotkey for its own purposes. Is there a way to rewrite my MacrosScheduler macro, still using Ctrl-1 as its global hotkey, so that the macro will recognize whether it should execute my code for the older application or, whenever the Active Window is the other, new, unrelated application, it should simply pass the Ctrl-1 event to that other application for execution?

I tried the following code, but it simply calls my MS macro over and over again in an infinite loop whenever the newer application is the active one.

Code: Select all

GetActiveWindow>strTitle,nXPos,nYPos,,
RegEx>OPTIONVUE,strTitle,0,Matches,NumMatches,,,
If>NumMatches>0
    UIClick>{"OPTIONVUE*"},{"T.Log"}
ELSE
    Press LCTRL
    Wait>0.2
    Send>1
ENDIF

[JRL]

If Macro Scheduler receives the hot key press before your application does there is little for you to do but change the Macro Scheduler hot key to something that does not interfere with your other applications.

Macro Scheduler is designed to do work within other applications. We want its hot keys to be "the" hot keys on our computers. Therefore you need to be careful about the hot key choices you make for Macro Scheduler scripts. For example, you most likely do not want to use CTRL + C as a Macro Scheduler hot key. You CAN set a script to that key combination but if you do, you will no longer be able to press Ctrl + c to copy highlighted data to the clipboard, you will instead run the associated Macro Scheduler script.

Hope this helps.

[KenHadley]

Yes, thank you, JRL, that's a very helpful explanation. I have removed the global hotkey definition from my MS macro and used the following AutoHotKey macro to define Ctrl-1 only for my OptionVue program. AHK will simply pass through the Ctrl-1 hotkey, if my desired application is not the active one. This allows the other application to continue to use the same hotkey.

As someone who migrated from AHK to MS a while back, this is the first time I have returned to AHK, because of its #IfWinActive directive. In all other cases, MS has been far superior in its capabilities and reliability for executing the macros I have written and meeting my business needs.

Code: Select all

;; Macro written in AHK scripting language
#IfWinActive, OPTIONVUE
^1::
	Run "c:\Program Files (x86)\Macro Scheduler 14\msched.exe" "OV Open Transaction Log" 
	return
#IfWinActive

[JRL]

Ken,

I hate to see you have to resort to AHK

There is usually a way its just not always obvious. After reading your last post and thinking a bit it occurred to me that if you start your "OV Open Transaction Log" script with a test to see if OPTIONVUE is the current window, you could then perform an alternate series of events to accomplish whatever CTRL+1 does. If CTRL+1 is the only way to get there, then ignore this and continue with what works.

As an example: I put the following into a script I named "PressCTRL_g". I set the hot key of the script to CTRL+g. In Notepad CTRL+g opens a "Go To Line" window. But you can also open the "Go To Line" window by using the menu and clicking "Edit" then "Go To...". OR you can open the "Go To Line" window by pressing Alt followed by "e" (for edit) followed by "g" (for Go To). The script tests to see if Notepad is the current window and if it is the script presses Alt, e and g then exits. If Notepad is not the current window the rest of the script will process.

However, as you've already discovered, you can't set this script up to press CTRL+g or you will be in a loop calling the same script over and over again.

Code: Select all

GetActiveWindow>Title,WinX,WinY
Separate>Title,Notepad,res
If>res_count>1
  SetFocus>Notepad*
  Press alt
    Send>eg
  Release alt
  WaitWindowOpen>Go To Line
  Wait>0.5
  Exit>0
EndIf

/////////////////////////////////////
MDL>The script you want to run with ctrl + g.

[armsys]

Hi Ken,
Hotkey conflicts are a routine event to most MS users.
For years I've been writing a plethora of complex code, one for each hotkey, similar to the idea/algorithm suggested by JRL to accommodate some commonly used hotkeys such as F10 and Ctrl+Shift+s. Most likely, JRL's solution is the only practical one available.
Upon reading your post above, I did some research on AHK. I decide to abandon AHK because of my worry of memory and performance impact.

[KenHadley]

JRL and armsys,

Thank you for these replies. I see now where JRL is headed. I would have a 'master' MS macro for each global hotkey and, based on checking for the active window, I could have two, three or even a dozen different ways of responding to CTRL-1, depending on which window/app was active. I will go back and try this.

Architecturally, however, the difference between AHK and MS is interesting. The concept of Directives in AHK (signaled by the # prefix) is not part of MS, as far as I know (other than 'Include,' of course). I am familiar with Directives in compiled languages (mostly as compilation instructions), but their extensive use in a scripting language like AHK is new to me. In my particular example above, AHK treats CTRL-1 as a hotkey *only* if a window is active. Otherwise, AHK "instructs" the script to act like the definition of CTRL-1 as a hotkey does not even exist. It doesn't "see" that hotkey if the desired window is not active and simply passes through the key strokes.

Armsys, I migrated from AHK to MS for some of the same reasons you mention. When using AHK, I was plagued by idiosyncrasies and inconsistencies in the AHK macros that I wrote. If the mouse currently happened to be somewhere unexpected on the screen, or the cursor happened to be in an editable field, I would need to insert an extra AHK command to make the macro work. I found myself tweaking the AHK macros on a frequent, sometimes daily, basis. Since I moved to MS and have used its Image Recon and other features, my MS macros work flawlessly every time.

[armsys]

I would have a 'master' MS macro for each global hotkey and, based on checking for the active window, I could have two, three or even a dozen different ways of responding to CTRL-1, depending on which window/app was active. I will go back and try this.

Yes, that's the whole idea. That's the way to go.
In fact, you can expand JRL's idea/code above. Besides going to a particular line, your code can do extra things to meet your unique needs such as saving the file, boldly going beyond what the hotkey was originally designed for.

Code: Select all

GetActiveWindow>Title,WinX,WinY
Separate>Title,Notepad,res
If>res_count>1
  SetFocus>Notepad*
  Press alt
    Send>eg
  Release alt
  WaitWindowOpen>Go To Line
  Wait>0.5

  // Extra functionalities
  // Save the current file
  Press CTRL
  Send>s
  Release CTRL
  Exit>0
EndIf

/////////////////////////////////////
MDL>The script you want to run with ctrl + g.

I migrated from AHK to MS for some of the same reasons you mention. When using AHK, I was plagued by idiosyncrasies and inconsistencies in the AHK macros that I wrote. If the mouse currently happened to be somewhere unexpected on the screen, or the cursor happened to be in an editable field, I would need to insert an extra AHK command to make the macro work. I found myself tweaking the AHK macros on a frequent, sometimes daily, basis. Since I moved to MS and have used its Image Recon and other features, my MS macros work flawlessly every time.

Thank you for sharing your first-hand user experience with AHK.

[armsys]

Hi KenHadley,
Now I would give a second thought of committing to AHK (as well as other languages).