I'm developing an app and I'd like to trigger functions in my app via keystroke combos when it's not in focus.
Because I'm developing my app in AIR, I do not have access to listen to global Keystrokes. However, I can receive STDOUT from an application. So, I'm looking for a utility that can give me this ability. I'm looking for both Windows and OSX (cross-platform baby!)
For Windows, you could write a simple application that installs a keyboard hook and prints information about the key event to stdout. See SetWindowsHookEx.
For Windows:
I don't know of any app off the top of my head, but here are some ideas that might work within 100 lines of code...
I would avoid SetWindowsHook, as that would inject your code into all apps. (Because I've spent good time debugging crash dumps and bugs as a result of poorly written hooks...)
You could write a console app with DirectInput (old gaming keyboard API). I believe you just pass DISCL_BACKGROUND and DISCL_NONEXCLUSIVE into IDirectInputDevice8::SetCooperativeLevel call. Use IDirectInputDevice8::SetEventNotification to set the event handle so you don't have get into a busy wait loop polling for input. And that should do it. I did this once for my app a long time ago on Windows 98 and it worked really well. But DirectInput is very close to being deprecated technology so YMMV.
Another simple hacked up way to do what you are doing is to have your app create a hidden window, call call RegisterHotkey for all the keyboard, and pump window messages. Your wndproc will get a WM_HOTKEY window message that you can use that to generate a message to stdout.
The simplest way, but will be slightly error prone and cpu-expensive is to have your console app get into a loop and call GetKeyboardState. This will return the entire state of the keyboard of all keys that are up and down. You'll have to figure out how translate each poll into a logical keystroke. I'd recommend sleeping a few milliseconds between polls so you don't kill system-wide performance.
Can't help you on OSX.
For windows, here is a utility that will listen to the keyboard.
http://www.dynamicnetservices.com/~will/academic/textinput/keycapture/
Related
I'm using a low-level keyboard hook (WH_KEYBOARD_LL) to disable certain input, such as Alt-Tab. I create the hook on a thread with a message pump, so I can properly handle the notifications.
The hook's callback function is able to process keyboard events whenever I'm not focused in the window that created the hook (i.e. my main window), but as soon as I activate that window, no events show up in the hook until I deactivate the window again and the input instead propagates to the window's WindowProc.
Does anybody have any clue what's going on here?
UPDATE: So, it turns out this behavior is caused by also registering for raw input in the same process. Apparently, using raw input causes my low-level keyboard hook to be disabled whenever my process’s window is focused. Does anybody know why and how to work around this?
Windows doesn't call low-level keyboard hooks if the most recently registered hook (aka the first hook to be executed) comes from a process that registered itself for raw keyboard events.
So a workaround is to create a second low-level keyboard hook in another process afterwards. Yes, this will cause both low-level keyboard hooks to be executed even when the focus is on a window from the first process.
Bad for performance, and who knows what Windows will bodge next - so I'm not really endorsing it - but it works.
I try to send a WM_LBUTTONDOWN and WM_LBUTTONUP messages to a window( simulating mouse clicks without moving the cursor ).
My program is working very good on many windows, but there are a few that don't work :(
Like Registry Editor, Yahoo Messenger, some Firefox sites, etc...
How can I make to work with those from above ??
NOTE#1: I use Win7
NOTE#2: My code is just calling the api and functions and aply them on the specific window handle. Its working ok but not on all windows :(
It is another aspect of UAC, called UIPI or User Interface Privacy Isolation that could cause this trouble. Designed to prevent a program that run un-elevated from hijacking the capabilities of an elevated one. That certainly explains the trouble with Regedit.exe, clearly UAC would be ineffective if a program could commandeer it to poke stuff into the registry. You'd have to run your program elevated to bypass this restriction.
Another one is that SendMessage() doesn't properly simulate mouse input. The messages you are sending are normally posted to the message queue. You need to use PostMessage() instead. You should also emulate WM_MOUSEMOVE.
The proper way to simulate mouse input is through SendInput(). That one exactly emulates the mouse driver behavior, there's no way for a program to tell the difference. But with the added requirement that you have to make sure that whatever program you are trying to automate runs in the foreground. That's very difficult, SetForegroundWindow() isn't reliable enough. So only consider SendInput() if you actually only want to send mouse messages to the foreground window, whatever it might be.
You can call SwitchToThisWindow instead of SetForegroundWindow, which is much better and it works most of the times, and then either call SendInput or mouse_event, which is much more comfortable, because you're not dealing with structs at all.
I have been working on windows automation and monitoring.
What exactly happens when I lock the screen of a windows machine?
I am working with Windows 7 at the moment, are there big differences to the behavior if I switch to Vista or the server versions?
Is there still a desktop that can be accessed via api's?
I know that i can still send key strokes and mouse clicks to specific windows (via ControlSend and ControlClick), but there seems to be no "desktop" itself.
Could someone shed some light on this whole thing or point me at a readable source where I could get an overview over the topic?
Basically what happens is that Windows switches to the secure desktop, makes it the current one, so input is now associated with it.
The old desktop remains where it was: all the HWNDs on the desktop are still there, and any thread attached to that desktop can still access those HWNDs, get their location, and so on. You can still send messages to windows on this desktop, so long as the thread sending the message is also on that desktop.
However, since the desktop is now inactive, it cannot receive input. GetForegroundWindow will return NULL (IIRC), and you can't use SendInput any longer, since input now belongs to [a thread on] a different desktop; no controls on that inactive desktop can receive focus.
Note that sending keypress messages to a control that doesn't have focus can sometimes cause unexpected behavior, since the app or control generally never expects to receive keyboard input without getting the focus first. (This can be problematic for controls that set up some sort of input context in WM_SETFOCUS and clear it up in WM_KILLFOCUS, for example.)
In short, the UI is still there: you can do certain queries against it, but you can no longer automate it as you could on a regular desktop by sending input, and some other functions that relate to focus or input may fail.
I'm not super familiar with AutoHotKey, but the name and description of functionality suggests that it's heavily reliant on the underlying Win32 SendInput API. This won't work at all for keyboard input when a desktop is inactive.
For a reasonable overview of how desktops work and how they relate to winstations, the locked desktop, and so on, check out the Desktop article on MSDN.
One issue that I've run into in the past with desktops and automation is: how to I leave a long-running test that's using some form of user input automation (mouse, keyboard simulation), but still lock my PC so that someone can't just walk by and interfere with it. Once you lock the PC, the desktop is inactive, and so the automation stops working. A similar issue happens if the screensaver kicks in: the desktop switches, and the automation fails.
One solution is to use two PCs: let's call them Main and Test: from Main, open a remote terminal services client onto the Test machine, and then run the automated test on the test machine, but from a terminal services client window on the Main machine. Now the cool part: you can minimize that TSC window, or even lock the Main machine (or let the screensaver kick in), and that virtual session will continue working, thinking that it is still active - it's just that nobody is paying it any attention. This is one way to create a "connected" session with an active desktop, but one that no-one can interfere with, because it's protected behind the locked desktop of the Main machine.
I don't know the details, but I believe the lock screen constitutes a separate "desktop" and maybe also a separate "window station" (as I understand it a window station is merely a container for desktops). The MSDN section on window stations should hopefully be useful: http://msdn.microsoft.com/en-us/library/windows/desktop/ms687098%28v=vs.85%29.aspx
In order to access a desktop, you will need to use the regular windows api's from a thread that is on that desktop. SetThreadDesktop would probably be the easiest way to do that in C, as long as the desktop isn't on a different window station.
Unfortunately, this is already difficult for a regular privileged application, and using AutoHotkey complicates it even more. Since you don't have control over threads or over process initialization, you will probably have to create a new process in the other desktop (you can do this using the CreateProcess API, which appears to have a wrapper available for AHK to which you can supply a desktop name: http://www.autohotkey.com/forum/topic1952.html). Your process will need special privileges to do this; I'm not sure that even running as Administrator is enough.
I want to receive a notification in my C++ application when a screensaver is about to start. I tried listening to WM_SYSCOMMAND messages with wParam == SC_SCREENSAVE which some people think should do the trick.
That didn't work. Spy++ even showed that my window didn't receive any WM_SYSCOMMAND message. Interesting thing is when I turned off the monitor I did receive the message with wParam == SC_MONITORPOWER. Am I understanding it wrong? Or did I just miss something?
Edit: For testing I used the default windows screensaver (the one with windows logo).
It appears that I will receive the SC_SCREENSAVE message only when my window has focus. The way around this is to set global hook. That would require me to put the callback function in a separate DLL and there is also this scary message about hooks slowing down the system so I decided to drop the idea of responding to screensaver start.
This is a relatively complex task (although it would be nice if it were easy).
Some of these tests you'll find online only work if your window is in focus. If it's running in the background it may not receive such messages.
Other tests rely on a screensaver program running (check the currently set screensaver, and then watch the process list to see if it's active) but don't work if you go into powersave mode, or if your screensaver is a black screen (ie, no program, just monitor off).
I don't believe there's an ideal way to do this. You might want to go back to the beginning and think more carefully about why you need to detect this state, and what you are trying to accomplish. You might need a different solution.
Probably my answer comes too late.
The MSDN handles screensavers under "Legacy".
On a notebook they waste battery and on a PC they are also useless.
It is better to turn the monitor off than letting it show a screensaver.
As you don't explain exactly what you want to do I don't know if you really need the notification BEFORE the saver starts or if it is enough to get notified when it already has just started.
In the latter case it is easy.
Write a thread that periodically checks:
BOOL b_SaverRunning;
SystemParametersInfo(SPI_GETSCREENSAVERRUNNING, 0, &b_SaverRunning, 0);
I don't really know where to begin. Let's start with the stupid questions:
What language should I use for this? What is suited for the task at hand?
Next, the real ones:
Is there a way to stop the screensaver from starting, short of changing the cursor position? If not, will changing the cursor position even work?
SetThreadExecutionState will prevent the screensaver from coming on or the machine from automatically going to sleep if you pass the ES_CONTINUOUS and ES_DISPLAY_REQUIRED flags.
I wrote an app awhile ago that does exactly what you are asking for. It runs as an icon in the System Tray, not the Taskbar, and uses a global message hook to disable the WM_SYSCOMMAND/SC_SCREENSAVE notification from reaching any applications. If that notification does not reach the DefWindowProc() function, the screen saver will never run.
Your program does not need to be visible in the task bar at all.
You don't even need a program at all, if you can disable the screensaver in the registry.
What you want to do can perhaps be achieved by sending a MOUSE_MOVE event to the desktop window. If you want to use C# (the only language I am current with right now), you can look at this article, but maybe a simple C program using the WinAPI is better suited for this task.
.NET will easily allow you to put an application in the system tray (checkout the NotifyIcon object in System.Windows.Forms.Controls).
I believe you can use the SetCursorPos (http://msdn.microsoft.com/en-us/library/ms648394(VS.85).aspx) API call to prevent the screen saver, just make sure you set them to the current location so you don't actually move the mouse.