Random "bugs" in Autohotkey? Topic is solved

Get help with using AutoHotkey (v1.1 and older) and its commands and hotkeys
Nixcalo
Posts: 116
Joined: 06 Feb 2018, 04:24

Re: Random "bugs" in Autohotkey?

10 Feb 2018, 07:07

Xtra, after like 20 tries, your solution seems to have nailed it. A different approach, and it seems to be working perfectly! Not a single random or wrong result! Awesome! You should inform anyone of this, it's great!

I believe I will implement your solution for all my scripts, with the Send, {Ctrl Down}x{Ctrl Up} and all...seems safer than Send ^x...

Thanks you guys, you are all great :)
guest3456
Posts: 3454
Joined: 09 Oct 2013, 10:31

Re: Random "bugs" in Autohotkey?

10 Feb 2018, 13:08

Nixcalo wrote:Xtra, after like 20 tries, your solution seems to have nailed it. A different approach, and it seems to be working perfectly! Not a single random or wrong result! Awesome! You should inform anyone of this, it's great!

I believe I will implement your solution for all my scripts, with the Send, {Ctrl Down}x{Ctrl Up} and all...seems safer than Send ^x...

Thanks you guys, you are all great :)
he is also using KeyWait to make sure that Ctrl is fully released before doing the Send

Nixcalo
Posts: 116
Joined: 06 Feb 2018, 04:24

Re: Random "bugs" in Autohotkey?

10 Feb 2018, 13:39

As a little update, Xtra solution does not work 100% of the time. I would say about 90%, which is way greater that the other solutions and it's definitely an improvement. Sometimes it does not work and what it does is delete what was selected, without replacing it with anything... but a great improvement nonetheless and with this success rate, script is a solution rather than a hindrance. THANK YOU! (Perhaps I have to add some "sleep" somewhere.."
guest3456
Posts: 3454
Joined: 09 Oct 2013, 10:31

Re: Random "bugs" in Autohotkey?

10 Feb 2018, 13:48

can you state what exactly you are doing when it fails? what app are you using? what keys are you pressing? are you running the ^u script standalone or as part of a larger script?

guest3456
Posts: 3454
Joined: 09 Oct 2013, 10:31

Re: Random "bugs" in Autohotkey?

10 Feb 2018, 13:54

Nixcalo wrote: Sometimes it does not work and what it does is delete what was selected, without replacing it with anything...
likely one of the ClipWait's are failing and just returning

try this code and see what it reports when it fails:

Code: Select all

^u::
    KeyWait, Ctrl
    KeyWait, u
    Send, {Ctrl Down}x{Ctrl Up}
    ClipWait, 1
    if (ErrorLevel)
    {
        Send, Initial ctrl-x failed to set the clipboard		
        return
    }    
    Clipboard := Format("{:U}", Clipboard)
    ClipWait, 1
    if (ErrorLevel)
    {
        Send, setting clipboard to uppercase failed
        return
    }    
    Send, {Ctrl Down}v{Ctrl Up}
return

User avatar
Xtra
Posts: 2744
Joined: 02 Oct 2015, 12:15

Re: Random "bugs" in Autohotkey?

10 Feb 2018, 15:16

You can increase the timeout of clipwait to 5 seconds.
If its still failing after this change your computer resources may be limited at the time of failure.
This could be from high cpu/ram usage or a program interfering with the clipboard.
lexikos
Posts: 9560
Joined: 30 Sep 2013, 04:07
Contact:

Re: Random "bugs" in Autohotkey?

10 Feb 2018, 16:49

The fault that lies at AutoHotkey's core is that it is built on top of an imperfect system designed for human interaction, and (by default) drives that system hundreds of times faster than a human does, sometimes with the user trying to drive at the same time.
I am quite certain that Visual Basic, C++ or Delphi manage these quite well.
What is the basis for your certainty? AutoHotkey is written in C++. Have you written any programs to perform copy-paste in external windows? Programs written in all sorts of languages handle copy-paste for their own application, but this is totally different.
(sending a Control X and then sending a Control V, not rocket science, and something other languages do perfectly)
Which other language does this perfectly, and has seen heavy use for this purpose?

