Some hotstrings disable Hotkey in another script, why?

[list]

This could be an incredible newb error, if so my bad, and feel free tell me to read the manual

It seems that a simple hotstring can disable a Hotkey from another script even though they are unrelated. I've tested this on Windows 7 and Windows 8, 32 and 64 bit.

To replicate you need two scripts.

Script 1 - the hotkey script, save this and start it, press INS to confirm the hotkey works.

Code: Select all

HotKey, Ins, label
Return

Label:
MsgBox You pressed INS
Return

Script 2 - the hotstrings script.
Save this and start it, press INS to see if still work.
Now type bt1 space -> it types by the way, press INS it should still work,
Now type bt2 space -> it types mört, press INS it should still work,
Now type bt3 space -> it types Mört, press INS and you should notice that INS no longer works,

Code: Select all

::bt1::by the way ; hotkey works
::bt2::mört       ; hotkey works
::bt3::Mört       ; now the hotkey no longer works?

So with lower case mört no problem, upper case M and INS is gone, also happens with € for example*

How can I fix script 1 (the hotkey script) so script 2 no longer disables the Hotkey? (I've tried various #...Hooks and $Ins but to no avail.

* HT boiler in the lintalist thread

[Rohwedder]

With my German keyboard and Win 7 64bit, I do not have this problem. Only when I switch to English keyboard.

[list]

I'm guessing the fact ö is part of your German keyboard layout has something to do with it. Good to know.

[guest3456]

Is it only Insert which fails? Does InputLevel/SendLevel help any?

[list-nli]

No not just INS, same happens with:

Capslock
Del
Home
F1
Scrolllock
Numlock
PgDn
`
(haven't tested others)

but not with:

%
a
^a

for example.

[guest3456]

Might have to wait to see what Lexikos says

[Helgef]

It seems to happen to all hook-hotkeys.

[guest3456]

bump

[list]

bump2

[4GForce]

It probly sends an easter egg code to Lexikos's troll bot everytime you use that hotstring !

AHK Unicode ( under win7 64 )

• From UTF-8 script file
  SendInput % "Mört" ; --> Mört
• From Ansi script file
  SendInput % "Mört" ; --> Mört
• Ansi back to UTF-8
  "Mört" ; --> "M�� ( actually show as MxF6rt in np++)

[guest3456]

.

ping

[lexikos]

Code: Select all

F1::Send Mö
F2::Send Mµ
F3::Send M{ASC 0181}

Code: Select all

Ins::MsgBox 1
+Ins::MsgBox 2

Press Ins -> 1
Press F1 -> Mö
Press Ins -> 2
Press LShift
Press Ins -> 1
; It's clear that the Ins script is not catching the LShift-up event when it's followed by a character not on the keyboard layout.
Press F2 -> Mµ
Press Ins -> 2
; µ is sent the same way, so this is to be expected.
Press LShift
Press F3 -> Mµ
Press Ins -> 2
; So apparently, it happens with both the VK_PACKET (Unicode) method and the Alt+Numpad method.

but not with:

%
a
^a

All hook hotkeys act as though the Shift key is still pressed, until after you press Shift. That includes these three hotkeys if they are using the hook. "Reg" hotkeys are unaffected because they are implemented by the OS; i.e. the OS tracks the modifier state for those.

When the modifier state is changed to send 'M', by default the keyboard events are flagged as "ignore all except modifier" (so really only ignore the mask key). The problem is that when the modifier state is set prior to sending a special character, it is explicitly flagged as "ignore all", so other scripts ignore the events, effectively leaving (their record of) modifier keys in the pressed state.

I can't imagine why "ignore all" was used there, but it has to be changed.

It's fixed in v1.1.25.01.

[boiler]

Works like a charm. Thank you!

[list]

Thanks!