Code: Select all
LCtrl::
keywait,LCtrl
tooltip, % A_TimeSinceThisHotkey
return
Code: Select all
LCtrl::
tooltip, % A_TimeSinceThisHotkey
return
Code: Select all
LCtrl::
keywait,LCtrl
tooltip, % A_TimeSinceThisHotkey
return
Code: Select all
LCtrl::
tooltip, % A_TimeSinceThisHotkey
return
Code: Select all
LCtrl::
Sleep 500
start:=A_TickCount
keywait,LCtrl
tooltip, % A_TickCount-start
return
I'll try again . The code shows the realtime delay between the reaction of keywait on event "Lctrl released", which should be zero, but it's obvious that it's much more (time difference between real quick press\release i.e. 100ms (quick keypress with keywait reaction) minus actual time 20-50ms that should've been displayed). It's about life delays between presses of Lctrl (they should be as I said 20-50 per press) and delays that are produced by keywait command - which are significantly higher (two times, wow ) in my case (~100ms per press ) . But they should be 20-50ms . I don't know how to make it more explicit.Helgef wrote:I'm not sure I understand what you mean. Your examples behaves as I expect.
Hi, Exaskryz, "as low as" and "average" are the serious differences here, I've got as low as 32ms , but the average time is about plus\minus hundred ms.Exaskryz wrote:I don't think KeyWait has any inherent delay, but there may be a keyboard driver level delay. I get timings as low as 47 milliseconds with your first code block.
An interesting experiment of yours. I think it proves that keywait has (after all) some inherent delay (kick-in time, you name it) . Just about those afore-mentioned 50ms. Or at least something produces that delay but I'm at loss what it is. Cause the code is as simple as it gets.Exaskryz wrote: I am getting back times of 0, but I've given myself plenty of time to release the key before it tried to capture a time and check for the key to be released.
Even if you use a Sleep 50 I'm able to get the KeyWait to process in <15ms and thus report as 0 ms in the tooltip.
Code: Select all
~LButton::
keywait,LButton
tooltip, % A_TimeSinceThisHotkey
return
The code shows the time between the hotkey triggering and executing the tooltip line, in both cases. Do you see any difference with this codeThe code shows the realtime delay between the reaction of keywait on event "Lctrl released", which should be zero
Code: Select all
LCtrl::return
lctrl up::tooltip % A_TimeSincePriorHotkey
the reaction of keywait on event "Lctrl released" should be zero andHelgef wrote:The code shows the time between the hotkey triggering and executing the tooltip line
like you said should much quicker than 77ms average or so (as I said so many times - 20-50ms is the real (I repeat) real-life timing of quick press\release). If you'd type with 77ms average you'd be a very slow typist .triggering and executing
Course I see no difference, my friend. As I said before I've tried many different and cunning alternatives which includes LCtrl down:: LCtrl up:: combos. It's all the same difference, so that's why I'm here.Helgef wrote:The code shows the time between the hotkey triggering and executing the tooltip line, in both cases. Do you see any difference with this codeCode: Select all
LCtrl::return lctrl up::tooltip % A_TimeSincePriorHotkey
Code: Select all
p::return
p up:: sendInput, p
I don't think so. Average word length is 5(.1) letters. That means it would take 385 ms to type 5 words. Add in a space or punctuation mark for a sixth character = 462 ms if my mental math is right. That means you are typing at at least 2 words per second which is at least 120 words per minute which is considered fast. Apparently the average is 33 wpm, which I'm sure includes elderly and those unfamiliar with computers. However, from Wikipedia:If you'd type with 77ms average you'd be a very slow typist .
So it has nothing to do with KeyWait.CAH9t wrote:Course I see no difference, my friend.
Of course you mess up normal typing with that, a is produced on key a down, and p on p up. TryAnd Type "papa" really fastCode: Select all
p::return p up:: sendInput, p
Code: Select all
p::return
p up:: sendInput, p
a::return
a up:: sendInput, a
Code: Select all
#installkeybdhook
keyhistory
Man, Read my first post.Helgef wrote: So it has nothing to do with KeyWait.
So it has to something to do with keywait also (and the others) whether you call it or not. It has everything to do with fundamentals that are behind keywait, getkeystate and LCtrl up:: that's why I want some help\advice from big guys. The problem is in the release-event-checking in ahk so it's global.no matter the key ; getkeystate alternative, "LCtrl down:: LCtrl up::" cunning alternative
I'm not messing anything. It's just funny (I don't know ha-ha or peculiar) that you've encountered the problem by yourself and still arguing that it exists. The people type just like that p down p up, a down a up, just very quick, they're the basics of typing without typos, please, don't argue it, that's an axiom, no offence. And because ahk is still waiting for the release of p while I've already upped it, you type "a" first cause it has no delay caused by the subj.Of course you mess up normal typing with that
Code: Select all
p::return
p up:: sendInput, p
a::return
a up:: sendInput, a
Unfortunately, you can't blame it on keywait. Helgef has provided an example where KeyWait is not involved and still you have issues with it. So there is something else, which I suspect it is your keyboard driver, that is causing the problem.CAH9t wrote: So it has to something to do with keywait also (and the others) whether you call it or not.
Can you provide an example where using something other than AHK allows you to achieve what you are looking for?CAH9t wrote:So it has to something to do with keywait also (and the others) whether you call it or not. It has everything to do with fundamentals that are behind keywait, getkeystate and LCtrl up:: that's why I want some help\advice from big guys. The problem is in the release-event-checking in ahk so it's global.
This is not only not an axiom, it is absolutely false. Although it is possible to type that way, it would make touch typing much slower and very tedious if it had to be done that way. You can even see it in slow-motion videos of people typing. Helgef has proven it to you in several ways, and you refuse to listen or even entertain his demonstrations, apparently.CAH9t wrote:The people type just like that p down p up, a down a up, just very quick, they're the basics of typing without typos, please, don't argue it, that's an axiom, no offence. And because ahk is still waiting for the release of p while I've already upped it, you type "a" first cause it has no delay caused by the subj.
Code: Select all
; This is the series of tests to test the reaction-time of ahk on release-key event (keyboard key). The problem is in the release-event-checking in ahk. In my version of tests ahk is unable to catch in time that the first key pressed is released, before I typed the second so it results in a typo ("apap")
; 1st test try to type papa with your fastest type speed ( If your output is "apap", please report it).
p::return
p up:: sendInput, p
/*
; 2nd test try to type "papa" with your fastest type speed. Don't forget to comment the other tests. ( If your output is "apap", please report it).
SC019:: ; it's important for the experiment, that SC019 in my layout is a scancode for "p" key.
keywait, %A_ThisHotkey%
sendInput, {%A_ThisHotkey%}
return
; 3rd test try to type "papa" with your fastest type speed. Don't forget to comment the other tests. ( If your output is "apap", please report it).
SC019:: ; it's important for the experiment, that SC019 in my layout is a scancode for "p" key.
while GetKeystate(A_ThisHotkey,"P")
{
}
sendInput, {%A_ThisHotkey%}
return
*/
Dear Helgef, we were on different pages from the get-go (as in first page and the last one). That's me who is to blame, because I should've stopped trying to explain myself right there, instead of trying to explain simple things redundantly thousand times. I respect your expertise and trying to help. I just thought that if Exaskryz got the drift simultaneously I could've fill you in eventually.Helgef wrote:Dear CAH9t, I'm suspecting we may have hit the language barrier
Friend, you're way quicker than that real-life, trust me. And I presume you're hitting one button very frequent-like so it should be way way quicker than 77ms average. Thank you, again. Till later.Exaskryz wrote:77ms average
Users browsing this forum: Bing [Bot], ghoulishghoul and 52 guests