Other languages have exactly the same tools to work with: keybd_event (which we call SendEvent), SendInput and journal playback hooks (which we call SendPlay). If any one of those methods was perfect, we wouldn't have all three plus SetKeyDelay.
Masonjar13 wrote:While that is correct, I just want to note that some applications do not allow native pasting
I didn't bother to mention that since the script relies on ^x to copy/cut text, in which case ^v is very likely to paste.

Console windows allow native pasting on all versions of Windows; just not via Ctrl+v. You can access it via WinMenuSelectItem in the preview of v1.1.28.00.
Nixcalo
Posts: 116
Joined: 06 Feb 2018, 04:24

Re: Random "bugs" in Autohotkey?

10 Feb 2018, 17:38

You may be perfectly correct, Lexikos, most likely the problem lies within Windows itself. But definitely a problem is somewhere :(
gregster
Posts: 8922
Joined: 30 Sep 2013, 06:48

Re: Random "bugs" in Autohotkey?  Topic is solved

10 Feb 2018, 18:00

In my experience, if there is a problem, it usually sits in front of the computer.
User avatar
Masonjar13
Posts: 1555
Joined: 20 Jul 2014, 10:16
Location: Не Россия
Contact:

Re: Random "bugs" in Autohotkey?

10 Feb 2018, 22:00

@lexicos, true that you can paste to it, but I did mean just with ^v. And I've also experienced where ^c/x will work, but ^v still does not. Very specific cases, of course. Good job on the new versions by the way, adding great new functionality :thumbup:

@gregster.. Agreed :lol:
To clarify some things:
Getting back on topic, I wasn't able to reproduce any of your issues. What would be best right now is if you tried more thorough testing and post detailed results, such as: what window/interface-type you were interacting with, if you were holding other keys, if any related toggle keys (capslock) were active, etc..
OS: Windows 10 Pro | Editor: Notepad++
My Personal Function Library | Old Build - New Build
User avatar
Cerberus
Posts: 172
Joined: 12 Jan 2016, 15:46

Re: Random "bugs" in Autohotkey?

11 Feb 2018, 17:32

Masonjar13 wrote:
Cerberus wrote:So{Blind} should make the hotkey more reliable, even when both the trigger hotkey and the hotkey to send have the same modifiers, in this case control?
When you hit the hotkey, ctrl will be down. When you send ^x, control is sent down and up, making ctrl logically up, but physically down. Blind makes it so that if ctrl is already down, it won't send it down or up, but just use the physical press instead. And, as it turns out, this doesn't matter at all.
OK I'm not entirely sure I understand. Is it as follows:
Let's say we have this hotkey line:

Code: Select all

^d::Send ^c
1. the hotkey trigger (e.g. my physically pressing the hotkey control-d, or my mouse-gesture programme sending out the hotkey) holds control down;
2. the hotkey trigger then presses the d key;
at this point, the Autohotkey Send command is triggered by the hotkey. But the trigger has not yet released the control key;
3. the Autohotkey Send command sends control down;
4. but! Now the hotkey trigger finishes its business and sends control up (because e.g. I let go of the physical key);
5. the Autohotkey Send command sends c (but now control was not down!);
6. the Autohotkey Send command sends control up.
If that is what you meant, then I think I finally understand why this problem occurs! Otherwise, I would be unable to understand how {Blind} could help, or even why the problem occurs in the first place. Because at first I read it as "the Send command won't release the control key", but that wouldn't make sense, because it would normally only do that after sending canyway.

But what {Blind} does is prevent the trigger (or anything outside the Autohotkey Send command that is currently executing) from sending control down. Is that right?
When {Blind} is the first item in the string, the program avoids releasing Alt/Control/Shift/Win if they started out in the down position. For example, the hotkey +s::Send {Blind}abc would send ABC rather than abc because the user is holding down the Shift key.

{Blind} also causes SetStoreCapsLockMode to be ignored; that is, the state of CapsLock is not changed. Finally, {Blind} omits the extra Control keystrokes that would otherwise be sent; such keystrokes prevent: 1) Start Menu appearance during LWin/RWin keystrokes; 2) menu bar activation during Alt keystrokes.
By "the program", do they mean "the trigger" as above (and not the Autohotkey Send command itself)?
User avatar
Masonjar13
Posts: 1555
Joined: 20 Jul 2014, 10:16
Location: Не Россия
Contact:

