I'd like to simulate 'real' keystrokes in an inactive window. After some research I found the Windows api. Since Im used to Java, I quickly found JNA, which implements the winapi.
I wrote some code, that could simulate keystrokes in a active window with the sendInput() method. The window did not detect virtual keycodes. After some search, windows with directinput need scancodes apparently. And it worked with the following code:
import com.sun.jna.platform.win32.BaseTSD;
import com.sun.jna.platform.win32.User32;
import com.sun.jna.platform.win32.WinDef;
import com.sun.jna.platform.win32.WinDef.HWND;
import com.sun.jna.platform.win32.WinUser;
int KEYEVENT_SCANCODE = 0x0008;
int KEYEVENT_UP = 0x0002;
WinUser.INPUT input = new WinUser.INPUT();
input.type = new WinDef.DWORD(WinUser.INPUT.INPUT_KEYBOARD);
input.input.setType("ki");
input.input.ki.wVk = new WinDef.WORD(0);// 0 cause scancodes are used
input.input.ki.time = new WinDef.DWORD(0);
input.input.ki.dwExtraInfo = new BaseTSD.ULONG_PTR(0);
input.input.ki.wScan = new WinDef.WORD(0x2C); // scancode for 'y'
input.input.ki.dwFlags = new WinDef.DWORD(KEYEVENT_SCANCODE); // keydown
User32.INSTANCE.SendInput(new WinDef.DWORD(1), (WinUser.INPUT[]) input.toArray(1), input.size());
input.input.ki.wScan = new WinDef.WORD(0x2C);
input.input.ki.dwFlags = new WinDef.DWORD(KEYEVENT_SCANCODE | KEYEVENT_UP); // keyup
User32.INSTANCE.SendInput(new WinDef.DWORD(1), (WinUser.INPUT[]) input.toArray(1), input.size());
Now I wanted it to be 'smooth', so that the window could be in the background or minimized. I found the SendMessage() and PostMessage() methods and thought I understood its concepts.
You pass the handler of a window, the message(wm_keydown and wm_keyup seems good for the task) and and its specific params.
I tried this, but it did not work. (same for postMessage).
User32.INSTANCE.SendMessage(handler, WinUser.WM_KEYDOWN, new WinDef.WPARAM(0x5A), new WinDef.LPARAM(0x002C0001));
Thread.sleep(100); //tried with and without
User32.INSTANCE.SendMessage(handler, WinUser.WM_KEYUP, new WinDef.WPARAM(0x5A), new WinDef.LPARAM(0xC02C0001));
Then I tried WM_CHAR and it worked partially. It worked in the chat of the window, but did not trigger hotkeys.
After some research, people say, you have to use directinput hooks(?), since some windows won't recognize messages from the winapi, but mine did apparently from sendInput and sendMessage with WM_CHAR.
Have I passed wrong params? What does it mean, that wm_char is regocnized, but wm_keydown and wm_keyup is not?
I already found lots of examples, stuff on stakeoverflow and the web, but it did not really help.
Thanks for reading and answering.
#update I used a tool for detecting messages. The Messages created by real keystrokes and the ones created from the code are equal:
In both cases there is a WM_keydown, then WM_char and WM_keyup.
Every param of every message is equal. In addition to that, like I said, if the chat is opened, there are characters written, but actions won't perform, when the chat is closed.
I checked, what messages are send with the sendInput() method: they are equal to the both cases above, but action is performed.
I'm not able to inprete this behavior.
Related
I'm writing a small accessibility app which simulates certain keyboard gestures, such as volume up\down.
The goal is to send a single command.
In practice, the volume goes all the way up to 100%, as if user pressed a button for couple seconds or as if the message was dispatched multiple times.
This behavior is the same with both PostMessage and SendMessage, in both C and C# (using PInvoke)
C:
PostMessage(0xffff, 0x0319, 0, 0xa0000)
C#:
PostMessage(new IntPtr(0xffff), WindowMessage.WM_APPCOMMAND, (void*)0, (void*)0xa0000);
The meaning of parameters: send to all windows, message, no source, volume up
Question: How do I issue a command which would result in Windows adjusting volume by the smallest increment?
Additionally, I attempted using WP_KEYUP and WP_KEYDOWN, without success
// dispatch to all apps, message, wparam: virtual key, lparam: repeat count = 1
User32.PostMessage(new IntPtr(0xffff), User32.WindowMessage.WM_KEYDOWN, new IntPtr(0xaf000), new IntPtr(1));
User32.PostMessage(new IntPtr(0xffff), User32.WindowMessage.WM_KEYUP, new IntPtr(0xaf000), new IntPtr(1));
The reason why the command is sent multiple times is, as pointed by Hans in the comment, I broadcasted it to all windows using 0xffff as first parameter. Every window handled it by increasing volume by a notch.
The solution to sending multiple messages is to send the message to either
The shell handle GetShellWindow()
The foreground window handle GetForegroundWindow()
Both handles adjusted the volume by one notch. GetDesktopWindow() did not work, though.
I am making an addon in Firefox, so I have a ChromeWorker - which is a privileged WebWorker. This is just a thread other then the mainthread.
In here I have no code but this (modified to make it look like not js-ctypes [which is the language for addons])
On startup I run this code, conn is a global variable:
conn = xcb_connect(null, null);
Then I run this in a 200ms interval:
evt = xcb_poll_for_event(conn);
console.log('evt:', evt);
if (!evt.isNull()) {
console.log('good got an event!!');
ostypes.API('free')(evt);
}
However evt is always null, I am never getting any events. My goal is to get all events on the system.
Anyone know what can cause something so simple to not work?
I have tried
xcb_change_window_attributes (conn, screens.data->root, XCB_CW_EVENT_MASK, values);
But this didn't fix it :(
The only way I can get it to work is by doing xcb_create_window xcb_map_window but then I get ONLY the events that happen in this created window.
You don't just magically get all events by opening a connection. There's only very few messages any client will receive, such as client messages, most others will only be sent to a client if it explicitly registered itself to receive them.
And yes, that means you have to register them on each and every window, which involves both crawling the tree and listening for windows being created, mapped, unmapped and destroyed and registering on them as well.
However, I would reconsider whether
My goal is to get all events on the system.
isn't an A-B problem. Why do you "need" all events? What do you actually want to do?
I am using Canon SDK to get the events from the camera. In the SDK, we register a callback function, which is called when a particular event occurs. I have built a Java wrapper, which communicates with the SDK.
But when the event is triggered, my window doesn't get the event directly. Infact on windows, this is how I get the event and dispatch it to myself:
private static final User32 lib = User32.INSTANCE;
boolean hasMessage = lib.PeekMessage( msg, null, 0, 0, 1 ); // peek and remove
if( hasMessage ){
lib.TranslateMessage( msg );
lib.DispatchMessage( msg ); //message gets dispatched and hence the callback function is called
}
Basically one peeps if the window has received an event or not and then proceeds. On Mac, one can do it using Cocoa by having a NSApplication and WindowServer sends events if any.
I am looking for similar alternative using X11. Any sample code/link will suffice.
PS: This a follow up question to this.
I suppose you are looking for XPeekEvent. The Xlib is very well documented and the manpage for XNextEvent(3) says:
The XPeekEvent function returns the first event from the event queue,
but it does not remove the event from the queue. If the queue is
empty, XPeekEvent flushes the output buffer and blocks until an event
is received. It then copies the event into the client-supplied XEvent
structure without removing it from the event queue.
Example code for displaying a basic Xwindow and a main event loop for handling events can be found (for example) on wikibooks.
I have a MFC GUI app that has multiple frames (sort of like Outlook'ish behavior with main window, and message/appointment windows being created in new frames, or Skype like multi frame syncronization), and I need to PostMessage malloc'ed data through the window hierarchy.
Say, I get the string, _wcsdup it, PostMessage(WM_NEWSTRING, ...), and, the control somewhere deep down the hierarchy processes it, or if there are no subscribers, the message get's cleaned.
What I am looking into now, is that all messages are posted to application thread, thread finds the active frame or best fit frame, passes the message to it, frame passes the message to it's view, the view passes message to subview and so on, if there is no view to process the message, it get's free'd.
The problem is that these chaining commands are pretty tiring to write, as I have to duplicate the message forwarding code in each CWnd class I have. At the same time, resource cleanup is pretty unpleasant, because if there is no window to catch the message, someone has to call the free. Therefore simply posting the message to the main message pump without extra handling, hoping that someone will always catch it, is not a valid approach. PostMessage returns S_OK, no one sees the message as processable, and it's left dangling.
Is there a better, correct approach for what I'm looking for?
I would never use PostMessage as you describe. My solution often involves a hand-shake:
// From CNotifierBlah
PostMesssage(hWnd, UWM_NEW_DATA, 0, 0);
//
LRESULT CDestinationWnd::OnNewData(WPARAM wParam, LPARAM lParam)
{
CNewData newData = GetNotifierBlah().GetNewData(); // Thread-safe getter!
}
Pretty much the same as Observer pattern.
Is there a way to track which window currently has keyboard focus. I could handle WM_SETFOCUS for every window but I'm wondering if there's an alternative, simpler method (i.e. a single message handler somewhere).
I could use OnIdle() in MFC and call GetFocus() but that seems a little hacky.
So from the way you worded the question I'm inferring that you want to have an event handler which is invoked whenever focus switches between windows. You want to be notified, rather than having to poll.
I actually don't think calling GetFocus from OnIdle is that much of a hack - sure it's polling, but it's low-overhead polling without side effects - but if you really want to track this, Windows Hooks are probably your best choice. Specifically you can install a CBT hook (WH_CBT) and listen for the HCBT_SETFOCUS notification.
Windows calls the WH_CBT hook with this hook code when Windows is about to set the focus to any window. In the case of thread-specific hooks, the window must belong to the thread. If the filter function returns TRUE, the focus does not change.
You could also do with with a WH_CALLWNDPROC hook and listen for the WM_SETFOCUS message.
Depending on whether you make it a global hook, or app-local, you can track focus across all windows on the system, or only the windows owned by your process.
There is an easy way using .Net Framework 3.5 : the library UI Automation provides an event focus changed that fires every time the focus change to a new control.
Page on MSDN
Sample:
public void SubscribeToFocusChange()
{
AutomationFocusChangedEventHandler focusHandler
= new AutomationFocusChangedEventHandler(OnFocusChanged);
Automation.AddAutomationFocusChangedEventHandler(focusHandler);
}
private void OnFocusChanged(object sender, AutomationFocusChangedEventArgs e)
{
AutomationElement focusedElement = sender as AutomationElement;
//...
}
This api in fact use windows hook behind the scenes to do that. However you have to use the .Net Framework...
How about the Win32 GetForegroundWindow?
If you're programming in .net 3.5, the Automation package olorin mentions is by far the easiest, but beware of using it in a program that itself has a UI, at least if the UI is done in WPF -- the focus tracking hooks get confused by events in its own app, and quickly lock up the UI. I sent MS a bug report on it. I have not observed the same problem using a traditional Windows Forms UI. You could, of course, put the tracking code in a separate console app and use some kind of ipc to transmit the info you need.
The tempting alternative of using Interop to access the WH_CBT Windows Hook from C# won't work -- the only global hooks you can get at from C# are the mouse and keyboard.
Well, this may not be very graceful... but you can retrieve the current focused control pretty easily. So you might consider setting up a timer that asks every 1/2 second or so "Where is the current focus?"... Then you can observe changes. Example Delphi code is below; it should be pretty easy to adapt, since the real work is in the Windows API calls.
<snip>
function TForm1.GetCurrentHandle: integer;
var
activeWinHandle: HWND;
focusedThreadID : DWORD;
begin
//return the Windows handle of the currently focused control
Result := 0;
activeWinHandle := GetForegroundWindow;
focusedThreadID := GetWindowThreadProcessID(activeWinHandle,nil);
if AttachThreadInput(GetCurrentThreadID,focusedThreadID,true) then begin
try
Result := GetFocus;
finally
AttachThreadInput(GetCurrentThreadID, focusedThreadID, false);
end;
end; //if attached
end;
procedure TForm1.Timer1Timer(Sender: TObject);
begin
//give notification if the handle changed
//(this code gets fired by a timer)
CurrentHandle := GetCurrentHandle;
if CurrentHandle <> PreviousHandle then begin
Label1.Caption := 'Last focus change occurred # ' + DateTimeToStr(Now);
end;
PreviousHandle := CurrentHandle;
end;
<snip>
http://msdn.microsoft.com/en-us/library/ms771428.aspx
Has a window focus tracker sample.
You could monitor messages for the WM_ACTIVATE event.
ref