I'm putting together an AutoIt script to automate notepad and this software called Ecsow Dialer. I'm stuck on one thing, that's trying to find the hot key to select the text box so it's ready to type text in. Manually you'd just press enter and it will open, but sometimes pressing enter will open up the menu along the top of the window, i think it all depends on where the cursor is in the window. I took a couple of screen shots, here they are below:
The red part is where i need it to select, when you press enter, it opens it up ready for text input:
and here is what happens when you press enter sometimes, sometimes it opens the menu above, this is why i need a hot-key instead of just having autoit press enter.
If anyone can help me out, i'd really appreciate it. Thanks.
Have you taken a look at the _GUICtrlListView* functions (they are user defined functions, meaning they can interact with outside programs as well in many cases)?
I'm not sure that's a standard window, if the AutoItInfo.exe tool doesn't provide a classid/classnamenn you are probably dealing with a non-windows-standard GUI.
If that's the case, try out IUIAutomation, they've done a good job with their tool helping others automate past AutoIt's standard functions.
Related
I have to use USB barcode scanner in application running on remote desktop. This scanner is being recognised by Windows as keyboard. When I try to scan barcode however, every 3th or 4th character is being changed to another one. When I type numbers by hand, they are being correctly written. The question is: is there any way to programmatically produce "lag" on keyboard globally? I would like to create for example a half second gap between keyboard input events and a result on the screen. Some time ago I worked with Windows hooks, and I was able to change keyboard input globally, but I remember I had problems with delaying it. Is there any other way?
you can make an autohotkey script to listen to a keyboard input, wait and then press the same keyboard button.
once you have intalled AHK(autohotkey) , you can do a AHK script whit the intructions that are in the ahk documentation.
Right-Click on your desktop.
Find "New" in the menu.
Click "AutoHotkey Script" inside the "New" menu.
Give the script a new name. Note: It must end with a .ahk extension. Ex. MyScript.ahk
Find the newly created file on your desktop and Right-Click it.
Click "Edit Script".
A window should have popped up, probably Notepad. If so, SUCCESS!
i::
sleep, 500 ;
Send, i
Return
(you can change the "i" for other keyboard keys).
a function would reduce the amount of code that you use, but i don't know how to do it in a AHK script
I'm trying to build an terminal application that, when started, will take the user away from their prompt and present them with a screen with an interactive menu. I would like the user to be able to interact with it in the following way:
They will start the application by running my_app from the terminal. This will start the application and present them with the root menu.
They will use the cursor keys to navigate around the menu and use the [ENTER] key to make a selection.
When they make a selection, they will be presented with another screen/menu when they will do some work. When they are finished this work, they will press a key that will take them back to the root menu.
The key thing I'm after is for it to not be a scrolling view that just adds more information to the end. I'd like it to have distinct, encapsulated views with a navigation hierarchy. My problem is that I don't know how to produce such a view and present it to the user, and then dismiss it again once they're done. If someone could give me some kind of design pattern for this kind of application, I'll be able to take it from there.
FWIW, I'm using Ruby and would like the app to be cross-platform. If that's too much to ask, then Windows will suffice.
I'm a Linux guy and I want to suggest ncurses library for you. there's an ongoing effort to port this also to Windows.
AFAIK it's going pretty well, please check this question.
In one of my other questions, I inquired about a shortcut to enable a particular feature in the VS2010 IDE. It looks like the only way to make it happen is through the Macro Recorder, which I have unfortunately never used (as it looks quite powerful!).
The straightforward way to make my macro would be to start the recorder with CTRL+SHIFT+R, then go to Debug -> Exceptions, check all of the boxes I want, click OK, and then stop the recorder. Unfortunately, all that I can see is that it opens the Exceptions window, and no more than that.
I figured that if the Macro Recorder doesn't record mouse events, then surely it must record keyboard events, but I was wrong about that, too. Upon editing my TemporaryMacro, I saw that the only thing it does is
DTE.ExecuteCommand("Debug.Exceptions")
What I really want to do is add a method that can enter keystrokes like DOWN, ALT+T, and ENTER.
I have googled like crazy, gone through MSDN, and checked here on SO. I am embarrassed to say that I have been unable to find any information about an object in DTE that allows me to send keystrokes! Hopefully, someone here will know how to do it!
This is the closest thing I've found to a document regarding keystroke automation: http://msdn.microsoft.com/en-us/library/8h31zbch.aspx
Edit: I figured it out how to send keystrokes, but how can you send them to popup dialogs???
Here's the code I tried:
Public Module RecordingModule
Sub TemporaryMacro()
DTE.ExecuteCommand("Debug.Exceptions")
System.Windows.Forms.SendKeys.SendWait("+{TAB}")
System.Windows.Forms.SendKeys.SendWait("{DOWN}")
System.Windows.Forms.SendKeys.SendWait("%T")
System.Windows.Forms.SendKeys.SendWait("{ENTER}")
End Sub
End Module
I couldn't get it to work, so I tried debugging, and that's when I realized what was happening -- SendWait doesn't get called until after the dialog is dismissed.
So does anyone know how to use the Macro Recorder to interact with popup dialogs via keyboard commands?
I don't think you can send keystrokes to the dialog box.
I would recommend that you take a look at AutoHotKey, from there you can define interactions with dialog boxes. It works outside of Visual Studio, so you will probably find many more uses for it.
I want to make my own Start Menu replacement and I am trying to figure out what approach to use. There are a number of ways the Start Menu is activated: click on it, hit windows key, hit Ctrl+Esc keys or tab until it gets focus and hit the space or enter key.
I know enough about win32 to do each one of these separately and I could figure it out with Spy++. I'd really like to know if there is an easier way through and I can't find any helpful articles.
I'd like to do this for XP and Vista/Windows 7.
I guess that you would have to inject yourself into the explorer.exe process (There can be more than one, but you want the one that has the "Shell_TrayWnd" window) and subclass the taskbar or one of its children to catch/eat the message that brings up the startmenu and instead, show your own window.
Take a look at http://bitbucket.org/wez/evildesk/src/755606d7935d/gdi.cpp , I think you could start your project by seing what they've done.
You can use WindowBlinds and design your own Start Menu as well.
What is your biggest pet peeve related to the windbg debugger from microsoft?
(note: I actually really like windbg if I ignore the unpolished UI.)
Attempting to dock a window is almost always the wrong kind of dock the first time until :I move the mouse just right. Why can't it have the docking cues that VS2008 has?
The ridiculous behavior when you attempt to use click-drag to select text on a line that is wider than its physical window.
The pieces of the history window that I need to copy/paste into bug reports are frequently wider than the physical window. I've gotten so used to the triple-click workaround that I find myself attempting to misuse triple click in other (well behaved) applications.
Key presses are ignored while the focus is in a source window. It's not like you can edit the source code from inside windbg. At least there's the Alt-1 workaround.
How insanely slow .kdfiles copies new binaries across the 1394 connection. It can take up to one minute for a large dll.
Not being able to switch from output window to command window using a key press, I read that 'Alt+1' should work but it doesn't always so I always have to resort to using the mouse. Also sometimes it doesn't remember when I tell it not to ask me everytime if I want to save the workspace when I quit.