Re: Random "bugs" in Autohotkey?

11 Feb 2018, 18:23

Ugh, my browser closed and I lost everything I had written.. so I'll go with the concise version (sorry).

Blind basically does the exact opposite of what you think it does. When Send is used, modifiers, such as shift, are explicitly sent up to avoid altering what you've put there as text to send. So, Send abc will send shift up, if shift is held, prior to sending, to retain its proper case. Send {blind}abc will not release shift prior to sending, if it's physically held, meaning, if you're holding shift, the output will be ABC instead. {text}, I would say, is much better than the default though, because it sends the actual character codes rather than the key codes, making it significantly more reliable. That means that modifiers no longer influence the output at all, because character codes aren't based off the literal keyboard keys as key codes are. While I do believe you can send modified character codes independent of physical or logical modifier state (correct me if I'm wrong, lexicos), {text} does not do this and, instead, acts similarly to/as a better replacement for {raw}. At the fact you may use {blind} with {text}, {raw} appears deprecated, unless there are specific cases in which {raw} would be better (?).

I typically avoid sending things like ^c and go for a more direct method, or I'll copy it to the clipboard ahead of time, then have the hotkey process it as I'd like.
OS: Windows 10 Pro | Editor: Notepad++
My Personal Function Library | Old Build - New Build
User avatar
Cerberus
Posts: 172
Joined: 12 Jan 2016, 15:46

Re: Random "bugs" in Autohotkey?

11 Feb 2018, 18:32

Nixcalo wrote:As a little update, Xtra solution does not work 100% of the time. I would say about 90%, which is way greater that the other solutions and it's definitely an improvement. Sometimes it does not work and what it does is delete what was selected, without replacing it with anything... but a great improvement nonetheless and with this success rate, script is a solution rather than a hindrance. THANK YOU! (Perhaps I have to add some "sleep" somewhere.."
You seem to have tried all suggestions in this thread. But, out of curiosity, did you also try Guest3456's suggestion here?:
https://autohotkey.com/boards/viewtopic ... 40#p199440
It's from an old thread, so I don't know, but just for completion's sake.

-----------------------------------------------------------------
To everyone: do you think adding BlockInput Send to Xtra's method could help? Or would that be a bad idea? Preferably combined with SendEvent(otherwise, use BlockInput, On, like so:

Code: Select all

^u::
    KeyWait, Ctrl
    KeyWait, u
    BlockInput, Send
    SendEvent, {Ctrl Down}x{Ctrl Up}
    BlockInput, Default
    ClipWait, 1
    if (ErrorLevel)
        return
    Clipboard := Format("{:U}", Clipboard)
    ClipWait, 1
    if (ErrorLevel)
        return
    BlockInput, Send
    SendEvent, {Ctrl Down}x{Ctrl Up}
    BlockInput, Default
return
BlockInput, Send: The user's keyboard and mouse input is ignored while a Send or SendRaw is in progress (the traditional SendEvent mode only). This prevents the user's keystrokes from disrupting the flow of simulated keystrokes. When the Send finishes, input is re-enabled (unless still blocked by a previous use of BlockInput On).
User avatar
Cerberus
Posts: 172
Joined: 12 Jan 2016, 15:46

Re: Random "bugs" in Autohotkey?

11 Feb 2018, 18:47

Masonjar13 wrote:Ugh, my browser closed and I lost everything I had written.. so I'll go with the concise version (sorry).

Blind basically does the exact opposite of what you think it does. When Send is used, modifiers, such as shift, are explicitly sent up to avoid altering what you've put there as text to send. So, Send abc will send shift up, if shift is held, prior to sending, to retain its proper case. Send {blind}abc will not release shift prior to sending, if it's physically held, meaning, if you're holding shift, the output will be ABC instead. {text}, I would say, is much better than the default though, because it sends the actual character codes rather than the key codes, making it significantly more reliable. That means that modifiers no longer influence the output at all, because character codes aren't based off the literal keyboard keys as key codes are. While I do believe you can send modified character codes independent of physical or logical modifier state (correct me if I'm wrong, lexicos), {text} does not do this and, instead, acts similarly to/as a better replacement for {raw}. At the fact you may use {blind} with {text}, {raw} appears deprecated, unless there are specific cases in which {raw} would be better (?).

I typically avoid sending things like ^c and go for a more direct method, or I'll copy it to the clipboard ahead of time, then have the hotkey process it as I'd like.
Ouch, poor you! Thank you for explaining this and the use of {Raw} and {Text}, and that the latter is unaffected by this entire issue of 'misbehaving' modifier keys. Then I am back at not understanding how {Blind} could help with hotkeys like ^d::^c (or ^c::^c, for that matter, which I also use). Or did you mean for {Blind} to be used only in the example you mentioned, like ^d::Send {blind}abc, where no modifier keys are used in the Send command? Now that I think about it, you probably did, in trying to solve the OP's issue.

As to not using ^c::, I wish I didn't have to! But I often need to, e.g. when I use a mouse gesture to copy selected text to the clipboard, or to search Google Images, etc. At least I wouldn't know of any way avoid sending ^c. The only solution I happened to find in another thread works in Firefox, where I have the most issues with unreliable hotkeys:

Code: Select all

$^c::
	IfWinActive, Mozilla Firefox
	{
		WinGet, hWnd, ID, A
		Clipboard := ""
		ControlGetFocus, vCtlClassNN, A
		SendMessage, 0x301,,, % vCtlClassNN, % "ahk_id " hWnd ;WM_COPY := }0x301
	} Else {
		Send ^c
	}
Return
lexikos
Posts: 9560
Joined: 30 Sep 2013, 04:07
Contact:

Re: Random "bugs" in Autohotkey?

12 Feb 2018, 03:28

Masonjar13 wrote:That means that modifiers no longer influence the output at all,
While it seems to be true that modifiers do not affect which characters are produced by the {Text} mode or {U+nnnn}, some programs will not produce any text at all if the logical modifier state is incorrect. For instance, I think Firefox ignores text while the Win key is pressed, which is why Send releases it by default even in {Text} mode. For instance, Win+[ on my system types "[" into Notepad but in Firefox it does nothing.
While I do believe you can send modified character codes independent of physical or logical modifier state
What's a "modified character code"? If it's independent of modifier state, I suppose it's not modified. 'A' and 'a', for instance, are just 65 and 97, and Shift state is irrelevant.
(correct me if I'm wrong, lexicos)
Since you insist ;) : it's lexikos, not lexicos.
lexikos
Posts: 9560
Joined: 30 Sep 2013, 04:07
Contact:

Re: Random "bugs" in Autohotkey?

12 Feb 2018, 03:52

Cerberus wrote:Then I am back at not understanding how {Blind} could help with hotkeys like ^d::^c
This may be beside the point, but ^d::^c is not a hotkey. It is a remapping, and as such already uses {Blind}.
Helgef
Posts: 4709
Joined: 17 Jul 2016, 01:02
Contact:

Re: Random "bugs" in Autohotkey?

12 Feb 2018, 06:02

some programs will not produce any text at all if the logical modifier state is incorrect.
Additionally, some programs' menu can be opened by something like !1::send "{blind}{text}f", for example in Notepad, but not in Opera (where nothing happens but !1::send "!f" would open it on some page only, adding "{blind}" seems to always open it :think:.).

Cheers.
User avatar
Cerberus
Posts: 172
Joined: 12 Jan 2016, 15:46

Re: Random "bugs" in Autohotkey?

12 Feb 2018, 13:21

lexikos wrote:
Cerberus wrote:Then I am back at not understanding how {Blind} could help with hotkeys like ^d::^c
This may be beside the point, but ^d::^c is not a hotkey. It is a remapping, and as such already uses {Blind}.
Ah, got it. So I should have said, ^d::Send ^c, right?
User avatar
Masonjar13
Posts: 1555
Joined: 20 Jul 2014, 10:16
Location: Не Россия
Contact:

Re: Random "bugs" in Autohotkey?

12 Feb 2018, 17:28

lexikos wrote:Since you insist ;) : it's lexikos, not lexicos.
You have no idea how many times I have to catch myself on that, and I have no idea why.

True, windows can always reject input for any reason really, but by the OS itself, seems to be perfectly fine.

lexikos wrote:What's a "modified character code"?
I explained that wrong, but this link explains what I mean. However, that "key" doesn't actually trigger a copy, so my point is bunk.

@Cerberus, WM_COPY should work for more than just Firefox.

Code: Select all

$^c::
WinGet, hWnd, ID, A
Clipboard := ""
ControlGetFocus, vCtlClassNN, A
SendMessage, 0x301,,, % vCtlClassNN, % "ahk_id " . hWnd ;WM_COPY := }0x301
clipwait,1
if(!errorlevel)
    Send ^c
