Like I said, I tried emailing them (at all of the addresses they have), but unfortunately the emails bounced, so I guess there’s no support.
In light of that, I ended up settling for an AutoHotkey workaround:
- Create a plain text file
Type the following
$Browser_Back::Send $Browser_Forward::Send
- Save it (e.g.,
MK_Rev.ahk
; I added these to my existing general-purpose scriptMisc.ahk
) - Run it (e.g.,
autohotkey MK_Rev.ahk
It—generally—works a treat, but is not perfect and has a few possible issues:
Under specific circumstances, AHK may not be able to intercept the keys/buttons and remap them. One such circumstance is when there is a heavy CPU load, though that could easily be resolved by setting AHK to high-priority. Another circumstance is if a program reads the keys in some non-standard way, but those usually won’t be using the browser-navigation buttons anyway.
Connecting a normal mouse/keyboard that doesn’t have them reversed would cause AHK to reverse them. That is, the keys would work correctly on the bad set and backwards on the good set! This is madness! MADNESS!!! One way to deal with this is to stop or pause the script when switching to the proper set. Another might be to enhance the script to somehow detect which keyboard/mouse the hotkey initiated from and dynamically make a decision on whether or not to remap. Unfortunately that is not a simple thing and would be a drastic change requiring advanced coding which is theoretically possible (AHK supports DLL system calls), but would generally not be worth the effort of massive research and testing to pull it off—it would be faster, cheaper, and easier to just buy another set without the problem (though I really like this one).