AutoHotkey Community

I've already demonstrated that it's possible to work around the issue. What's stopping you from writing scripts that are compatible with Google Desktop, etc.?

likely i missed something in your workaround. You're having AHK trap *EVERY* window's keys. how do you get AHK's sends to be recognized by programs' hooks loaded before AHK ?

my attempts at traping the key for every program and sending it back with a 'send', 'sendinput', and 'sendevent', seems not to work in various programs-- ie. they miss the key send event generated by ahk... maybe am missing something ? Even when I make a simple ahk compiled script "#A:: send #B" and another "#B:: tooltip ok # B" ... the first script will not envoke the second. Is the idea that one script might be for one program or game, and another script for another seem strange ?

(your 'workaround' does not seem, unless am missing something, to allow for one script to trap #b for program A, and another script to trap #b for program B, something AHK is designed (nicely) to do.)


bottom line: There *is* a conflict with AHK and other programs, some that everyone can test and see, and some apparently worse, that show up on some systems and not others. If you, or anyone wants to make a distribution exe that uses either HOOKED alt, or win keys, or #IfWinActive alt or win keys (as hotkeys), then you are risking conflict with the end users' systems in small ways and large-- even if you don't see the conflict when you test in your own system!! There is no debate about the conflict with sending the control key, it clearly exists. On Every windows system with 'show mouse caret' option enabled, it produces a target circle on the screen with each conflicted hotkey activation of ahk-- you can test this yourself.

And, this is something that is incredibly easy to fix, we know how and where, and can be done even as an option so there is NO RISK to existing ahk scripts. (likely Chris can even improve on the fix here suggested.)

_________________
Joyce Jamce

What're you talking about? I demonstrated how to convert # or ! #IfWin hotkeys to not use the hook, thus taking away the control keypresses.
As I said:

• Hotkeys that use the hook are never triggered by simulated input
• It has nothing to do with whether they were "loaded before AHK."
• # and ! hotkeys that use the hook generate control keypresses, so they're already a problem, never mind AHK's sends. Obviously it won't work if you don't apply the workaround to them!!!
• The whole point of the workaround is to not use the keyboard hook. No hook means no hook order, and Send works fine.

Or are you referring to a program other than AHK? I don't believe I've used any that use the keyboard hook rather than RegisterHotkey.

It works fine in the last example I posted...Hmm... I just tried that, and it seems #b is using the keyboard hook. #a in my earlier tests was NOT. Even using the the following two scripts, it seems #a always uses RegisterHotkey, and #b always uses the keyboard hook. It doesn't matter what order they're loaded in.


It seems #b focuses the system tray. Maybe Windows has already registered that hotkey (though it isn't documented) and this prevents AHK from using RegisterHotkey for #b?

As I said, the workaround is to not use the keyboard hook. If AHK decides to use the keyboard hook regardless, the workaround can't be applied.


One other workaround that I think hasn't been mentioned - register your own keyboard hook. Search MSDN or the AutoHotkey source code for SetWindowsHookEx and WH_KEYBOARD_LL, or see this post by Laszlo.

by having your script handle every (ex.) #A, and then sending a simulated #A *every* time #A is pressed (except for single intended window), you're replacing *every* actual #A with simulated #A. This does not work with may cases and many apps. exactly the problem.Not if you use the very cool #IfWinActive feature!!!1. sometimes hooks needed. 2. send doesn't work fine, even with the simple example of 2 AHK scripts running, wanting same hotkey but for 2 different windows. this works great if you use the #IfWinActive. It doesn't work with your suggested workaround. Or did I miss something ?You really think AHK is the only program that uses a key hook ???!

ok... now we're talking the same langauge!!!



bottom line is there is a conflicts problem with the ahk 'system' generated control sends. Allowing user CONTROL over that, turning off the ahk generated controls (as developed in this thread), makes AHK better, and eliminates the conflict.

Conflicts are not good, making AHK more flexible, more compatible, more invisible in its work *is* good. Allowing the AHK 'coders' to distribute scripts without having to worry about conflicts with the windows show caret feature, and without risk of conflicts with other control and control-control based programs... is, hopefully *good* and desired. When there is benefit and no risk... when AHK GAINS SOMETHING and LOSES NOTHING... maybe a simple fix worth doing ?? (at least that's my view).

_________________
Joyce Jamce

If you'd care to list these cases and apps, I'd like to hear them. If AutoHotkey's simulated input were that unreliable, most of us wouldn't be here.
Please explain? I had #IfWinActive hotkeys in mind when I said "# and ! hotkeys that use the hook." #IfWinActive causes the keyboard hook to be used, thus indirectly causing the control keystrokes. How can you say "not if you use #IfWinActive"?
That is exactly what my (more recent) demonstration does - shows how to implement one hotkey from two different scripts, "for 2 different windows." The issue isn't whether Send will work, but whether the hotkey can be implemented without the hook. (i.e. #a can, #b apparently can't.)>> http://www.autohotkey.com/forum/viewtop ... 207#143207 <<
No, I said I haven't used any (besides AHK.) Regardless, keyboard hooks can detect simulated input, it's just AutoHotkey's hook that ignores it. (This is why you see "artificial" keypresses in the KeyHistory, even though they were sent by a different script.) Heck, it's even possible to write a script to block the artificial control key-presses. It's less than ideal, though, since it may be hard to tell whether the user actually wants them.
I'm not (specifically) disagreeing with you on that. Chris has already stated his reasons for not wanting to implement it. It seems to me that your time would be better spent exploring workarounds (or patching AutoHotkey yourself) than repeating what you've already said.

If my send workaround isn't usable, dig deeper.See also LowLevelKeyboardProc.


Edit: Sean, I noticed when sending {sc05DvkFF} (your seemingly non-existent key), AutoHotkey recognises it as "F9 05D". I confirmed this using MapVirtualKey() - scancode 0x5D belongs to VK_EREOF, which MSDN describes as "Erase EOF key." The following script generates a list of scancodes that don't map to virtual keycodes (at least in the current keyboard layout.)

Same here. It's still a bit mysterious why I had chosen that key. At least it's not mapped into any vkcode according to the table of keys I've been keeping. At that time when I was choosing the key, DllCall() or alike wasn't available there, which is now available, I guess. That might be the main reason why I used only KeyUp event to not cause an expected consequence as most keys don't do anything particular at KeyUp.

Instead of removing or replacing the control keypresses, I thought I'd try sending yet another keypress to prevent Windows from recognizing it as a raw control keypress.This sets a keyboard hook. When it detects an artificial control key-release (while Win or Alt is down), it simulates a keystroke. This seems to work in preventing Windows' show cursor feature. To hopefully prevent any problems with sending the keystroke, the hook blocks it from other applications and hooks later in the hook chain. (You may need to disable this part for it to work with third-party apps that use raw Control.)

Interestingly, it is valid to send vk00sc000 using keybd_event(). Though it takes up "space" in AutoHotkey's key history, it doesn't actually show up (effectively removing the oldest key event.)

Test script:

That's probably because LL hook recognizes their vkcodes as 0xA4 and 0xA5, not as 0x12.
Anyway, are you sure if GetKeyState("Alt","P") is not more appropriate here?
Hmm, on second thought, GetAsyncKeystate may not be appropriate here, might work at the lower level than LL hook.

Yeah, thought as much. I mostly wrote that Note so no-one would try to "optimize" by replacing LAlt & RAlt with just Alt.

I don't think ,"P" would be appropriate, since the artificial control keypress occurs when the user physically releases the key, but before the logical state is "released."

Your creative sparks are indeed a pleasure.
his reasons now are articulated down to two:

as discussed in thead, it is not at all 'rare' to press two hook alt hotkeys one after the other, without pressing an non-hotkyes in bettween.. I do it daily when i jump more than 1 paragraph, or when I change the background transperency, etc. etc.

and, in exact same light, the keystrokes immediately (no time lag) follow eachother in a normal AHK use...

ie. each time Chris articulated some reservation for including the non-control key send fix as an OPTION, (which is legitimate), responded directly to that reservation/thought.

if Chris was saying 'it's rare for someone to press two hotkeys one after the other, so no need for any fix' then.. hopefully my efforts to explain why that misses many AHK use, would be helpful.

Obviously if the reason for not fixing the AHK conflict is something else, than any response simply waste of time.





Gosh, you're guidance in that direction would be fantastic.

Can't seem to find the source code for the ahk2exe compiler,
and am very unclear about generating the BIN file...

just to note: if user has option to set hotkey, you don't know if will end up a hooked key or not. Any macro/function that uses key for stepping (volume control, transparency level) , zooming, or moving (to end of paragraph, etc.), if key ends up as hooked, generates the double AHK generated control keypress.

And, since hotkeys are central to the core functions of AHK, and the monitoring / sending of keys also one of the core functions.... the issue and fix is significant.

It isn't just explicitly hooked, or explicitly #IFWinActive hotkeys. It's (for the reasons that they need the hook), also simple hotkeys like #B, #C and #D, etc.

_________________
Joyce Jamce

There are two possiblities when pressing two consecutive Alt hotkeys:

• You hold down alt, press both hotkeys, then release Alt. In this case, there is only one artificial control keypress, since it occurs as you release the Alt key.
• You hold down alt, press a hotkey, then release Alt; and repeat. In this case, there is an Alt keypress between the first and second artificial control keypresses.

Either way, that won't trigger a true double-press of Control. If the app sees it as such, the app needs to be fixed.
You don't need the ahk2exe source, just the AHK source code. The VC++ Project file has two build configurations ("SC...") for building AutoHotkeySC.bin.
Does running my script prevent the artificial control keypresses from being recognized? FYI, it doesn't matter if you use hook hotkeys, nor does it matter which script you put them in; with that hook-hack in place.

I did have one very strange issue - where one of my hotkeys would randomly ignore CoordMode, show it's menu in the wrong place, and not activate it. Explicitly setting CoordMode in the hotkey seemed to fix it. Setting the default CoordMode had no effect... (It uses MouseGetPos and TrackPopupMenu instead of Menu,..,Show.)
You aren't very attentive, are you?I agree completely with:
Interestingly, the Alt key and Win key can be used to cancel each other out.

have tried this, (could not seem to gen the .bin, but tried to compile using older exe with newer bin...) get garbage exe.

You have tried this with packaged exemaker with later/changed source compile ?


also,

perhaps am mis-understanding,

are you saying that AHK as we know it is *not* really all open-source,

ie. that the exe maker is not open-source ???



@lexikos,

actually did you miss the bit about this being an option ?

no risk to anyone.


same



there is a conflict with the built in windows locate mouse caret function, acknowledged to effect every system that uses that feature.

there is conflict with at least one langauge control program which uses the control key, and despite you're analysis that multi-controls are not generated.. there is conflict with at least 3 programs (including google DTS) which i've tested.




not if made an option. no-one has asked to change the default behavior, just to provide the option of eliminating the conflicts caused by AHK's sending control keypresses upon hotkey presses.

_________________
Joyce Jamce

The problem I can see with that, if I'm understanding correctly, is that it could potentially cause conflicts with anything hotkey related. Creating an optional workaround that could possibly present other, seemingly unrelated issues to users if the option is used might not be worth adding if it only affects a very small number of scripts in a very small number of cases. The current methods in use so far sound like the lesser evil. Further development and testing would probably be necessary to justify the change. Since Chris has decided that this doesn't seem to qualify as a high priority item, it sounds like it might be better for someone else to design an alternate method, provide a test version for a large number of people to test, then present the results as a proposed change to AutoHotkey once testing/updates are complete and a decidely stable version has been developed.

One alternative might be to spend time writing a few scripts (the more the better) and listing issues with specific applications (the more the better) and ways to consistently reproduce the issues to demonstrate why this issue should be given priority. So far, the side effects seem to be minimal...

That's my 2 cents anyway...

this script
creates this key history


using latest AHK build.



notice the 2 control key presses ahk gens.


1. this pops goolgle DTS right up.

2. even if the double control send is fixed (not clear to me why Ahk does this), the conflict still exists with the windows feature, in multiple hotkey scenerios, etc.

3. can it be that I am the *only* one distrubed by this ??


Do others understand that:

1) keyhooks are EVERYWHERE: when you ask for them "$", when you use #IFWinACtive, and when it's 'necessary' #B, #C,#D, etc. etc.

2) when keyhooks apply, any alt (!), or winkey (#) hotkey will cause a giant animated circle to popup (at every hotkey press/release) in *every* windows system that has the 'show mouse caret' function enabled.

If this is your script on someones machine with this windows setting, it makes a mess on their every time they use a relevant hotkey....

3) other 'end' users may have single control activated programs, which will go crazy if your script is run on their machine. (this is what happened to my script and gave birth to this thread).

4) have not figured out when/why but often, not always, a double control results and google desktop search, and other DOUBLE control activated programs get activated.

5) the fix is suggested/requested as an option, not breaking any existing script in any way.

_________________
Joyce Jamce