I just want my script to select the right Window to input key storkes. To do this I think I use WinActivate. I ran the example from their site but found some strange results in Windows 10
IfWinExist, Untitled - Notepad
WinActivate ; use the window found above
else
WinActivate, Calculator;
If Notepad is minimized, it gets the focus
If Notepad is open but is not have the focus (i.e. another window is on top of it), Notepad gets the focus
If Notepad is not open and the calculator is minimized, for some strange reason it doesn't get the focus.
If Notepad is not open and the calculator is open but not have the focus, it gets the focus.
What is causing the inconsistency?
It happens because of the implementation of the WinActivate function on the language. WinActivate tries to open an window, but it might not be able to.
From the documentation
Six attempts will be made to activate the target window over the
course of 60ms. Thus, it is usually unnecessary to follow WinActivate
with WinWaitActive or IfWinNotActive.
Usually you can try the #WinActivateForce directive in combination with WinWaitActive or IfWinNotActive.
Sometimes you can use an ahk_exe parameter to match the window. It may work in cases where the window title doesn't. In this case you would use
Also it's useful to try restoring the window with WinRestore.
SetTitleMatchMode, 2
IfWinExist, Bloco de notas
{
WinActivate ; use the window found above
}
else
{
WinRestore, ahk_exe calc.exe
WinActivate, ahk_exe calc.exe
}
I'm on Win7, but the above worked for me.
Here is an example of a good and complete implementation of a function that tries to activate a window.
Semicolons introduce comments in AHK. There has to be a white space before it, otherwise it's seen as part of the string (alias winactivate "Calculator;")
so, use
WinActivate, Calculator ;
or just omit the ;, for it doesn't contribute anything
Related
I create two windows through autohotkey and move them to my leftmost and rightmost monitor respectively (I have 3 monitors).
When I minimize them, and call them again, they are being shown on the central monitor. But I want them to be shown where they were before.
See following gif.
Following is the ahk script:
Run, Notepad
WinWait, ahk_class Notepad
WinSetTitle, asd
Run, Notepad
Sleep, 1000
WinGet, fensterID, List, ahk_class Notepad
Loop, %fensterID% { ; will run loop for number of windows in array
WinActivateBottom, % "ahk_id " fensterID%A_Index%
WinGetTitle, title, A
MsgBox, %title%
if (title == "asd")
WinMove A,, 1500, 0
else
WinMove A,, -2304, 0
WinMaximize, A
}
Meanwhile I switched to AutoIt and - having the same problem there - I found out, thanks also to this, that it works if I disable the maximized option for Windows Terminal (the actual program I was trying out with), then move and maximize the window. It should do the same with AutoHotKey.
I created a single-window menu scheme using ncurses and got it working.
When I added a second window, I can no longer get my wgetch call to fire (or so it seems).
Somewhat confusing to me is the function prototype :
int wgetch(WINDOW *win);
which says wgetch somehow depends on the window but I don't get the relationship - how does "the window" matter? If it does, and I have more than one window, which one do I use? Also, https://linux.die.net/man/3/wgetch says "There is just one input queue for all windows." which tells me "the window" is a "don't care".
Can someone explain?
Thanks.
The window matters because wgetch refreshes the window before reading characters. That's in the wgetch manual page:
If the window is not a pad, and it has been moved or modified since the
last call to wrefresh, wrefresh will be called before another character
is read.
Each window (including stdscr) may have been altered since the last call to wrefresh. If you make changes in one window without refreshing it, and then call wgetch in another window, the changes to the first window are not automatically displayed. You can use wnoutrefresh to combine refreshes, e.g., using that for the first window and then use the wrefresh done automatically for the second window to refresh both.
I am using Zenity 3.10.2 and any time I use Zenity, regardless of dialog type, the dialog it brings up has focus. i.e. I can straight away press "Enter" straight away and proceed. (I need this ability for automation)
However, there is one exception and it is very difficult to test. It occurs during the KIWI installation of a custom Linux distro and involved a question dialog being created with no focus. Neither enter nor tab have any effect.
There is a bash script which creates this dialog. When I run this in all other contexts, It has focus, but in this install it does not, the cursor appears in random places all around the place. However, from what I can see, the whole point of Zenity is on-top, already focused dialogs.
The actual call to create the dialog is the result of sourcing a file that has the bash script in it i.e. ". ~/.bashrc". Even this approach, always works when I test it manually.
Any ideas as to what could cause a Zenity dialog to be created without focus? Or any way using just Zenity to reclaim / change the focus?
I am aware you can use a window manager such as wmctrl to bring the Dialog to the focus. However this currently not a used package and shouldn't have to do anything else as this is just a simple dialog.
WINDOWMANAGER=/usr/bin/gnome-session
Any guidance would be much appreciated!
I want to use AutoHotkey to run a program and send some keystrokes.
But I don't get it to work. The program pops up, and then nothing happens.
Here is what I have so far:
run, c:\windows\sysnative\gfxv4_0.exe
WinActivate, "Intel(R) Graphics Control Panel"
SendInput {Tab}{Tab}{Tab}{Tab}{Tab}{Tab}{Tab}{Tab}{Tab}{Enter}
Just for testing, I have also tried to send some keys to notepad, but that doesn't work either. The notepad window pops up, but then nothing:
run notepad.exe
WinActivate "Unbenannt - Editor"
SendInput abc{Tab}{Tab}xyz
I have also tried WinActivate without parameters, but no results either. Have also tried with Send, SendPlay, SendEvent and SendRaw. No change.
System is Windows 8.1 64 Bit, latest Service Packs.
Core i7, 8 GB, 2 screens.
Remove the quotes
The parameters of AHK commands are literal strings unless specified otherwise in the help for a command or you explicitly make the parameter an expression: WinActivate, % "some string"
Wait for the window to appear before activating it because launching an application takes time:
WinWait Intel(R) Graphics Control Panel
Maybe there's ® instead of (R). Use the exact window title text from Window Spy application that comes with AutoHotkey.
I find myself opening files inside the wrong window in Vim — sometimes the NERDTree or MiniBuffExplorer — and it’s really throwing me off.
I’m sure it’s happening because my cursor is mistakenly focused inside one of these windows, but is there anything I can add to my .vimrc file to prevent this from happening?
I finally found the solution to this annoyance in the MiniBufExplorer source comments. It looks like this feature has been available since version 6.2.8 (release 2004-06-07):
If you use other explorers like TagList you can (As of 6.2.8) put:
let g:miniBufExplModSelTarget = 1
into your .vimrc in order to force MBE to try to place selected
buffers into a window that does not have a nonmodifiable buffer.
The upshot of this should be that if you go into MBE and select
a buffer, the buffer should not show up in a window that is
hosting an explorer.
It's possibly related to the setting of mousefocus. From :help mousefocus
The window that the mouse pointer is
on is automatically activated. When
changing the window layout or window
focus in another way, the mouse
pointer is moved to the window with
keyboard focus. Off is the default
because it makes using the pull down
menus a little goofy, as a pointer
transit may activate a window
unintentionally.