Limit For 1 Key In Many Different Combos!? Topic is solved

[abcjme]

I use Space in a LOT of different Combos. I coded Space to return Space. Instead, it's returning the last character in my code (a `). I found that deleting ANY 1 line of this code will result in Space returning Space again. That leads me to believe that Space has reached its limit for how many combos it can be in.

Why is there this limit?
Is this limit the same for all keyboards?
Is there a way to over-come this limit?

Code: Select all

^esc::exitapp

;LETTERS

space::space

5 & space::m
space & 5::m
4 & space::d
space & 4::d
3 & space::z
space & 3::z
2 & space::j
space & 2::j
1 & space::x
space & 1::x
f5 & space::b
space & f5::b
f4 & space::g
space & f4::g
f3 & space::v
space & f3::v

9 & space::l
space & 9::l
0 & space::r
space & 0::r
- & space::w
space & -::w
= & space::y
space & =::y
m & space::q
space & m::q

; MULTI STRING
[ & space::
if getkeystate("capslock", "t")
send Have
else
send have
return

space & [::
if getkeystate("capslock", "t")
send Have
else
send have
return

] & space::
if getkeystate("capslock", "t")
send For
else
send for
return

space & ]::
if getkeystate("capslock", "t")
send For
else
send for
return

j & space::
if getkeystate("capslock", "t")
send Non
else
send non
return

space & j::
if getkeystate("capslock", "t")
send Non
else
send non
return

k & space::
if getkeystate("capslock", "t")
send Hyper
else
send hyper
return

space & k::
if getkeystate("capslock", "t")
send Hyper
else
send hyper
return

l & space::
if getkeystate("capslock", "t")
send Est
else
send est
return

space & l::
if getkeystate("capslock", "t")
send Est
else
send est
return

`; & space::
if getkeystate("capslock", "t")
send Ing
else
send ing
return

space & `;::
if getkeystate("capslock", "t")
send Ing
else
send ing
return

' & space::
if getkeystate("capslock", "t")
send Ness
else
send ness
return

space & '::
if getkeystate("capslock", "t")
send Ness
else
send ness
return

