ControlSend,, test, ahk_exe notepad.exe
The above works just fine but the following does not, it should englarge the text in notepad.
ControlSend,, ^{+}, ahk_exe notepad.exe
I have also, tried
ControlSend,, {Control down}+{Control up}, ahk_exe notepad.exe
I dont really care for notepad, I am just stuck with controlsend and I am trying understand it. Often it will lose focus to the target window after triggering the hotkey. Is there a special rule in Controlsend, that gets it to keep focus where it is, after triggering the command? For example sending the following to notepad, will activate it. I thought the whole point was to maintain focus where it is.
ControlSend,, ^s, ahk_exe notepad.exe
In the last example, A window is being created so it may be a bad example but many times this issues occurs when sending simple, standard hotkeys to programs
Thanks!
Using Notepad's Alt menu to trigger the zoom in command instead of trying to send a Control Plus lead me to this solution:
WinMenuSelectItem, ahk_exe notepad.exe, , View, Zoom, Zoom In
Many of the commands that you use shortcuts for (such as Zoom, save, and etc) can be triggered from this menu as well. This method also meets the requirement of not activating the Window when triggered.
Related
Hi i want to make a batfile that looks something like.
hide mouse
run /wait some.exe
show mouse
the issue i have is i am making a arcade cabinet. and i have a few games that do not hide the mouse pointer and it just sits dead center on the screen.
This isn't usually an issue as you can just move the mouse and hide it, but as its an arcade cabinet there is no mouse..
I have tried and app that hides the mouse pointer after a few seconds. but that causes other issues "it will often minimize the game when it hides the mouse" I could probably use AHK to force the window IF it happened. but that seems like a lot more work than just having a bat file for the few games that i wish to hide the mouse on..
this is the windows mouse pointer.. not an in game specific mouse.
given stephans's message i decided to use a seriese of batch files to kill the mouse hider app when the aplications it minimized start and then retart the app when those tasks end..
I was hoping for a more elegant solution but it seems to be the only way i can do this.
given it is now mostly AHK scripts being used to call bat files im not sure if i need to delete the question.
the process is possible to do in batch but for my needs it was better to run the bat from a ahk script as this kept it as elegant as possible.
for any one else..
the AHK reads.
run %rompath%pin.bat
Runwait, %rompath%%romname%%romextension%
ExitApp
;Required
CloseProcess:
WinKill, A
run %rompath%pinst.bat
return
pin.bat reads:
taskkill /f /im "AutoHideMouseCursor.exe"
and pinst.bat reads:
start "path to exe\AutoHideMouseCursor.exe"
The app i used to hide the mouse is AutoHideMouseCursor
if this question is best served to be deleted let me know.
I run a batch file as part of Windows XP startup which executes continuously until Windows closes. It calls a VBScript file, which executes SendKeys "+{ESC}" (Shift+Esc). This gets picked up by 4t Tray Minimiser to send the CMD window to the system tray. Most times it works, but occasionally the CMD window stays visible.
Upon searching, various posts seem to suggest the .VBS file is losing focus or it's a timing problem. Some suggest AppActivate but I can't work out how to achieve what I want. Even the examples given for AppActivate seem like a lot of work.
Did you check the documentation? It's actually rather straightforward. You call AppActivate with the title (or part of the title) of the window you want to bring to the foreground, then run SendKeys to send keystrokes to the foreground window.
Set sh = CreateObject("WScript.Shell")
sh.AppActivate "window title"
sh.SendKeys "+{Esc}"
I want to disable / block the mouse click and keyboard typing for 6 seconds after launching a .exe file while displaying a advsplash.
Currently I manage to run a .exe file, activate the splash, block the keyboard and run a second .exe, but then, I need to restart the computer to unlock the mouse/keyboard.
Any idea on how to disable it without restarting the machine ?
This sounds like something you should never do.
If you want to do UI automation Windows already has support for that, using SendInput or keybd_event is not a good idea. Some apps steal foreground focus, this is just a fact and if that happens at the wrong time you end up sending input to the wrong window.
I wrote some Apple script to take advantage of the extra buttons of my mouse (say invoke 'Back' from my web browser) and it runs fine inside AppleScript editor. Now I'd like to bind it to my mouse's 'Button 4'. Saving the script as 'script' or 'bundle' would only cause the button-click to open the editor instead of executing it. Saving it as 'Application' will do the work but it involves opening the application, doing its job, and exiting the application, so each time there's a flash. Any way to get rid of this flash? One way is to run the script in the background but I don't know how.
I use Butler for this kind of thing. You can assign a keystroke to your mouse button, then tell Butler to run your script on that keystroke.
I can't help but wonder if there's not built in support for that already with your mouse's software, though. I can't remember the last mouse I had that the 'Back' option wasn't built-in.
My suggestion would be to use a program that can run a script with keyboard shortcuts. Here's a free one. Then instead of running the script from a mouse button, you just assign the mouse button to perform the keyboard shortcut.
By now everyone writing for Windows probably knows that applications cannot (officially) steal focus from foreground processes, and why. But I have just managed to steal focus, inadvertently, and don't understand how this is even possible.
I have a Delphi app that user brings up with a hotkey (or by a mouse click, or by Alt+Tab), selects a piece of text and hits Enter. My app then minimizes (hides to the tray, even), and pastes the text user just selected into the active window. Nothing new here, plenty of similar projects out there - clipboard extenders, glossaries, macro programs, etc.
What is puzzling to me is that after doing all the above and then sleeping for 1500 ms, I restore my main form and it gets the focus back! It becomes the foreground window, even though it wasn't 1500 ms ago (tested; Windows 7 32-bit.).
In fact, I don't want this at all, so before restoring my main form I record which window has foreground and I give it back to that window after it's been given to me. I'm just curious why my app gets to be in the foreground when by rules it should not. Maybe I don't understand the rules as fully as I thought I did?
If you look at the documentation for SetForegroundWindow you see a list of conditions for the call to succeed, one of them is "The process received the last input event." So if the user does not do anything after pressing enter in your app you still have the right to steal focus. I don't know if Delphi calls SetForegroundWindow for you when the window is restored but it might be something to look into.
I don't know how you restore your window but using SW_SHOWNOACTIVATE with ShowWindow might help...