Send TAB in authotkey after every (letter)keypress regardless of language setting - autohotkey

I'm trying to make filling some web-forms easier. Each form might include 100 times that tab would have to be pressed after typing a letter to be able to input the next letter to it's corresponding slot. I tried some examples, but ran in to problems when changing Windows language settings to Russian. Most of the time I will be inputting Russian letters, and if not, then just normal latin letters.
I tried following basic examples which worked for either one letter at a time or all (latin) letters at once.
#UseHook On
w::send ш{Tab}
Which outputs
ш(and one single TAB taking me to the next input)
So for some reason the characters are not correctly output from AHK.
This other example I found here and it works fine for any latin letter after a small modification:
https://autohotkey.com/board/topic/67948-detect-any-letter-key-press/
Loop 26
Hotkey, % Chr(A_Index+96),LatinLabel ;loop creating hotkeys for a-z
Return
LatinLabel:
Func(A_ThisHotkey)
Return
Func(var) {
#UseHook On
Send %var%{TAB}
}
I read that listening for all keypresses or actions would not be ideal, since this would also record mouse clicks and even movement.
So are there other alternatives googling didn't reveal to me?

Are you having problems with sending Unicode characters?
For the euro symbol I use either of:
SendInput {U+20AC}
PostMessage, 0x102, 8364, 1, Edit1, A ;WM_CHAR

The problem of ш becoming ш is due to the script file having been saved as UTF-8 without BOM. You just need to save the file as UTF-8 with BOM. AutoHotkey (as of v1.1.30.03) interprets files without a BOM as ANSI, because the default editor is Notepad, and Notepad (prior to Windows version 1903) defaults to ANSI.
The second script registers hotkeys a-z via the expression Chr(A_Index+96), which produces latin letters. Once registered, these hotkeys will activate when you press the corresponding virtual keys even if you change the keyboard layout. However, they will still send latin letters, because A_ThisHotkey is a-z.
The solution is to use the ~ hotkey modifier instead of sending the hotkey. In that case, pressing the key has whatever effect it should normally have, then the script sends Tab.
Loop 26
Hotkey % "~" Format("vk{:02x}", A_Index+64), AzKey
return
AzKey:
Send {Tab}
return
This registers hotkeys for the virtual keys vk41 - vk5A, which correspond to A - Z on layouts which contain those characters, but also work with other layouts. However, there may be some other keys which produce "letters" or other characters you want to watch for; in that case, just register additional hotkeys as needed.
Hotkey ~vkC0, AzKey
or stack the labels
vkC0::
AzKey:

Related

How do I force Windows to ignore an AutoHotKey and instead pass that hotkey directly to the active window?

My cPanel has a text editor that allows multi-cursor functionality using Ctrl-Alt-Up, Ctrl-Alt-Down, Ctrl-Alt-Right, and Ctrl-Alt-Left. Unfortunately, Windows has default hotkeys for these key combinations that rotate the display on your screen. When I try to use these key combinations in the text editor, Windows hijacks them before they can get to the active window.
I first searched to see if there's any reasonably easy way to turn off specific Windows default hotkeys. My search only turned up results that turn off all hotkeys. I then decided to download AutoHotKeys and see if I could write a script to achieve what I was looking to do. Below are some examples; I'll stick with Ctrl-Alt-Right just to select one out of the four:
First block of code is the same in all 4 attempts:
#NoEnv
SendMode Input
SetWorkingDir %A_ScriptDir%
SetTitleMatchMode, 2 ;this and the next line should only perform the scripted
#IfWinActive Opera ;hotkey if the active window's title contains 'Opera'
Attempt 1: Hotkey correctly bypasses Windows default display-rotating action, and sends the keystrokes to the text editor in Opera. However, the text editor enters the string "ight" wherever the cursor is. There is no Ctrl-Alt-R hotkey in the text editor, and it must not be a Windows default hotkey either. So it sends Ctrl-Alt-R to Opera, which does nothing. Then it sends "ight" which is typed out. (This is the "most successful" of the 4 attempts, but definitely does not achieve the desired outcome):
^!Right::
Send, ^!Right
return
Attempt 2: Only differs from #1 with SendPlay instead of Send. The Hotkey again correctly bypasses Windows default display-rotating action. However, the text editor does not appear to do anything at all:
^!Right::
SendPlay, ^!Right
return
Attempt 3: Back to just Send, but now with curly braces around the second "Right". Now the hotkey doesn't even bypass Windows default display-rotating action (this truly boggles my mind because I would have thought that the result of Attempt #1 proves that the active Opera window was found and the keystroke Ctrl-Alt-Right is correctly being read by the ^!Right in the first line. I'm so confused why adding the curly braces in the 2nd line is negating these things that seem as if they should already have occurred):
^!Right::
Send, ^!{Right}
return
Attempt 4: Only differs from #3 with SendPlay instead of Send. The Hotkey again correctly bypasses Windows default display-rotating action. However, the text editor does not appear to do anything at all:
^!Right::
SendPlay, ^!{Right}
return
To summarize:
----------| Curly Braces | No Curly Braces |
----------|------------------|-----------------------------|
Send | Win Dflt Action | types "ight" in text editor |
SendPlay | no action | no action |
So here's the final question, based on this table, it would appear to me that Send is definitely the way to go. If (as Attempt 3 appears to indicate) the curly brace is causing the display-rotation, how do I send this keystroke to the active window without Windows hijacking it? Obviously, #IfWinActive Opera is working correctly when the curly braces aren't used. Perhaps there is another directive that prevents or bypasses Windows' default action entirely?
If you don't wish to have the screen rotation functionality, this can be disabled in your graphics panel. I believe it's associated with Intel graphics application. It might be something like, right-click the desktop, select graphics options, choose hotkeys, then click disable. This is just guessing as I don't have that on the computer I'm using, but I've encountered it on others' computers before.
As for your hotkeys, you need the curly braces around the word "right" or it will just send the individual characters, just like actually typing it. Another issue is that you need a $ in front of your hotkey since it is self-referencing; that is, it's sending the same keystrokes that activate it.
If you haven't had a chance to check out the help file, I definitely recommend it.
https://www.autohotkey.com/docs/Hotkeys.htm#Symbols

