I trying the translate an equivalent of this Arduino digispark code into AutoHotKey code.
DigiKeyboard.sendKeyStroke(KEY_Q, MOD_CONTROL_LEFT | MOD_SHIFT_LEFT);
This code simply emulated a keyboard and types "CTRL+SHIFT+Q".
I also need a simple AHK code snippet that can detect CTRL+SHIFT+Q" being typed on the main keyboard.
Thanks in advance for pointing me in the right direction.
This will display a message box when ctrl+shift+Q is pressed.
^+q::
MsgBox , ctrl+shift+Q detected
Return
If you need it to also fire its native function, place a tilde ~ in front of the hotkey, like this ~^+q::.
Here's some good info from the help file, Hotkeys.
Related
I dont know how to make this working or I am missing something - maybe in #include ?
at this point I have:
#RequireAdmin
#include <MsgBoxConstants.au3>
#include <FileConstants.au3>
;vcdredist
Run($sDrivers & "\vcredist_x86.exe")
WinWaitActive("vcredist_x86")
;ControlClick("Microsoft Visual C++ 2010 x86 Redistributable Maintenance", "","[CLASS:Button; INSTANCE:3]")
ControlClick("Microsoft Visual C++ 2010 x86 Redistributable Maintenance", "","[ID:105]")
I've checked with AutoIt v3 WIndow Control and arguments inside ControlClick are correct
none of last two lines make AutoIt select desired option.
Any help very much appreciated.
WinWaitActive()
Probably Isn't the thing you're looking for, as it waits for the window to be active for the code to be ran. WinActivate() activates the window.
If you want the code to run when you activate the window, then WinWaitActive() will do.
Also you can avoid having the title in the ControlClick by doing this.
$hWnd = WinWait("vcredist_x86")
WinWaitActive("vcredist_x86")
ControlClick($hWnd, "", "[CLASS FROM AUTOITINFO]", "Left", 1)
Use the Autoit Window Info tool to find the classes if you aren't using it already.
(https://www.autoitscript.com/autoit3/docs/intro/au3spy.htm)
If ControlClick still doesn't work, then you can try using
MouseClick("Left", x, y)
X, Y are the coordinates.
Probably the script is waiting to the window become active WinWaitActive().
In this case you can use a WinActivate before the WinWaitActive to avoid this problem.
If you want a more robust solution you can use this:
While Not WinActive($win)
WinActivate($win)
Sleep(500)
WEnd
I wrote a UDF in AutoIt to wait for controls. posted around here a few times. just feed it the stuff you want and how long, if applicable you want to wait. you can wait forever by default.
However, there is an easier solution, install it in quiet mode. run a command
Run($sDrivers & '\vcredist_x86.exe /q')
now you don't have to poke any buttons. also, it's better not to use ID because if you are testing an application that is changing, the developers can change all that. I use button text as additional search criteria instead. much more reliable and less maintenance on my code.
Have gone through the similar situation for one application while trying to automate that, after trying all the debugging just added the below command and it worked like charm
#RequireAdmin
I try to download file using Autoit from Firefox 28.0.
I try to download a exe file,popup flashed but autoit window info tool cannot recognize the save button.
how can i automate this.
My scripts looks like
Local $hWnd=WinActivate("[CLASS:MozillaDialogClass]")
WinWaitActive($hWnd)
;MsgBox(1,$hWnd,$hWnd)
;ControlClick($hWnd,"","Save")
ControlClick($hWnd,"&Save File","")
;WinClose("[CLASS:MozillaDialogClass]")
how can i automate this......
Right now both of your ControlClick attempts are incorrect. The correct syntax is ControlClick(Window title or handle, *window* text, control *id*, ...). Look at the helpfile and examples for it to see what you're not doing right currently.
The firefox download dialog is a little tricky, googling gives a lot of results for people who have tried to do the same thing and struggled.
The easiest method is to click the window at the coordinates of the button. ControlClick can be used for this (simply leave the control id blank). The AutoIt window info tool should give ControlClick coords when you try and select where the button is.
That method does assume that the button is always in the same place, which is not necessarily the case. Alternatives are to use ControlSend to send the Alt+S combination (or whatever it is for that button).
And finally, it's worth mentioning the IUIAutomation framework which has shown to be very reliable for automating windows that aren't using standard winapi controls.
The simplest way to do is as follows on mozilla:
Use the following code on autoit.au3 file
ControlFocus ( "MozillaDialogClass", "", "" )
Sleep(10)
Send("{ENTER}")
Execute the same file in selenium using:
Runtime.getRuntime().exec("C:\\Users\\Balaji\\Desktop\\autoit.exe");
Use the below code to download a file in Firefox using AutoIt.
WinWait("[TITLE:Opening ; CLASS:MozillaDialogClass]","", 10)
If WinExists("[TITLE:Opening ; CLASS:MozillaDialogClass]") Then
; Perform keyboard ALT key + s key to select Save File Radio button using keyboard shortcut.
ControlFocus ( "[TITLE:Opening ; CLASS:MozillaDialogClass]","", "" )
Send("!s")
; Wait for 2 seconds
Sleep(2000)
; Press Keyboard ENTER button.
Send("{ENTER}")
EndIf
I am trying to understand this bug and I am looking for a workaroud.
Using this script:
#NoEnv
#SingleInstance force
SendMode Input
;Alt+t to send keystrokes
!t::Send, /[]
It send the correct keystrokes /[] to all windows but the windows console (cmd)
Additional Info:
Using autohotkey v1.1.09.02
With an english US keyboard layout, it sends: '90
With a french canadian multilingual keyboard layout, it sends: é^ç
Any idea of what can fix it?
Try this:
#NoEnv
#SingleInstance force
;SendMode Input
;Alt+t to send keystrokes
!t::Send, % chr(047) chr(091) chr(093)
Return
And let me know if it solves your issues.
Found this:
I use multiple languages or keyboard layouts on my system. Why do Send and Hotstrings sometimes send the wrong characters?
This can happen whenever the script's language or keyboard layout does not match that of the active window. To fix it, open the script's main window via its tray icon. While the main window is active, use the language bar (or a language hotkey such as LeftAlt+Shift) to change the script's language/layout to match that of the window you are currently typing in. Switching the script's language can be automated with the following example hotkey:
#l:: ; Win+L hotkey.
ListLines ; Show the script's main window.
WinWaitActive ahk_class AutoHotkey
Send {LAlt down}{Shift}{LAlt up} ; Switch to alternate language (keys must be in this format).
WinMinimize ; Minimize the window found by WinWaitActive above.
return
More info: Like all applications, each script starts off using your default language. If the default does not match that of the active window (where the keystrokes are sent), the difference in keyboard layouts might cause keystrokes sent by the script to be translated into something unexpected.
On: http://autohotkey.free.fr/docs/FAQ.htm#load
I wish to simulate a right click on a file. This is done by opening a Windows Explorer window and then right clicking on it.
The main issue is finding the location of the file in Windows Explorer. I am currently using Autoit v3.3.8.1.
My code 's first line:
RunWait (EXPLORER.EXE /n,/e,/select,<filepath>)
The next step is the problem. Finding the coordinates of the file.
After that, right clicking at that coordinates (it seems to me at this time) is not a problem....
Some background:
OS: Windows 7 64-bit
Software Languages: C#, Autoit (for scripting)
The Autoit script is called by a code similar to that below:
Process p = new Process();
p.StartInfo.FileName = "AutoItScript.exe";
p.StartInfo.UseShellExecute = false;
p.Start();
The code is compiled into a console class file which is run at startup. The autoit script runs as the explorer window opens up.
It seems as though you are taking the wrong approach to the problem, so I'll answer what you are asking and what you should be asking.
First up though, that line of code is not valid, and is not what you want either. You want to automate the explorer window, and RunWait waits for the program to finish. Furthermore you want those items to be strings, that code would never work.
Finding the item in explorer
The explorer window is just a listview, and so you can use normal listview messages to find the coordinates of an item. This is done most simply by AutoIt's GUIListView library:
#include<GUIListView.au3>
Local $filepath = "D:\test.txt"
Local $iPid = Run("explorer.exe /n,/e,/select," & $filepath)
ProcessWait($iPid)
Sleep(1000)
Local $hList = ControlGetHandle("[CLASS:CabinetWClass]", "", "[CLASS:SysListView32; INSTANCE:1]")
Local $aClient = WinGetPos($hList)
Local $aPos = _GUICtrlListView_GetItemPosition($hList, _GUICtrlListView_GetSelectedIndices($hList))
MouseClick("Right", $aClient[0] + $aPos[0] + 4, $aClient[1] + $aPos[1] + 4)
As has already been mentioned, sending the menu key is definitely a better way than having to move the mouse.
Executing a subitem directly
This is how it should be done. Ideally you should never need an explorer window open at all, and everything can be automated in the background. This should always be what you aim to achieve, as AutoIt is more than capable in most cases. It all depends on what item you want to click. If it is one of the first few items for opening the file in various programs, then it is as simple as either:
Using ShellExecute, setting the verb parameter to whatever it is you want to do.
Checking the registry to find the exact command line used by the program. For this you will need to look under HKCR\.ext where ext is the file extension, the default value will be the name of another key in HKCR which has the actions and icon associated with the filetype. This is pretty well documented online, so google it.
If the action is not one of the program actions (so is built into explorer) then it is a little more complex. Usually the best way will be to look at task manager when you start the program and see what it runs. Other things can be found online, for example (un)zipping. Actions like copy, delete, rename, create shortcut, send to... They can all be done directly from AutoIt with the various File* functions.
With more information, it would be possible to give you more specific help.
First, you might want to look at the Microsoft Active Accessibility SDK. In particular look at this interface...
http://msdn.microsoft.com/en-us/library/accessibility.iaccessible.aspx
You can use this to walk the items in the control and find the one with the file name you are looking for and its screen location.
From there, maybe try something like this for simulating the right click.
How can I use automation to right-click with a mouse in Windows 7?
Once you have done the right click, use accessibility again to find the right option on the context menu.
Maybe there's an easier way, you should be able to cobble something together like this if you don't find one. Good luck!
Suppose I have a file named test.txt on D drive. It needs to right click for opening Context Menu. To do this, the following code should work:
Local $filepath = "D:\test.txt"
Local $iPid = Run("explorer.exe /n,/e,/select," & $filepath)
ProcessWait($iPid)
Sleep(1000)
Send('+{F10}')
I've been playing around with some ANSI stuff (like colors etc.) in java and php (from scratch) and I'm trying to find a way to basically wait for a key press. I'd like to have something like the following pseudo code at the end of my main event loop:
If (KeyPressed)
Begin
var event = new KeyboardEvent();
event.Key = ReadKey();
this.BubbleEvent(event);
End
But everything I've been trying over the last couple days fails because the key presses only become available on STDIN after the user has pressed enter.
It doesn't matter much what language you answer in, but java, php, plain old c or c# would be nicest, and I cannot use any really spiffy library stuff because I need to port it to all four of those languages... I need this to work over a telnet or ssh connection, but my research so far suggests it is impossible unless you're working on the local machine.
Please prove me wrong.
The curses function cbreak(3) will disable line-buffering and erase/kill handling. You can do this yourself with stty(1) if you really want.
When your program dies and leaves the terminal in cbreak mode, you can usually use either stty sane or reset to bring the terminal back to a reasonable state.
From within Perl, you can use either the Term::ReadKey or the Curses module to manipulate the terminal. See the Term::ReadKey(3pm) or Curses(3pm) manpage for details.
From within C, you can use either ioctl(2) calls on the terminal device to turn on cbreak mode, or you can use curses. See the ncurses(3) manpage for details.
I know, this is an old thread, but I could not find a suitable answer anywhere else. So with some help from the senior programmers of my company I came up with this:
private void waitKeypress() throws IOException
{
System.in.read();
while ( System.in.available() > 0 )
{
System.in.read();
}
}
The part reading as much input as is available solved my problem that when used multiple times, "System.in.read()" alone does not always wait.
For me this does the trick, I use it like this:
doSomething();
waitKeypress();
doNextThing();
Hope it helps.
Kind regards,
Ralph