Mouser v3.7.3
A hotfix for v3.7.2. Opening the custom shortcut recorder on Windows froze the mouse pointer for the rest of the session. If you are on v3.7.2, update.
🖱️ The freeze
Assigning a custom shortcut left the mouse completely unresponsive. The shortcut could be typed but not saved, because the Save button could no longer be clicked, and nothing short of a sign-out or a reboot brought the pointer back.
Reported by @327607501 (#259) on Windows 11 with an M590 over a Bolt receiver, though it was never device-specific: any mouse, any connection, on any Windows machine running v3.7.2.
The cause was two hooks quietly sharing one object. ctypes.windll.user32 is a single process-global handle, and ctypes stores function prototypes on the handle itself rather than per call site. Mouser's low-level mouse hook declares CallNextHookEx to take a mouse event; the shortcut recorder's keyboard hook declared the same function to take a keyboard event. Whichever ran second won. Opening the recorder rewrote the prototype the mouse hook depended on, so from that moment every mouse event failed on the way into the hook and no click, move or scroll reached Windows.
The recorder now loads its own private handle, so the two hooks no longer share prototypes.
Note
The recorder was reworked in v3.7.2 (record and type modes, Windows key support). This regression arrived with that rework, so v3.7.1 and earlier are unaffected.
Two details from #259 are working as intended, now that the pointer moves again. Enter is recorded as part of the shortcut rather than confirming the dialog, because it is a bindable key, so use the Save button to confirm. Binding a button to launch an app is a separate feature request and is tracked on its own.
🙏 Thanks
To @327607501, again. The report in #253 found the crash fixed in v3.7.2, and #259 arrived within hours of that release with enough detail to pin this one down immediately.
Full changelog: v3.7.2...v3.7.3