y & space::'
space & y::'
t & space::.
space & t::.
r & space::send {}}
space & r::send {}}
e & space::send {{}
space & e::send {{}
w & space::send `~
space & w::send `~
q & space::send `_
space & q::send `_
g & space::send `:
space & g::send `:
f & space::send `>
space & f::send `>
d & space::send `<
space & d::send `<
s & space::send `@
space & s::send `@
a & space::send `&
space & a::send `&
b & space::send {!}
space & b::send {!}
v & space::send {^}
space & v::send {^}
c & space::send `|
space & c::send `|
x & space::send `%
space & x::send `%
z & space::send ``
space & z::send ``

[Rohwedder]

Hallo,
Seems to be a bug!
Only a try, replace:

Code: Select all

space::space

by:

Code: Select all

$space::Return
space Up::send {space}

but you lose the auto-repeat from key Space.

[lexikos]

There is a limit of 50 (MAX_MODIFIER_VKS_PER_SUFFIX) custom prefix keys handled by VK, or 16 (MAX_MODIFIER_SCS_PER_SUFFIX) custom prefix keys handled by SC, for each suffix key.

You can work around it by using any other method of detecting combinations:

• Use a hotkey plus the Input command to detect the next key.
• Use #If GetKeyState("Space", "P") plus single-key hotkeys.
• Use single-key hotkeys which all call a single function for tracking combinations manually.
• Use the Hotkey command to dynamically activate and deactivate hotkeys.
• Use your own keyboard hook (I wouldn't recommend it).

Custom combinations exceeding the limit will not work, and may or may not interfere with other hotkeys (but this latter point could be fixed). Rohwedder's suggestion eliminates one side-effect but does not fix the underlying problem.

I didn't design it, but I can think of several reasons for the limitation.

Reasons

Custom combinations work like this:

• Detect the suffix key.
• Retrieve kvk[this_key_vk] or ksc[this_key_sc] (contains key state and lists of custom modifier keys).
• For each modifier VK or SC, check if that key is down. If down, fire the corresponding hotkey.

With fixed-size arrays, kvk can be a single contiguous block of memory, which means a single memory allocation (when the keyboard hook is installed) and no memory fragmentation. The code is both smaller and faster than if the arrays were dynamically allocated.

Fixed-size arrays large enough to hold all possible combinations of suffix key and custom modifiers would take much more memory. (If my understanding is correct, 2.25MB vs around 200KB.) Most scripts do not come close to the limit, and some do not use custom combinations at all, but these arrays still exist in memory.

With dynamic arrays, it would be necessary to either repeatedly resize the array (which takes time and may cause memory fragmentation), or first calculate how large the array should be, then populate it (which takes time). Both cases require larger code than using fixed-size arrays.

It is easier to write thread-safe code with fixed-size arrays. The arrays can be and are modified by the main thread while the hook thread is active (and may be simultaneously reading those arrays). Resizing the arrays would require synchronizing with the hook thread, or uninstalling the hook temporarily.

Linked lists might offer a solution, but there may be complications I'm not aware of. On the other hand, flat arrays have better locality of reference, which improves performance via CPU cache utilization.

[lexikos]

Depending on your needs, you may avoid the limit by simply reducing the number of hotkeys.

Note that 5 & space::m is two hotkeys: 5 & space:: and 5 & space up::, as explained in full by the remapping documentation. You may easily reduce the number of hotkeys by using 5 & space::Send {Blind}m instead.

[abcjme]

Great info! Thanks lexikos! You mention memory as a possible reason for the limitation, but isn't 2-3 mb of memory pretty trivial?

"You may easily reduce the number of hotkeys by using 5 & space::Send {Blind}m instead."

That'd increase the size of my script. Would it save much by means of memory demands?

[lexikos]

... but isn't 2-3 mb of memory pretty trivial?

2MB for every script that uses the keyboard hook regardless of how many custom combinations it uses is in no way trivial. Waste is waste, and not everyone has gigabytes to spare.

That is only hypothetical, increasing the limits to a point that they can't be reached, while keeping the current space-inefficient implementation. It would be only possible to use a fraction of that 2MB, since there is a limit of 1000 hotkeys total. I have done some testing and believe it is possible to remove the limit and decrease memory usage (eliminating these arrays completely) without impacting performance much.

Why does the size of your script concern you?

There are ways to reduce the repetition. I wouldn't bother for most of them, but I would do this, for example:

Code: Select all

[ & space::  ; No need for separate (duplicate) definitions.
space & [::
if getkeystate("capslock", "t")
send Have
else
send have
return

Note that 5 & space::m is two hotkeys: 5 & space:: and 5 & space up::, as explained in full by the remapping documentation.

That is,

Code: Select all

; 5 & Space::m is equivalent to:

5 & Space::
SetKeyDelay -1
Send {Blind}{m DownR}
return

5 & Space up::
SetKeyDelay -1
Send {Blind}{m up}
return

Also,

Code: Select all

; 5 & space::Send {Blind}m is equivalent to:

5 & space::
Send {Blind}m
return

It is two hotkeys and six action lines vs. one hotkey and two action lines. Using 5 & space::Send {Blind}m would save a trivial amount of memory. Memory usage isn't the point; the point is that there are only 50 slots for hotkeys ending with & Space, and 5 & space::m takes two.

[abcjme]

lexikos, I understand now, thanks!

"Why does the size of your script concern you?"

I just like to be efficient with any of my coding. That way, if I put it online, it's quick for others to download.

[lexikos]

The latest test build removes these limitations.

[Nwb]

Hmmm can't this be solved by just running two scripts.. hehe?

[abcjme]

Hmmm can't this be solved by just running two scripts.. hehe?

I tried! Apparently not!

[Nextron]

When using two script, you end up with two hooks that can interfere with each other: When using a custom combination, the native up+down event of the prefix key is only sent, if no matching suffix key is pressed, which happens when you release the prefix key. That prevents a second hook using that prefix key from working properly.
Either way, there is already a solution in place.