How to switch current IME using PowerShell?

I have created a script to add/remove (toggle) a specific IME. Now, after that IME is added, I want to switch to it, just as if I clicked the language name at the bottom right of the screen, and then clicked that IME on the pop-up list.
I have searched Google for this, but I could not find a suitable command. The top result was Set-WinDefaultInputMethodOverride, but I was not talking about changing the default IME or the precedence; I just want to automate the manual changing as described in the previous paragraph. Is that NOT possible with PowerShell?
You can shift the IME on or off with ALT + SHIFT in Windows and cycle through the languages. The easiest way to do this is with SendKeys.
Add-Type -AssemblyName System.Windows.Forms
[System.Windows.Forms.SendKeys]::SendWait('%+')
This will load the correct assembly and send the ALT+Shift keystroke. A list of special characters for SendKeys can be found here. On my system this changes the language from English to Japanese, a second [System.Windows.Forms.SendKeys]::SendWait('%+') will then cycle to Scottish Gaelic. Sending a third keystroke cycles back to English.
If the language has multiple inputs like Japanese Hiragana, half width Katakana, full width Katakana, etc... you can use ALT+~ to cycle those as well. Tilde must be escaped. [System.Windows.Forms.SendKeys]::SendWait('%{~}')
Note that the application you are attempting to enter text into has to support this though. For example Powershell itself will let me switch to Japanese but will not let me switch to Hiragana, only the standard ascii chars.
I'm not sure what your ultimate goal is but this is one way to shift through your installed languages via hotkeys.

Why do hotstrings act unexpectedly?

I have to test cases:
Case 1
#Include test1.ahk
::se::Stack Exchange `{backspace}
(test1.ahk is empty) then typing:
se␣ (with a space at the end) → Stack Exchange (no space at the end)
use␣ → uStack Exchange
But let say I delete the ␣{backspace} at the end or change it to
::se::Stack Exchange `{backspace}
::de::define
then it works normally again.
Case 2
#Include test1.ahk
::se::Stack Exchange
works fine, but
#IfWinActive, ahk_class SunAwtFrame
return
::se::Stack Exchange
makes se→se, i.e. nothing happens.
This is very weird, because there's nothing seems to be wrong. I can't even quarantine it, and updating AHK to the latest version or reinstalling it doesn't help. All I know is that when it happens any hotstring will behave this way. The problem started when I included this script, but even when I've exclude it this still happens. The script itself doesn't seem anything wrong too.
Also ask on Reddit.
Preventing expansion of se to trigger when you type use, is one of the reasons why I end my text expansion strings with a special character. As I maintain text expansion for three languages, I have settled on the following scheme.
text\ is the default (Dutch)
text= is used for English
text] is used for German
I also use the . in some cases to expand abbreviations.
I chose the \, = and ] signs, because they are all close to the Enter key.
Example:
Dutch:
:*:adhv\::aan de hand van
:*:bv\::bijvoorbeeld
English:
:*:am=::Account Management
:*:actm=::Active Monitoring
:*:appr=::approach
:*:art=::article
:*:ba=::business alignment
German:
:*:nrw]::Nordrhein-Westfalen
:*:ma]::Mitarbeiter
:*:fk]::Führungskräfte
Dots:
:*:adhv.::a.d.h.v.
:*:dmv.::d.m.v.
:*:ovv.::o.v.v.
As you can see, I can write adhv either with a . at the end or with a \ and they expand differently.
The * is used to overwrite the default ending characters like {Space}.

