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.
Related
When using FolderBrowserDialog in WPF, I've seen a few answers where using the Win32 API is required to make it modal. For example,
Using FolderBrowserDialog in WPF application
How to use a FolderBrowserDialog from a WPF application
Actually, is the Win32 Api REALLY required ? I just tried the FolderBrowserDialog and it is already modal by default; simply calling .ShowDialog() is already modal to the underlying window. (What are the other answers talking about or have the wpf internals changed ?)
EDIT: using Visual Studio 2015 with .NET framework (not core)
Actually, is the Win32 Api REALLY required
Yes. The FolderBrowserDialog is exposed through Win32. You can't write software for Windows without using Win32 in some way or another.
I just tried the FolderBrowserDialog and it is already modal by default; simply calling .ShowDialog() is already modal to the underlying window.
That's because when you call ShowDialog() it passes IntPtr.Zero for the owner hWnd parameter (the same as NULL in C). When you pass NULL then Windows uses the currently active window in the process as the owner - so an owner is still set, it's just determined automatically:
From the documentation for WinForms' ShowDialog() (the overload without the owner parameter. While WinForms and WPF are separate, the principle is the same for both):
When this version is called, the currently active window is made the owner of the dialog box. If you want to specify a specific owner, use the other version of this method.
That said, you should still specify the owner hWnd where possible because you may rearchitect your application and may want a different window to be the owner (e.g. when you want to show a dialog immediately after the non-root parent window closes)
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.
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
I'm learning Chinese at the moment and I have gotten my hand on a Chinese dictionary definition.
Now I would like to make an interface.
All I really want the application to do is when I point my mouse pointer over any text on the screen (in any window), it would identify the text I am pointing at and then display a small form over it, which would the chinese transaction.
Is that possible to do? Can WinForms apps interact with windows outside of it's own application?
In C# you can get text under mouse cursor by P/Invoking
GetCursorPos
GetClassName
SendMessage
WM_GETTEXT
WM_GETTEXTLENGTH
WindowFromPoint
Like mentioned here
here is another example in C++
A WinForms application can interact with the Windows of other applications. Window handles exist in a global namespace so if you can get the handle of another application's window you can send it messages. You will have to use pinvoke to do some of this, have a look at WindowFromPoint
However, there is no standardized way to display text in a window; there are dozens of APIs for displaying text. So when you point at text with a mouse, you can only get the pixels, but not necessarily the text.
Some window classes will allow you to send class-specific messages query for the text at a specific location, but many will not. Your best bet is probably to use the same methods that screen readers for the blind use http://en.wikipedia.org/wiki/Screen_reader
I am using a third-party Windows Forms control that performs some actions "delayed" using the Application.Idle event.
Now that we're moving our application to WPF, these actions stopped working.
I've found that the System.Windows.Forms.Application.Idle event is not raised as expected.
How can I get the Idle event to fire in a WPF application so that I can continue to use that third-party control (within a WindowsFormsHost)? It is not possible to modify the Windows Forms control.
You should read this page on MSDN which describes the message loop behavior in a WPF application. In particular it looks like the ComponentDispatcher class can be used to catch a ThreadIdle event which would roughly correspond to the Windows Forms Application.Idle event.
You could then presumably use the System.Windows.Forms.Application.RaiseIdle method to raise the Idle event as the component expects.
If you are using a WPF Application, you are actually no longer using the System.Windows.Forms.Application class to run your application, even if your application contains a Windows Forms Control.
Instead, you are using the System.Windows.Application class (different namespace).