# C++ Message Loop in DLL

## Recommended Posts

Hi Guys, Please excuse my ignorance again.. I'm developing a custom control for one of my collegues which consists of a basic DirectX scene. The DirectX part is written in native C++ and compiled as a DLL, I'm also producing a Visual Basic wrapper so that my collegues can use the control within their .NET application. The constructor passes the 'handle' of a custom 'control' to the C++ code which uses it to draw the DirectX stuff. I'd like to have a message loop in the DLL so that I can respond to mouse clicks and drags without having to rely on the Visual Basic wrapper to deal with them. I've tried to make this sound as simple as possible but I'm having trouble understanding it myself. Many thanks in advance, Stefan :)

##### Share on other sites
Evil Steve    2017
What part are you having trouble with?

The message pump is process-wide, and when you call GetMessage or PeekMessage, you're reading messages for the processes message queue. If you want to handle particular messages for a control, then a message loop in the DLL sounds like it'll be a pain - your best bet would be subclassing the control to handle input.

##### Share on other sites
I'm still a little confused here. Im having trouble assigning a WndProc to a HWND that's passed to my dll in a constructor. I'm sure I'm just being hungover...

##### Share on other sites
Evil Steve    2017
Quote:
 Original post by Stefan SkrobanskiI'm still a little confused here. Im having trouble assigning a WndProc to a HWND that's passed to my dll in a constructor. I'm sure I'm just being hungover...
I'm not sure about VB, but in C++, it's done by calling SetWindowLongPtr with the GWLP_WNDPROC parameter to set a new window proc for the window. SetWindowLongPtr returns the old window proc, which you need to keep a hold of.

In your new window proc, you do whatever handling you want, and instead of calling DefWindowProc, you instead call CallWindowProc, passing in the address of the old window proc. That has the effect of having default behaviour for messages.

##### Share on other sites
Promethium    580
Given a HWND you can replace the WndProc by calling SetWindowLongPtr with GWLP_WNDPROC as parameter. But remember that you replace the "real" WndProc with your own, so you want to extract that with GetWindowLongPtr first, store it somewhere, and then call it in the end of your custom WndProc with CallWindowProc.

It works fine, I did it in a project to capture mouse and keyboard input from a user provided window.

##### Share on other sites
Ahh right that makes perfect sense. Cheers guys

Just to add clarity for other readers. The VB part is just a wrapper for the C++ stuff designed for my collegues who are using .NET to develope their app, it just calls on various functions in the C++ code. To keep it simple for them I'm dealing with mouse clicks and drags in the C++ and just require the 'handle' of a .NET control to act as the HWND.

##### Share on other sites
JohnnyCode    1046
Quote:
 Original post by Stefan SkrobanskiI'm developing a custom control for one of my collegues which consists of a basic DirectX scene.

Well I gues then that this control owns a window. You can assign an explicit message procedure to window like
WNDCLASS wc;wc.lpfnWndProc = (WNDPROC) MyWndProc;

and have a definition of procedure like
LRESULT CALLBACK MyWndProc(	HWND hWnd,UINT	uMsg,WPARAM	wParam,	LPARAM	lParam){	switch (uMsg)				 	{	case WM_ACTIVATE:        break;       }}

the procedure should be defined as a global function, not a control class member.

##### Share on other sites
NukeMantis    100
Will this work for what I'm doing, putting a DirectX DLL in the code that handles the CompositionTarget.Render event from a WPF Image object that has a d3dImage as the source? I'm getting NC_CREATE and NC_DESTROY (and one other message, don't remember what it is) in my DLL but no mouse events...