How to delete characters as they are typed into MATLAB command line

I am using my keyboard to run an application in MATLAB, where each keypress is handled differently depending on the number or letter pressed. To recognize keypresses I'm using the HebiRobotics library discussed here:
Detect Keyboard Input Matlab
While running the program, hundreds of keypresses are required, each of which types a character in the command line, after the >>. Is there any way to delete these characters as they are typed so the command line remains clear? I've tried fprintf('%c',8) to backspace, but this applies to the previous executed command, not the characters on the current line.
To be honest, this isn't terribly important, but having the characters appear is ugly, takes a few extra clicks to delete, and is one of those little things that is driving me crazy.
This answer by 'Oleg Komarov' seems to be relevant -Clearing text typed with input() from command history

SendInput %userInput% causes my computer to malfunction oddly

SendInput %userInput% causes my computer to do very weird stuff. Sometimes it logs off, sometimes my arrows of the keyboard get disabled, sometimes it runs cmd in windows an infinite times...
UPDATE:
this is the thing that gets inputed in the command line and runs:
runas /user:administrator cmd
UPDATE:
I think I almost got the problem, as such I edited the question to leave out what I deem to be irrelevant now.
When SendInput is happening, and the user is still inputting data in the keyboard, such as pressing the win-key, then this can cause the system to log off because win-key + l is a shortcut for that. Likewise must be for all the other things that are happening. Another observation is that SendInput skips certain characters, like {enter} etc. It only processes them at the end, when all the regular characters are put into place. I notice that at the end, SendInput is still busy doing stuff, perhaps some exotic characters it delayed till the end. Because the user think the output is complete, he ends up pressing the shortcut key again which in combination with the current sendInput is causing the system to crash.
UPDATE:
It also goes bezerk if there is a "!" to be send with SendInput.
This is one string I pasted to the copyboard:
dsjkfhjdsfsjdh!!!!!!!!!!!####################$$$$$$$$$$$%%%%%%%%%^^^^^^^^^^^^^&&&&&&&&&&&&&*****(((((((((())))))))))))____++++++++++++++++=======------------000000000000000099999988888.
But the output is WITHOUT the exclamation marks. Like this:
dsjkfhjdsfsjdh#######$$$$$$$$$$%%%%%%%%%&&&&&&&&&&&&*****(((((((((())))))))))))____+======------------000000000000000099999988888.
Why is that? Are there any other characters? Exclamation marks are important I feel, and I don't want to remove them. Are there any workarounds?
UPDATE:
It is more complicated than that. When I copy paste the above characters WITHOUT the exclamation marks, it still does weird stuff.
Here is some of the code that eventually userInput combines and sends away with SendInput:
StringReplace, contents, save_selection, ``, ````, All ; Do this replacement first to avoid interfering with the others below.
StringReplace, contents, contents, `r`n, %A_SPACE%, All ; Using `r works better than `n in MS Word, etc.
StringReplace, contents, contents, `;, ```;, All
;* loc_title origanally contains browser specification. Remove it.
StringGetPos, pos_delim, loc_title, - , R
length := StrLen(loc_title)
count := length - pos_delim
StringTrimRight, loc_title, loc_title, count
You could use sendraw instead of sendinput.
Here is what the docs say:
Raw mode: The SendRaw command interprets all characters literally
rather than translating {Enter} to an ENTER keystroke, ^c to
Control-C, etc. However, the normal rules for escape sequences,
variable references and expressions still apply since these are
processed before the command executes. To use raw mode with SendInput,
SendPlay, or SendEvent, write {Raw} as the first item in the string;
for example: SendInput {Raw}abc.
Then you don't have to worry about the ! or other control modifiers.
The reason that the exclamation mark character is an issue is because SendInput treats it as a code to press the Alt key.
There are several similar codes:
^ = Ctrl
+ = Shift
# = Windows key
You can find the others listed in the documentation for SendInput.
It seems like you want to send the raw text and not have SendInput look for these codes. You should be able to put {Raw} at the beginning of the userinput variable and it will ignore any codes in the rest of the characters.
If it is typing too slowly, you could put SetKeyDelay,-1 in your script to remove the key sending delay.
A good workaround that I found was to avoid SendInput altogether. Rather use the clipboard to copy the string inside, to then paste it on your screen. It works flawlessly, and is a billion times faster. Why would a person utilize SendInput in the first place? However, the actual question still is standing, why does SendInput behave so strangely? What is inside that string: %userInput% that causes my system to crash? How can I find out?