XButton1 / XButton2 from AutoHotkey and Macro Express

Opus is blocking (XButton1) - (XButton2) from AutoHotkey and Macro Express.

Is there a setting or workaround?

Any help appreciated!

Is/are (XButton1) - (XButton2) the left and right mouse buttons or something else?

In what context are they blocked? (e.g. When a particular window is active?)

What are you trying to do?

Hi Leo,

Mostly what this interfears with is my ability to close (Listers, Dialogs, Property boxes, etc.) via XButton2 "Normally used for browser back function.

Apparently, while Opus is active via anything it’s hooked into (Listers, Dialogs, Property boxes, etc.) all send keyboard functions via scripts like AutoHotkey are invisible globally to any other running scripts except itself.

Note: This anomaly doesn’t affect Opus running XP it only affects Win7 systems.

***I tested the following scripts while Opus was active via (Listers, Dialogs, Property boxes, etc.)

This AutoHotkey script sends the (middle mouse) button when (xbutton2) is clicked:
XButton2::MouseClick, middle
Results: Other scripts, running external to Opus, received the (middle mouse) click ok. Being this isn’t a keyboard function it wasn’t blocked by Opus.

This AutoHotkey script sends the (F1) key when (xbutton2) is clicked:
XButton2::Send, {F1}
Results: The F1 key was received by Opus help and opened it normally. Other scripts running outside of Opus were unable to receive the (F1) key. "This is understandable since Opus has this key mapped for such."

This AutoHotkey script sends the (Alt+Shift+F9) keys when (xbutton2) is clicked:
XButton2::Send, {ALTDOWN}{SHIFTDOWN}{F9}{SHIFTUP}{ALTUP}
Results: Other scripts running outside of Opus were unable to receive the (Alt+Shift+F9) keys being sent by AutoHotkey, even when these keys aren’t mapped or used in any way by opus. This test was performed using many different key combinations all having the same results.

All this may seem trivial, however, I open and close the affected elements constantly and the ability to close with a click of a button saves days maybe weeks when added up over time. Plus, in the creative flow, it's nice to keep it going as smooth as possible!

You're trying to make it so that pushing the Back button on your mouse sends the normal Back event, which AutoHotkey then turns into Alt+Shift+F9, which you then want to be seen by something other than the active window?

Have I understood correctly?

Yes.

What I’m doing is mapping the XButton2 as (Shift+Alt+F9) then Macro Express runs a macro activated by (Shift+Alt+F9). For me, it’s much easier to write scripts with Macro Express vs. AutoHotkey. However, Macro Express doesn’t recognize the XButtons like AutoHotkey, so I use it as an XButton relay.

Regarding the mouse back button; the mouse itself doesn’t send the forward and back functions. Mouse buttons other than the standard right, left and middle are processed by windows as XButton1 through XButton16. Applications then make use of this protocol as needed. Most applications map the XButton1 and XButton2 as forward and back, i.e. most browsers and explorer type interfaces. This should only affect the application itself and not supersede other applications ability to make use of them. All other applications I’ve used have never prevented this, not even Opus prior to win7.

As a workaround, I mapped the middle mouse button to XButton2 and Opus doesn't interfere with this because it doesn’t make use of the middle mouse button. However, this duplicates the middle mouse button reducing my 5 button mouse down to 4 usable buttons when Opus is active.

To remedy: It would be nice if a future update would provide an option to disable the use of the 4th and 5th mouse buttons as forward and back use only.

If

XButton2::Send, {F1}

works, but

XButton2::Send, {ALTDOWN}{SHIFTDOWN}{F9}{SHIFTUP}{ALTUP}

doesn't work, then isn't the issue unrelated to XButton2?

XButton2 is being used in both cases and the difference is the keys that are being sent in response to it.

This seems like a bit of a Rube Goldberg solution as well, to be honest. :slight_smile: There must be a simpler way to make the mouse button run a particular command. (Both the Microsoft and Logitech mouse drivers allow you to explicitly bind buttons to arbitrary commands, for example.)

I have a slightly different understanding, at least with the Logitech drivers (I don't have the Microsoft ones to hand to check).

You can bind mouse buttons to "Generic Button" (whose exact meaning depends on the physical button in question), which I think is what you're describing, but it's unusual (I've never seen it in a default mouse configuration, at least; maybe it's used in some specialised mice?) and separate from the Back function.

When a button is bound to the Back function, the OS (and/or the mouse drivers) turns generates a specific Back-Button event when it is pushed, and applications look for that rather than a generic-button-X event. Apps (other than games) are typically unaware of the generic mouse buttons beyond the main left and right ones (and occasionally the middle button, which Opus and a few other things respond to, but most ignore).

(Maybe the OS and/or default mouse drivers will also generate a Back-Button event after certain Generic Button events are sent and not swallowed by the active application? That might explain things and make both of our understandings true.)

Both our understandings are true depending on system setup. I don’t use a mouse driver. I rely on windows built-in support for the 4th and 5th mouse buttons. With this, it doesn’t matter what type of mouse is used. I’ve used Logitech Microsoft, Kensington and Razer models and they all can be controlled the same via script without any type of mouse drivers installed. This includes controlling the 4th and 5th mouse buttons.

I’ve concluded it’s very likely Opus has nothing to do with this behavior and more to do with how Microsoft’s “Window Manager” currently supports XBUTTON1 and XBUTTON2 via 64bit systems.

In my tests via 32bit Opus: This anomaly only occurs when the active window is 32bit in a 64bit system and a scripting language like AutoHotkey is used to send any type of keystroke via clicking the 4th and 5th mouse buttons to another 2nd running script. In this manor, neither the active 32bit application nor the 2nd running background script is able to receive the send-key value sent by the first running script. The send-key value seems to be invisible to the system at this point!

Note: This similar anomaly has been reported in other forums where Opus wasn’t in the mix.

The following references are to Microsoft’s support for XButton:

Microsoft TechNet Subscriptions - About Mouse Input
technet.microsoft.com/en-us/subs ... 01(v=vs.85.aspx

MSDN - Mouse Input (Windows)
msdn.microsoft.com/en-us/library ... 33(v=vs.85.aspx

In case anyone might be curious about what types of input devices can make use of the advanced XButton support, I’ve included the following 17 button mouse that is compatible with MS XButton Support. However, for devices to make use of buttons above the 5th you still need to use a device driver. Microsoft has mentioned in the past that they will be providing XButton support up to 16 buttons, but this has yet to be seen!

17 Button Mouse
xoxide.com/razer-naga2012exp ... mouse.html