[v2] KeyBd/MouseHook and UseHook enabled by default

[swagfag]

i propose the following:

• #InstallKeybdHook enabled by default if Send command variant is used. Directive replaced with a new one which would instead suppress the installation of the hook, provided thats at all possible. Something like #DeferKeybdHookInstall but thats a bit wordy
• #InstallMouseHook same as above.
• #UseHook enabled by default if a Send command variant is used, unless one of the above alternate directives appears in the script

the primary reason being is i see time and time again people trying to make repeat macros, involving sending the key that triggered them, inadvertently triggering an infinite(well, almost..) loop. Thats rarely the desired behavior, in fact id reckon it never is. I cant think of a situation where youd want that and tbh if youre using Send to trigger other hotkey labels, thats just bad design and should be actively discouraged. "More than #MaxHotkeysPerInterval have been sent in the last however long it took ms." is the cryptic message they then have to go by in their efforts to track down the bug.

+1 MB memory footprint i can live with. those concerned with it can use the alternate directives and acknowledge what using them implies.

Besides memory i personally cant think of any reason why you wouldnt want to have the hooks enabled by default at all times, but im willing to leave it at them getting enabled only if Send appears in the script.

[Helgef]

I appreciate your good intentions, but it is a bad idea for several reasons. Consider for example that sendinput is default in v2.

Besides memory i personally cant think of any reason why you wouldnt want to have the hooks enabled by default at all times

why would you want the hooks to be installed at all times? Disregarding the one example you provided which is trivial to solve in the minority of script which are affected.

Cheers.

[swagfag]

If a script other than the one executing SendInput has a low-level keyboard hook installed, SendInput automatically reverts to SendEvent (or SendPlay if SendMode "InputThenPlay" is in effect). This is done because the presence of an external hook disables all of SendInput's advantages, making it inferior to both SendPlay and SendEvent. However, since SendInput is unable to detect a low-level hook in programs other than AutoHotkey v1.0.43+, it will not revert in these cases, making it less reliable than SendPlay/Event.

yeah that would break sendinput, i wasnt aware of this limitation

i dont have any other reason really, but i dont agree its trivial either. its not if youve just installed ahk and want to make some quick macros without any prior priming. its just yet another one of those "ahk gotchas". while it can be trivially resolved if one were to spend 10 mins rereading the send docs thoroughly or digging around the web, a good deal of people dont and instead just resort to dumping the script on the help subforum. This can be avoided. Maybe change #MaxHotkeyPerInterval's error message to hint at the possibility of a hotkey trying to send itself.

[Nextron]

the primary reason being is i see time and time again people trying to make repeat macros, involving sending the key that triggered them, inadvertently triggering an infinite(well, almost..) loop.

The method to prevent this behavior is explicitly explained in the hotkey docs, not hidden away somewhere. Apparently, some people aren't willing to spend a few minutes to read the basics, but instead wait to be told to RTFM.

Besides memory i personally cant think of any reason why you wouldnt want to have the hooks enabled by default at all times, but im willing to leave it at them getting enabled only if Send appears in the script.

My main script definitely uses hooks and I try to combine as many persistent scripts I require to it as possible, but that doesn't keep me from having many separate scripts, which can be seen more as batch files, for which I wouldn't need a hook installed. Consider that a hook is a intrusive form of system interaction: It can monitor, change and delay any input. It may be used by just you, but also hundreds of other forum users (which hopefully check code before they run it) or thousands of oblivious colleagues. I wouldn't be pleased if I found out some program I use, applies such a hook without good reason.