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
![Smile :)](./images/smilies/icon_e_smile.gif)
he is also using KeyWait to make sure that Ctrl is fully released before doing the SendNixcalo 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
likely one of the ClipWait's are failing and just returningNixcalo wrote: Sometimes it does not work and what it does is delete what was selected, without replacing it with anything...
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
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.I am quite certain that Visual Basic, C++ or Delphi manage these quite well.
Which other language does this perfectly, and has seen heavy use for this purpose?(sending a Control X and then sending a Control V, not rocket science, and something other languages do perfectly)
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.Masonjar13 wrote:While that is correct, I just want to note that some applications do not allow native pasting
OK I'm not entirely sure I understand. Is it as follows:Masonjar13 wrote: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.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?
Code: Select all
^d::Send ^c
By "the program", do they mean "the trigger" as above (and not the Autohotkey Send command itself)?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.
You seem to have tried all suggestions in this thread. But, out of curiosity, did you also try Guest3456's suggestion here?: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.."
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).
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.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.
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
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.Masonjar13 wrote:That means that modifiers no longer influence the output at all,
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.While I do believe you can send modified character codes independent of physical or logical modifier state
Since you insist(correct me if I'm wrong, lexicos)
This may be beside the point, but ^d::^c is not a hotkey. It is a remapping, and as such already uses {Blind}.Cerberus wrote:Then I am back at not understanding how {Blind} could help with hotkeys like ^d::^c
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 itsome programs will not produce any text at all if the logical modifier state is incorrect.
Ah, got it. So I should have said, ^d::Send ^c, right?lexikos wrote:This may be beside the point, but ^d::^c is not a hotkey. It is a remapping, and as such already uses {Blind}.Cerberus wrote:Then I am back at not understanding how {Blind} could help with hotkeys like ^d::^c
You have no idea how many times I have to catch myself on that, and I have no idea why.lexikos wrote:Since you insist: it's lexikos, not lexicos.
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.lexikos wrote:What's a "modified character code"?
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
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.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).
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}
..
Users browsing this forum: Google [Bot] and 316 guests