Return
OS: Windows 10 Pro | Editor: Notepad++
My Personal Function Library | Old Build - New Build
User avatar
Exaskryz
Posts: 2882
Joined: 17 Oct 2015, 20:28

Re: Random "bugs" in Autohotkey?

13 Feb 2018, 05:06

Cerberus wrote:Then I am back at not understanding how {Blind} could help with hotkeys like ^d::^c (or ^c::^c, for that matter, which I also use).
I may have not followed the thread decently, only skimming ove rit. But wanted to try to clarify this point, at least how I understand it.

Doing ^d::Send ^c results in these actions for the computer:

Human has pressed Ctrl
Human has pressed d
AHK recognizes this is a hotkey -- "Ah! It's a hotkey!"
AHK anticipates the Send command, {Blind} is not there
*AHK releases the Ctrl key
*AHK presses the Ctrl key
AHK presses the c key
Active program recognizes that as the copy shortcut and performs the supported action
AHK releases the c key
AHK releases the Ctrl key
Human may release Ctrl or d at their leisure

What I marked with asterisks is where I suspect the problem arises. Sometimes the computer sees that Ctrl was released, but does not see that Ctrl was pressed again practically immediately after.

I might be wrong about this and would be happy to be corrected, or told that this was already discussed, but does Send CAPITALS result in a key sequence like?

Code: Select all

Send {Shift down}
Send c
Send {Shift up}
Send {Shift down}
Send a
Send {Shift up}
Send {Shift down}
Send p
Send {Shift up}
..
If so, that can explain why at times the capital letters are not coming through for OP.

Well, I Tested it. The answer is yes and no. No, as keyhistory indicates that Send CAPITALS results in a single {Shift down} followed by c, a, p, ... l, s and then a {Shift up}. However! Yes in that if there are letters in between that shouldn't be capitalized, Shift is released. That makes sense. But note that the space character is considered uncapitalized. If I instead ask for Send CAP I TALS, Shift is released after the p, space is pressed, then Shift is pressed down again for the i, i is sent, Shift is released, space is pressed, then Shift is pressed, and t, a, l, s are sent, then Shift is released.

So with the rapid sequence of {Shift up}space{Shift down}, sometimes the Shift down is ignored or is processed late by the system, even after other letter keys have been processed.

Return to “Ask for Help (v1)”

Who is online

Users browsing this forum: Google [Bot], imustbeamoron, roysubs and 186 guests