 |
AutoHotkey Community
Let's help each other out
|
| View previous topic :: View next topic |
| Author |
Message |
Joy2DWorld
Joined: 04 Dec 2006
Posts: 561
Location: Galil, Israel
|
 Posted: Sat Aug 25, 2007 11:33 pm Post subject: |
 |
|
| lexikos wrote: | Interesting. I replaced all instances of | Code: | | KeyEvent(KEYDOWNANDUP, VK_CONTROL) |
(5 in hook.cpp, 1 in keyboard_mouse.cpp) with | Code: | | KeyEvent(KEYDOWNANDUP, 0xFF, 0x0FF) |
and it seems to work. Instead of Control keypresses, it generates: | Code: | FF 0FF i d 0.00 not found
FF 0FF i u 0.00 not found |
(0x05D also works in place of 0x0FF.) |
Interesting indeed.
(@ Sean, That's brilliant!!!)
_________________
Joyce Jamce
Last edited by Joy2DWorld on Sun Aug 26, 2007 2:57 am; edited 1 time in total |
|
| Back to top |
|
 |
Lexikos
Joined: 17 Oct 2006
Posts: 7299
Location: Australia
|
| Posted: Sat Aug 25, 2007 11:49 pm Post subject: |
|
|
Using KEYUP instead of KEYDOWNANDUP seems to work equally well, but only puts one "not found" in the key history instead of two.  |
|
| Back to top |
|
|
Joy2DWorld
Joined: 04 Dec 2006
Posts: 561
Location: Galil, Israel
|
| Posted: Sat Aug 25, 2007 11:59 pm Post subject: |
|
|
| Quote: | | Is that a Windows feature? As far as I can tell, Windows only has Ctrl+Shift, Left Alt+Shift or Grave Accent (`) to switch input languages. |
and | Quote: | Either way there is no point in disabling the control keypresses.
I did, however find another workaround - don't use the keyboard hook. For example, instead of: |
1. Yes on my own system it is ctrl+shift, which is why didn't encounter the AHK problem originally. There is, as have learned the hard way!!! a freeware tool allowing use of just the control key, via long keypress or via single/double press.
in looking into issue, found about half a dozen programs that use the naked control key as a program trigger or shortcut.
2. stopping the startmenu popup is (if not otherwise obvious) needed, but can be done intentionally from within the triggered script.
3. am a HUGE fan of AHK, and just have some frustration that some fundamental 'issues' didn't make it to the language doc file....
4. the KeyEvent(KEYDOWNANDUP, 0xFF, 0x0FF) looks like an easy solution,
just hope can encourage Chris to include the fix *at least as an option* in the standard AHK release....
having to worry about distributing a forked AHK version kills part of the idea, of using the install to share/educate about the powers of AHK...
(hmmm... worse than that.... apparently can only compile if you have NET 2.0+ installed... uggg.... well.. that's MS foryou...)
_________________
Joyce Jamce |
|
| Back to top |
|
|
Joy2DWorld
Joined: 04 Dec 2006
Posts: 561
Location: Galil, Israel
|
| Posted: Sun Aug 26, 2007 12:27 am Post subject: |
|
|
KeyEvent(KEYUP, 0xFF, 0x0FF) looks like an easy solution,
just hope can encourage Chris to include the fix *at least as an option* in the standard AHK release....
note that | Code: | #a::
IfWinActive, foo
{
tooltip foo
}
else ; this bit is only really necessary if #a actually does anything...
{
Hotkey, #a, Off
Send #a
Hotkey, #a, On
}
return |
isn't really a workaround as the 'sent' hotkey will get missed by other programs depending on the hook order...
ie. if non-obvious, loading a #a triggered hotkey script before, and another after this 'work around' , you should find that the sent #a is only sent to the subsequently run script...
ie. this 'workaround' not work...
but KeyEvent(KEYUP, 0xFF, 0x0FF) looks like an easy solution,
hope can encourage Chris to include the fix *at least as an option* in the standard AHK release....
_________________
Joyce Jamce |
|
| Back to top |
|
|
Lexikos
Joined: 17 Oct 2006
Posts: 7299
Location: Australia
|
| Posted: Sun Aug 26, 2007 1:29 am Post subject: |
|
|
| Joy2DWorld wrote: | | (hmmm... worse than that.... apparently can only compile if you have NET 2.0+ installed... uggg.... well.. that's MS foryou...) |
Nonsense. | Joy2DWorld wrote: | isn't really a workaround as the 'sent' hotkey will get missed by other programs depending on the hook order...
ie. if non-obvious, loading a #a triggered hotkey script before, and another after this 'work around' , you should find that the sent #a is only sent to the subsequently run script... |
Also nonsense. If you load another #a:: script after the workaround, it will override the workaround so #a will never even be sent.
test1.ahk | Code: | #a::
Hotkey, #a, Off
Send #a
Hotkey, #a, On
msgbox #a sent
return |
test2.ahk | Code: | #a::
msgbox #a
return |
If you load test2.ahk second, it overrides test1.ahk - i.e. #a is never sent. If you load test2.ahk first, test1.ahk sends #a and properly triggers test2.ahk. |
|
| Back to top |
|
|
Joy2DWorld
Joined: 04 Dec 2006
Posts: 561
Location: Galil, Israel
|
| Posted: Sun Aug 26, 2007 2:32 am Post subject: |
|
|
| lexikos wrote: | | Joy2DWorld wrote: | | (hmmm... worse than that.... apparently can only compile if you have NET 2.0+ installed... uggg.... well.. that's MS foryou...) |
Nonsense.
|
interesting.
You can compile it without the MS Net 2.0(+) framework installed ?!
| Quote: | Also nonsense. If you load another #a:: script after the workaround, it will override the workaround so #a will never even be sent.
|
what ?!??!!
in AHK you can limit the intercept of the hotkey via #IfWinActive
which allows bypass-non-intercept of the hotkey.
so if script #1 (LOADED FIRST OR SECOND) has a hotkey #A, but limited with #IFWinActive... then pre or post loaded scripts or programs still get the #A...........
you suggest work-around, not using #IfWinACtive, ie. not using this hook structure...
but the suggestion doesn't work, as explained above...... the script sent #a is only sent to the subsequently run script... and NOT a prior loaded one...
script #1 first run this:
| Code: | #NoEnv ; Recommended for performance and compatibility with future AutoHotkey releases.
SendMode Input ; Recommended for new scripts due to its superior speed and reliability.
#ifwinactive Test
#a::
msgbox you got me !!
return
|
Script #2, run it next:
| Code: | #a::
send #a
return |
and you will see clearly that the second script IS run, but the first one not (assume from window start with "Test").
which is all to say that, attempting to use a 'send' in conjuction with a window test, as an alternative to #IFWinActive .... just doesn't work unless you happen to have all the script load in exactly right order...
with that... the the KeyEvent(KEYUP, 0xFF, 0x0FF) does sure look like a great solution,
and just hope can encourage Chris to include the fix *at least as an option* in the next AHK release....
_________________
Joyce Jamce |
|
| Back to top |
|
|
corrupt
Joined: 29 Dec 2004
Posts: 2485
|
| Posted: Sun Aug 26, 2007 3:21 am Post subject: |
|
|
| Joy2DWorld wrote: | | (hmmm... worse than that.... apparently can only compile if you have NET 2.0+ installed... uggg.... well.. that's MS foryou...) |
I think that might be the case if using VC++ 2005 Express but AFAIK the VC++ 2005 Express installer should take care of that for you unless you have beta versions installed that may cause conflicts. Here's a page that may give info if that's the case. I don't understand though... If you have gone to the trouble of installing VC++ and the necessary SDK libraries then why is having to install .NET 2.0 (+) (if necessary) an issue... ? |
|
| Back to top |
|
|
Joy2DWorld
Joined: 04 Dec 2006
Posts: 561
Location: Galil, Israel
|
| Posted: Sun Aug 26, 2007 3:34 am Post subject: |
|
|
| corrupt wrote: | | If you have gone to the trouble of installing VC++ and the necessary SDK libraries then why is having to install .NET 2.0 (+) (if necessary) an issue... ? |
support number of systems with limited HD space, they simply cannot afford the net2 overhead. If add net2, no longer easy to debug program conflicts, especially net1/2 related.
net2 runs way to slow in virtual machine.... (unless somehow missed a key part of install... when tried it...)
_________________
Joyce Jamce |
|
| Back to top |
|
|
corrupt
Joined: 29 Dec 2004
Posts: 2485
|
| Posted: Sun Aug 26, 2007 3:37 am Post subject: |
|
|
| Joy2DWorld wrote: | | corrupt wrote: | | If you have gone to the trouble of installing VC++ and the necessary SDK libraries then why is having to install .NET 2.0 (+) (if necessary) an issue... ? |
support number of systems with limited HD space, they simply cannot afford the net2 overhead. If add net2, no longer easy to debug program conflicts, especially net1/2 related.
net2 runs way to slow in virtual machine.... (unless somehow missed a key part of install... when tried it...) |
.NET 2.0 is not necessary to run AutoHotkey.exe after compiled AFAIK... |
|
| Back to top |
|
|
Lexikos
Joined: 17 Oct 2006
Posts: 7299
Location: Australia
|
| Posted: Sun Aug 26, 2007 5:28 am Post subject: |
|
|
| Quote: | | and you will see clearly that the second script IS run, but the first one not (assume from window start with "Test"). |
#IfWinActive forces the use of the keyboard hook, and as a side-effect prevents simulated input from triggering the hotkey. The hook order has nothing to do with it. Heck, one script isn't even using the keyboard hook.
The workaround must be applied to every script that uses the hotkey. For example: | Code: | #a::
ifwinactive, ahk_class Progman
{
msgbox desktop!
return
}
hotkey, #a, off
Send #a
hotkey, #a, on
return |
| Code: | #a::
ifwinactive, test
{
msgbox you got me !!
return
}
hotkey, #a, off
Send #a
hotkey, #a, on
return |
These will work regardless of the order they're loaded in. (Neither uses the keyboard hook.)
Hey, wasn't the original purpose for the workaround to avoid those control keypresses?? If you only apply the workaround (remove the hook) to one script, the other will still generate control keypresses... 
If I recall correctly, the Windows SDK (formerly known as the Platform SDK) includes a VC++ compiler; and it's free to download. I'm quite certain it doesn't require the .net framework. It likely won't be as simple to set up, though.
| corrupt wrote: | | I think that might be the case if using VC++ 2005 Express |
Can you even install VC++ Express without the .Net Framework? It can't build native win32 apps out-of-the-box... |
|
| Back to top |
|
|
corrupt
Joined: 29 Dec 2004
Posts: 2485
|
| Posted: Sun Aug 26, 2007 6:57 am Post subject: |
|
|
| lexikos wrote: | | corrupt wrote: | | I think that might be the case if using VC++ 2005 Express |
Can you even install VC++ Express without the .Net Framework? It can't build native win32 apps out-of-the-box... |
That was the point. If you quote a bit further...  | Quote: | | I think that might be the case if using VC++ 2005 Express but AFAIK the VC++ 2005 Express installer should take care of that for you... |
|
|
| Back to top |
|
|
Chris
Site Admin
Joined: 02 Mar 2004
Posts: 10716
|
| Posted: Mon Aug 27, 2007 6:11 pm Post subject: |
|
|
I appreciate all the research and findings that have been posted. While I can see that there is some reason to change the current behavior, there are also several reasons against it:- Although the "control-up only" method appears to work the Alt key, it doesn't work for the Start Menu (at least not always). Thus, it wouldn't be a complete solution.
- Sending the 0xFF virtual key instead of VK_CONTROL has a significant risk of breaking existing scripts, especially games and other apps that might recognize and respond to any non-modifier keystroke (even 0xFF). In fact, some apps might recognize and respond only to scan codes (ignoring the virtual keys). In such cases, if the low-order byte of the scan code matches that of any other key on any keyboard layout/language, it would probably produce unwanted characters for some users.
- Any change to this area (even minor) could break existing scripts because Alt and Win hotkeys are very common, and blocking the Start Menu and the menu bar are complex areas. Therefore there's a good chance that more people would be harmed than helped. In such cases, I usually err on the side of not making any changes.
- I've seen no evidence that the current behavior (control-down + control-up) affects anyone other than Joy2DWorld and perhaps one other person in an old topic. If there's evidence that this affects more than 1 out of 1000 users, please post it. Otherwise, I think there shouldn't be any changes to the default behavior due to the risk of doing more harm than good.
| Sean wrote: | I think I once experimented on this, why then system hotkeys defined through RegisterHotkey don't show this symptom. ...I believe what I observed was that it suppresses only the Key-Down event, do nothing to the Key-Up event of the hotkey.
I'm not sure if this behavior would cause a problem with AHK, e.g., with KeyUp hotkeys etc.
Certainly, it'll cause annoyance like activating Start Menu if an user doesn't follow the rule of the (KeyDown) hotkeys, i.e., releasing the modifier keys before releasing the hotkey itself.
And, I'm aware of keys which generate only KeyDown event but no KeyUp event, though they are very rare.
I just looked at my script (written in other app) ...Looks like I accompanied ONLY CTRL KEYUP, not Ctrl KeyDown+KeyUp.
Actually, the key wasn't Ctrl key, seeming an artificial non-existent key like SC:05D, VK:FF. |
Thanks for that info. It has already proved valuable to others here, and I expect it will help me in the future.
| Joy2DWorld wrote: | (please... also allow at least the flexibility to have option to TURN OFF sending CONTROL KEY PRESSES when ALT hotkey activations release the ALT key!!!)
...to include a #TURNOFFAUTOCONTROLKEYPRESSES option........
...the KeyEvent(KEYDOWNANDUP, 0xFF, 0x0FF) looks like an easy solution,
just hope can encourage Chris to include the fix *at least as an option* in the standard AHK release.... |
I'd like to see evidence that the control keystrokes affect a sizeable number of users. After all, pressing down the Control key in combination with ALT is extremely common (even the operating system's own built-in hotkeys seem to prefer the Control+Alt modifier combination). This implies that the extra Control keystrokes should be harmless on the vast majority of systems.
In any case, I appreciate the idea of creating a new option to change the control keystrokes into some other keystroke (or none at all) . However, without evidence that this affects more than 1 out of 1000 people, I think the option should be a low priority relative to other improvements.
Thanks. |
|
| Back to top |
|
|
corrupt
Joined: 29 Dec 2004
Posts: 2485
|
| Posted: Tue Aug 28, 2007 5:35 am Post subject: |
|
|
| Perhaps a beta (or unofficial) release could be put together for people to test to see if an alternative method could be used without introducing unwanted side effects? |
|
| Back to top |
|
|
Chris
Site Admin
Joined: 02 Mar 2004
Posts: 10716
|
| Posted: Tue Aug 28, 2007 9:56 am Post subject: |
|
|
| If anyone wishes to do that, I'd welcome it. However, I think the criteria would be that the change should adversely impact no more than 1 out of 1000 users (unless someone comes up with evidence that the current behavior impacts more than 1 out of 1000). To determine that statistically, it seems that at least 3000 users (simulated or real) would need to test their scripts in a broad variety of applications, games, keyboard layouts, and languages. |
|
| Back to top |
|
|
J2DW as guest
Guest
|
| Posted: Tue Aug 28, 2007 3:15 pm Post subject: |
|
|
| Chris wrote: | In any case, I appreciate the idea of creating a new option to change the control keystrokes into some other keystroke (or none at all). However, without evidence that this affects more than 1 out of 1000 people, I think the option should be a low priority relative to other improvements.
|
gosh,
you obviously know best, but we're talking about merely parsing one additional #TURNOFFUNWANTEDCONTROLKEYPRESSES directive,
and making what is the up/down send based on that... (ie. control vs. 'null'/'non-key/0xFF).
*EVERYONE* who uses the 'find cursor by control key press' option of their Windows is annoyed by a floating circle at evey hooked alt or winkey hotkey activation.
*EVERYONE* who uses any of the control key based apps.. is effected.
maybe it's just an annoyance for them,
maybe they just mark it up as AHK is not compatible with them, and move on...
but ... gosh...
tiny amount of coding to add option of 'taming' an AHK behavior...
seems like that makes AHK better... yes ? |
|
| Back to top |
|
|
|
|
You can post new topics in this forum
You can reply to topics in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Register
Profile
Log in to check your private messages
Log in
