In my Win32 application, a child window is created by a third party SDK.The Window creation process is transparent and I cannot associate a WndProc method with the child Window. I want to be able to capture child window messages in parent window. How can I do this? Any help would be highly appreciated.
Have you looked at SetWindowsHookEx? Or if that seems like overkill you could probably just use SetWindowLong with GWL_WNDPROC and define your own custom WinProc then forward to the child window.
There is a pretty good article on MSDN about it.
Related
I have a shell extension that needs to reload its configuration when a specific window message (custom message registered with RegisterWindowMessage) is broadcasted by another application.
I tried several approaches to intercept the message:
Installing a window subclass callback on a window of Windows Explorer, using SetWindowSubclass. This works on Window 7, but not on Windows 8, because apparently DllMain is not called on the main thread, and SetWindowSubclass doesn't work from another thread. This is mentioned in the documentation:
You cannot use the subclassing helper functions to subclass a window across threads
Installing a hook for CALLWNDPROC, using SetWindowsHookEx. Because I don't want to slow down the whole system, I install the hook for a specific thread only (the explorer's main thread). This works on Windows 8, but not on Windows 7... I suspect this is because I'm hooking on the wrong thread, but I'm not sure. And anyway, this approach seems overly intrusive.
Creating a message-only window to handle the message. This doesn't work at all, because message-only windows don't receive broadcasted messages.
Is there a reliable way to receive a window message in a shell extension?
A window message initially seemed to be the easiest way to notify the shell extension, but if you think another mechanism would be more appropriate, I'm open to suggestions.
Create a hidden window and listen for the message in its window procedure.
Register a window class that has default values for all the fields apart from the window procedure and class name. You don't need to specify anything else in the window class since the window will never be visible.
When you create the window, pass 0 for the window style. Specifically exclude WS_VISIBLE.
Pass 0 for the WndParent when you create the window. This will make it a top level window and so eligible to receive broadcast messages.
I am trying to use the Windows API function RedrawWindow to force a window to repaint.
This is working perfectly for almost all applications, but it does not work for a legacy MDI application. It repaints the parent (host) window, but not the MDI child window.
Does anyone know about this issue and how to fix it?
RedrawWindow applies to one window only, so you are probably calling it with the wrong HWND. So you will need to find the correct HWND for the child window.
I would like to host an application window from a process "A" into the main window of a process "B", just as if "A"'s window were a MDI child window. Is this possible in Windows? Or are there some tricks which would allow me to fake this?
By the way, I'd like to remove the title bar (or better yet, all the non-client stuff) of "A"'s window when it is embedded into "B"'s window. I suppose that this must be possible by tweaking the window styles or window classes, but I am by no means an expert in these Win32 intricacies.
It's possible to host the Window. Change A's parent HWND by calling the SetParent function against it. To change the window styles, you need to use the GetWindowLong/SetWindowLong pair to change the attributes that you want to muck with.
If this is a third-party application (ie, not yours), then you're probably in for a rough ride, particularly if the window does any theming or anything custom with its window (for example, changes to the drag area, etc).
Is it possible to start a new process and set it's main window as a child window of my MDI application?
The scenario is: I have a MDI application and I want to start Adobe Acrobat as a child window of my MDI application.
In theory, I believe it's possible using SetParent.
However, in practice, this may be a bit more difficult than you'd expect. Also, you'll need to do work to syncronize the styles, etc.
Just a thought, though - If you are trying to embed Acrobat Reader (not full Acrobat), you may be able to do this easier by embedding a webcontrol and having the acrobat reader plugin used in that...
Here are some samples of people making this work (at least partially):
Related SO question with workarounds for specific issues.
CodeProject article using SetParent
Experts-exchange question about embedding a java app in a win32 app.
I don't believe this is possible, at least not using SetParent. To quote from the SetParent documentation:
An application can use the SetParent
function to set the parent window of a
pop-up, overlapped, or child window.
The new parent window and the child
window must belong to the same
application.
I don't think what you want is easily done, but it could be an option to try to integrate one of the open-source PDF-viewers (if you're prepared to go GPL as that is probably the license on most of them). Some links:
epdfview
xpdf
evince
okular
I need to understand the differences between windows main/mdi/child/dialogs.... how win32 messages should be propagated... why some messages are present in one type and not other...
There is reference information available here on the MSDN website. If you want more of an introduction or tutorial, then Charles Petzold's book Programming Windows is excellent.
Main window
The application's top window. It is flagged as the process main window and this information can be readily accessed by calling processes with the appropriate permission.
MDI (Multiple document interface) window
This is, typically, in an application main window and it contains a set of MDI Children. This is mostly a window class integrated with Win32 API. I believe it's not treated differently by the operating system as any other window class. Those are becoming extinct in favor of multiple SDI windows (Word 2007).
Child
This is a child window of any other window. Its position, visibility and mostly everything is dependent on the parent window. The children send notifications to their parents. A notification is a specific kind of window message.
Dialog
Dialogs provides easy child creation and input handling based on what 95% of dialogs need. Dialog functions in the API let you create a window and its children using compiled templates in the PE file (.exe). The message handling is also slightly different since you are working mostly with notifications from children.
The main difference with dialogs is when you are using a modal one. The creation call will block until the user closes the dialog. This can make UI updating a little tricky in some situations.
Im not a windows developer, but heres what I understand:
main window - toplevel container which you can active/see in the taskbar.
dialog - little box locking (if modal) your window, not seeable in the taskbar. Mostly used to display message to the user.
mdi (Multiple Document Interface) - Not directly a window but more a simple container for storing child windows. Each child window can be maximized/minimized/closed inside this container, but you wont find any of these in the taskbar.
http://en.wikipedia.org/wiki/Multiple_document_interface