WinForms is all well and good, but I've been trying to work out a solution to this issue of overriding a form control so that DGDK.NET can render into it. The problem here is that because DGDK.NET implements it's own WndProc procedure, any key messages or such are completely ignored when a window has been overidden.
As far as I can tell, when overiding windows in this manner, the Input system of DGDK.NET completely collapses. Now, this isn't the fault of tne engine since it's inherant in all native window management. Usually, if you are going to override a window, it's quite easy to do in the C++ world since you can obtain the WndProc address of the window, and call it from YOUR WndProc procedure if you don't handle the messages that are sent from the system.
Now, this becomes slightly more complicated when dealing with Managed .NET code. I've found an article on The Code Project which provides some useful code for showing how subclassing in .NET can be done.
Now, I'm going to see if this article is any good at providing a better way of Overriding the DGDK.NET application window so that it can be subclassed, but more importantly, whether it's possible to obtain DGDK.NET's WndProc address, and call it from our normal WndProc message handler of a WinForms control. If this is possible, it could well solve the oDBInput class problem for all WinForms based .NET applications.
Find the article here:
http://www.codeproject.com/vb/net/subclassnetway.asp
Paul.
"This is Big Brother, could Ian please remove his head from the oven, thank you!"
