My WPF application has windows that are running on separate dispatchers. I need to be able to tell those windows to activate when the main window has focus. What event should I listen too to know when the application has focus?
Application.Activated event is a good place. When you get this event, your application has been activated by the user (either mouse click or keyboard focus switched to it).
It's not clear from the question if you want to know about the application getting focus (in which case, Franci is right) or when the main window gets focus. For the main window (or any particular window), there is a GotFocus event inherited from UIElement http://msdn.microsoft.com/en-us/library/system.windows.uielement.gotfocus.aspx
Related
I am new to WPF and have two windows in a solution. Both are opened using Window.Open().
However there is a difference in behaviour that I don't understand. When one of the windows is opened, if you click the view that launched it the new window is minimised behind the main view, so you can interact with it.
The other window, when opened and you click the main view stays where it is and does not get hidden.
How can I get this window to show the same behaviour as the first?
I figured this out, by removing the parent child relationship in the window I was able to get the functionality I desired.
I've a WPF window, which I transfer over websockets via https://wow.codeplex.com/ !
The problem now is, I need to simulate Mouse Events on that window. Clicks already work directly in WPF, but MouseMove does not. So I tried to use SendMessage API, but this does not work!
The problem is, I can not use APIs which really move the cursor, because multiple Clients could be connected!
I suspect some thing is overloading the mouse move events in the codeplex custom window and returning an unhandled exception. Put a debug pointer in the custom window mouse move and watch. You will get it resolved.
I have a basic WPF application based on MVVM, in that i have to implement save prompt if the user has any unsaved changes on the screen and he tries to close it without saving.
For the same i have handled the closing event of the window and i am presenting a prompt.
My problem is i see the DataContext is stale, it's not having the latest changes in UI.
One more observation is that i see the correct DataContext on closed event of the window.
Any clues..?
Binding would not have stopped when your Window is Closing and will continue to work. Have you checked output for binding errors?
Show me the code :)
I have a WPF app that uses MVVM Light and I wish to both execute a command on the view model and change the keyboard focus to a specific control when the user presses ALT+SHIFT+C.
Is it possible to achieve this in an elegant way?
It depends on how the shortcut key is created (if it's like Visual Studio or more like Windows - it means if you have to hold only ALT or all the keys).
But whatever the logic, You will have to first bind an Event to a Command (it might be the event keydown of one of your controls).
In MVVM Light, you will have to use Interaction.Triggers with EventToCommand (there's a lot ot explanations on google and SO)
The logic would be put here in you command.
Then a dependecy property as show here could be implemented for getting the focus.
I've been working on injecting input into a WPF application. What makes this project hard is that I need to be able to inject the input into the application even though it's running in the background (i.e. another application has the input focus). Using the SendInput() function is therefore out of the question.
So far, I've got keyboard input working but am having trouble injecting mouse input.
I used Spy++ to observe the window messages that get sent to the WPF window when I physically click the mouse button. I then simply craft these same mouse messages (such as WM_LBUTTONDOWN and WM_LBUTTONUP) manually and send them explicitly to the WPF window to emulate mouse input.
Unfortunately, this doesn't work as expected (not even when I, for testing purposes, have set the WPF window as the foreground window).
I've added a button to my test WPF window which when clicked displays a message box. Injecting the appropriate mouse messages when I've manually positioned the cursor over the button doesn't cause the button to be clicked, however (i.e. the clicked event isn't fired by the WPF framework).
If I add a handler for mouse clicks on the actual dialog (the client area), that handler does get called if I position the cursor over the dialog itself and inject the same window messages as before:
this.MouseLeftButtonDown += WndMouseDown;
public void WndMouseDown(object sender, EventArgs e)
{
...
}
Strangely enough, if I change the push mode of the button to Press (i.e. it's considered clicked on mouse down rather than the default mouse up), the button clicked event is now fired when I inject the same messages as before. (It's worth mentioning that the handler from the example above correctly fires for both mouse downs and ups, so it'd seem the WPF framework does process both messages successfully.)
It seems like there are some other criteria that need to be fulfilled in order for a mouse clicked event to be fired by the WPF framework. Does anybody know how mouse input is handled internally in WPF, or why it's not interpreting my mouse up and down messages as a click on the button?
(It's worth mentioning that this approach [sending window messages] works fine on ordinary Win32 windows, such as the Start->Run dialog. The difference here is that WPF only has one physical Win32 window and the rest is WPF specific, which means all window messages go to that top-level window rather than the actual button.)
I've been searching high and low for an answer to this and would appreciate any thoughts or ideas.
I'd highly suggest going the UIAutomation route. You create an AutomationElement by window handle. Crawl to the button and invoke it. I'd just like to know how you managed to get the keyboard input working. I am currently trying to resolve the converse issue. How to get a WPF window (I've managed to get a hWnd to it via Win32 calls), to respond to virtual keyboard messages. I've logged ++spy sessions on the window in question and replicated it's input without success.
Use UI Automation to do this - trying to manually simulate input via window messages is a textbook mistake, like trying to start a land war against Russia.
Your strategy is basically sound but in order to send a message to a window owned by another process you must first register the message.
Here is an article explaining the whole business. The sample code is unfortunately in VB but I'm sure that won't stop you.