This is probably not the approach you want to take. Normally this kind of "render my engine into a HWND" technique accomplishes input handling by having the other HWND's process (the C# application in this case) send the relevant events back to your engine process via some kind of backchannel, such as a socket connection. It's generally an easier-to-deal-with technique.
That said, if you're set on monitoring the events directly, look into
SetWindowsHookEx. That function allows you to inject a hook function that is called with before (
WH_CALLWNDPROC) or after (
WH_CALLWNDPROCRET) they have been processed by the target windows
WNDPROC. You need to give the function a hook type (one of the two previous constants) and a hook function, which must look like:
LRESULT CALLBACK HookFunction(int code, WPARAM wparam, LPARAM lparam);
Your hook function will be called with the appropriate window message and parameters as given in the hook function signature. Be aware that your placement of the hook before or after the target window procedure impacts how you must handle the resulting messages, as the window may or may not have done things to reflect state differently based on whatever its own
WNDPROC wants to do. You also may not be permitted to take action when your hook is called (if the code is negative, you must immediately invoke and return the value of
Also, you'll need to put your hook code into shared memory since you're not hooking something in your own thread, and you'll need to be aware of the bitness (32 or 64) of both processes, because they have to match.
Overall it can be a bit tricky to deal with. There are some good posts on StackOverflow about using
SetWindowsHookEx in various ways, such as this one dealing with the shared memory issue.
Since you control all the code involved here (as I understand it), I think you should avoid the trouble of
SetWindowsHookEx and go with a socket-based approach. Alternatively you can create a control in the C++/CLI interop layer that talks directly to your engine code and manually pumps events for it using a variant of an
Application.Idle event listener. That may require some rejiggering of how your engine's core loop is coupled to
SDL_PollEvents though, so it's hard to say for sure how much work is involved without seeing more of your code.