We have a legacy application in Win32, we are building new modules using WPF. We have a situation where we need to notify the WPF window of a particular shotcut key message invoked on a win32 window. My question is, is there a way to handle the keyboard messages on WPF window invoked on a win32 window? If so what do I need to do to achieve it?
Thanks,
Ub
What you need is a keyboard hook. Hooks can be global or application-wide. In your specific case I think application-wide is enough.
So, what you need is to get the Handle of the Win32 process and hook the message to filter the WM_KEYDOWN messages. Here is an example:
http://blogs.msdn.com/b/toub/archive/2006/05/03/589423.aspx
Related
I am updating an old application written in win32 in C and the requirement is to hide the mdi child windows based on some flags. I tried several methods but to no avail.
I tried ShowWindow with SW_HIDE but that doesn't work. The window just remains there blank (and generates no paint message). The same happens with SetWindowPos with SWP_HIDEWINDOW as one of the flags. SetWindowLong with ~WS_VISIBLE is the worst of the lot. It neither blanks the client area nor generates paint message, thus smearing it when other windows are moved over it.
Is it even possible to do it? If so, how?
PS: I did see a Delphi question here with the same requirement but I don't know Delphi and couldn't make out anything.
As was explained in earlier discussions, such as this one:
How to hide a MDI Child form in Delphi
MDI is simply not designed to allow child windows to be hidden, and Delphi's VCL has internal logic to prevent user code from trying to make that mistake. Trying to circumvent that logic causes unwanted side effects due to MDI's limitations.
In short, to "hide" an MDI child window, you have to destroy it, and then re-create it when you want to "show" it again. That is the only reliable option that MDI supports.
I am developing Windows forms application using visual studio C++, and want to sendmessage from a thread to the window (WM_USER message), however I can't find out where to place the code (Studio does it automatically) for receiving that message. How to do it?
Is it the right approach in windows forms application?
You need to override the WndProc method of your form. In that method you can implement any special handling you need for any Windows messages delivered to your form's window.
Take care to follow the documentation to the letter:
Notes to Inheritors
Inheriting controls should call the base class's
WndProc method to process any messages that they do not handle.
I've a WPF application which allows me to edit some data.
I would like to make that if we try to close the application, the user must acknowledge that he will lost its modifications.
But here we are, I got several problem:
There is no "Closing" commands on the windows object(I can execute a command when I have an event from the code behind I guess)
I don't know how it's the recommended way to cancel something with the MVVM pattern? Normally I would have put the e.Cancel = true;, but we can't because it's a command
So how would you ask the user if he is sure to close the windows, with the MVVM pattern?
The concept is to add a behavior to your window that "hooks" into the window closing event. Once the behavior is hooked in, you can perform just about any action you need without violating the principles of MVVM. Check this link for information on how to create a window closing behavior:
http://gallery.expression.microsoft.com/WindowCloseBehavior/
Hope that helps.
Since you tagged this question as "mvvm-light", you can check the EventToCommand in MVVMLight. It may meet your needs.
This question is similar:
Handling the window closing event with WPF / MVVM Light Toolkit
I have been developing a Lync Silverlight application in Silverlight and now I am trying to shift it to WPF.
However, I am facing some thread affinity issues. For example I display the Lync client's state on my page in a textblock, and so in my code behind have wired a state changed event handler, that writes the new state into the textblock whenever the state of Lync client changes.
Now, this worked perfectly in silverlight but seemingly is not allowed in WPF.
Now my questions are:
How come it works in Silverlight bt not in WPF, even though Silverlight is supposed to be a subset of WPF?
Thread affinity is an important concept and I know we can use invoke dispatcher, but doesn't it just beat the concept of asynchronous programming in form of event handlers and callbacks?
I have a button defined in my XAML page, and the click event handler defined on it can access other UI elements, it does not suffer the problem outlined above.
But if I define a LyncClient instance in my code-behind, event handlers defined on it cannot access the UI elements. Why so, I detected no such difference between UIElements and other objects in Silverlight?
Based on above comments, I'll suggest the following "answer"...
I would guess it is more likely than not that there is some sort of different in the way that the SL API was written than that of the WPF api. That could explain the difference in the thread that is used when the API issues the callback. To verify this, you could:
Ask MS directly
Put some diagnostics code in your callback method to log the thread ID and compare that to the main thread of the application. Do this for both SL and WPF to see if they are the same or different threads.
Open the assemblies in Reflector to inspect how each API was written.
In terms of handling this specific situation, in your callback, you could:
Get the dispatcher object (different for SL than WPF) and always issue UI updates through Dispatcher.Invoke.
Use databinding and INotifyPropertyChanged to insulate the UI from the property. You could delcare a property on a ViewModel or in the code behind. Then bind the UI's textbox to that property. Databinding has some smarts in it that will automatically marshal property changes to the correct thread (in most cases anyway).
Hope that helps.
I'm looking for a way to overlay the graphical output of a third-party application with some lines, arcs etc. The applications accepts a handle of a window in which it will then display its output.
Using VC++ I put together a Windows Forms app in Visual Studio that draws (non-static) stuff in the onPaint-method of a form. Passing this form's handle to the other app, of course, overwrites my graphics stuff every time the other app redraws.
Can I somehow hook into this redrawing process to add my graphics after the other app redraws? Overlaying the form with a transparent panel onto which I draw could be an alternative. But real transparency for controls seem to be a problem of its own in Windows ...
You can't do this easily without getting notifications from the app. Which, if it doesn't provide them, would require setting a global hook with SetWindowsHookEx() so you can see the WM_ERASEBKGND and WM_PAINT messages. That's hard to get right, you cannot write such a hook in managed code. Since it requires injecting a DLL into the target process.
The only other option is that you put a transparent overlay on top of your form. Another form that has its TransparencyKey property set. The basic code you need to get that right is available in my answer in this thread. You just need to tweak it so it is permanent.