v2.0-rc.1 Baffling issue with hotkeys

[Elequosoraptor]

Hello. I am trying to put together a symbol layer with hotkeys and #HotIf. In theory, you press a hotkey, change the value of a variable, and a new set of hotkeys for various symbols take effect. I am also using some code that creates alternate symbols on a long press, or key repeat on double tap+long press.

I have tested all of these features seperately, and used them all together when making my regular letters autoshift, but I have found a baffling set of issues with my symbol layer. Some of these might have been present all along, but not detectable, but I really have no idea how to even diagnose the issues.

When rapidly randomly typing three or more keys in the symbol layer (not less than three keys, and not while typing slowly), at some point(as far as I can tell, at a random point) the hotkeys stop working, either partially or entirely. That is, instead of symbols, all my letters output regular letters, even though the script is still running. Sometimes this happens for a few random presses scattered in the string of symbols I'm typing, sometimes this happens permanently and I can no longer type any symbols with the hotkeys at all.

Also, usually (but not in every variation of the test), Shift gets stuck down, so everything comes out capitalized. I usually have to make my computer sleep and then wake it up again for it to unstick.

Here's the basic code for the hotkeys, though I do have hotkeys for basically every letter key.

Code: Select all

longPress(thisKey, defaultString, longPressString, numOfBackspaces){
    startTime := A_TickCount
    SendInput(defaultString)
    backspaceInput := "{Backspace " numOfBackspaces "}"
    ; Instead of a sleep or simlar delay, a loop is used so that, in the process of rapid typing, one cannot release the hotkey and then press it again, falsely triggering the script into backspacing, missing that the key had been released
    while(GetKeyState(thisKey, "P")) {
        endTime := A_TickCount - startTime
        if(thisKey = A_PriorKey && endTime > longPressDelay) {
            SendInput(backspaceInput)
            SendInput(longPressString)
            KeyWait(thisKey)
        }
    }
}

#HotIf currentLayer = "Sym"
q::{
    if(A_PriorKey != "q" || A_TimeSincePriorHotkey > 350){
        longPress(ThisHotkey, "{Blind}~", "{Blind}$", 1)
    } else {
        SendInput("{Blind}~")
    }
}

The way shift locks down is probably the most consistent part of this issue, but the behavior is so random I have no idea. When trying to replicate the issue, I'm not pressing Shift (either via a Hotkey or the actual key).

[lexikos]

How do you type ~ on your keyboard layout? On the US layout, it is with Shift.

If you are trying to send characters, I would highly recommend using SendText.

[Elequosoraptor]

I have a US layout. I wanted to make a symbol layer with my own layout that would be more optimal than the key placement on the standard US qwerty board. That includes defining custom shift states, so a physical key can be used to type a special character and then another special character when shifted. However, since the hotkeys simply stop working if you type too fast I'm thinking that I won't be able to use AHK for keyboard layers. Text mode seems reasonable, however I don't see how it would resolve any of the issues I've been seeing.

I did some more experimentation, and tried to bundle all the code into a single function I could set a hotkey to call with various parameters, but that just made the issues worse and weirder. For example, sometimes keys don't output anything at all, but not in any way I can replicate except by repeatedly typing and waiting for it to happen.

[safetycar]

If I recall correctly I tried something a bit similar in the past but the problem I saw was that typing fast can make you press a new key before releasing the previous one. I don't remember going on after noticing that.

[lexikos]

Like I said, on the US layout, ~ is produced by holding Shift and pressing another key. So when you SendInput("{Blind}~"), it will press and release Shift. You said "I'm not pressing Shift (either via a Hotkey or the actual key)", but KeyHistory would show that you were pressing Shift via SendInput. I do not know why Shift would be sticking down, but it stands to reason that there is higher risk of that happening if you are pressing and releasing it every time you send a character than if you are not pressing it at all.

SendText (or the {Text} mode of other Send functions) sends each character by its ordinal value. It may need to temporarily release modifier keys that you are holding, but it never needs to press any additional modifiers (such as Shift or AltGr) to produce a particular character.

Since you're using {Blind}, you may want to use SendInput "{Blind}{Text}~" rather than SendText "~".

For SendInput and SendEvent, Text mode is equivalent to translating each character to the form {U+nnnn}, where nnnn is the hexadecimal Unicode character code without the 0x prefix; so you can also use {U+007E} with SendInput in place of ~.

[Elequosoraptor]

This morning I repeated my tests and the shift issue vanished...........before I got around to adding {Text} as you suggested. No idea why, I just can't seem to replicate the behavior I had observed and recorded previously.

The addition of {Text} did not resolve anything else however, the hotkeys still randomly fail and typing too rapidly can cause them to 'shut off' entirely, as if no script at all was running. Thanks anyway for the suggestions.