Has anyone had any luck overriding the WndProc method? I can add it to the form as an override and it compiles fine, but it chokes at run-time with an unhandled exception error.
METHOD OVERRIDE PROTECTED VOID WndProc (INPUT-OUTPUT m AS System.Windows.Forms.Message):
SUPER:WndProc(INPUT-OUTPUT m).
END METHOD.
I receive the error even without the SUPER statement.
Thanks.
Whoa! that's some heavy stuff Let me know how you get on...
Will do.
All we're attempting is to take an existing Progress app, run it as a separate process, and host in a form. I already have it working to a degree, but I had to make all the api calls from the external prcess.
What I want is to use SendMessage to send information to the form (like the external window's handle) and then use WndProc to do all the work.
I have a C# example, but it uses WndProc which is throwing the error in Progress.
So you plan to integrate the Progress app into an existing .NET app? A separate .exe?
Why don't you launch the whole .NET app from within Progress?
All we're attempting is to take an existing Progress
app, run it as a separate process, and host in a
form. I already have it working to a degree, but I
Are you looking to host the entire in a form?
If you just want to host the one screen/window in a form, there's a set of classes to help you with that (Progress.Windows.WindowContainer and MDIChildForm). These basically allow you to host the client area of an OpenEdge window in a Form.
You probably know this, but you can run windows and forms in the same ABL session too - not in a hosted manner, but they're all in the same process.
-- peter
This is the entire app, as it currently exists, being hosted.
The new UI we're developing will contain a framework for running the application's functions. As it will be a fairly long process to update the entire app, we want to release it so that the user can get to the existing application directly within the framework.
Additional .NET functionality will be released in stages, but users will still have access to all functionality within the framework.
I don't really understand this. Is the whole purpose of doing this so that you can send your ABL application messages by using SendMessage? Why don't you use ABL sockets? That's what they're for - communicating between different, possibly disparate types of processes. I don't think that overriding WndProc is really a good idea!
Or am I getting this all wrong?
Laura
Hi Laura,
The initial purpose of the override is so when I run the external process from within my framework (using System.Diagnostics.Process), the external process will pass back its window handle via the SendMessage and I'll capture that using WndProc.
I thought I was going to be able to use the System.Diagnostics.Process MainWindowHandle property and do all of this without SendMessage, but it doesn't seem to return the correct handle (or it's a timing issue). Either way, I have api calls in the external progress window that allow me to parent that window into my .Net form.
The WndProc override would allow me to do it all from within the form.
Here's what I'm doing in the form:
ProProcess:StartInfo:FileName = cDlcBinPath + "prowin32.exe".
ProProcess:StartInfo:Arguments = cCommandLine.
ProProcess:StartInfo:UseShellExecute = FALSE.
ProProcess:Start().
ProProcess:Exited:SUBSCRIBE(ProProcess_Exited).
ProProcess:EnableRaisingEvents = TRUE.
ProProcess:SynchronizingObject = THIS-OBJECT.
ProProcess:WaitForInputIdle().
ProHandle = ProProcess:HANDLE.
Then the external Progress process has these api calls:
RUN GetParent(INPUT myProgressWin:hwnd,OUTPUT pHdl).
IF pHdl NE ? AND
pHdl NE 0 THEN DO:
RUN SetParent(INPUT pHdl,INPUT iTabHandle, /* PASSED IN AS A PARAMETER FROM THE FORM */ OUTPUT iRtnInt).
RUN GetWindowLongA(INPUT pHdl,INPUT -16, /* GWL_STYLE */OUTPUT iStyle).
ASSIGN iStyle = iStyle + 12582912 + /* WS_CAPTION / 8388608 + / WS_BORDER / 262144 / WS_THICKFRAME */
.
RUN SetWindowLongA(INPUT pHdl,INPUT -16, /* GWL_STYLE */ INPUT iStyle,OUTPUT iRtnInt).
RUN ShowScrollBar(INPUT pHdl,INPUT 3, /* SB_BOTH */ INPUT 0, OUTPUT iRtnInt).
RUN SetWindowPos(INPUT pHdl,INPUT 0,INPUT 0,INPUT 0,iWWidth,iWHeight,4 /SWP_NOZORDER/ + 16 /SWP_NOACTIVATE/, OUTPUT iRtnInt).
END.
It works, but I'd like something a little cleaner.
Regarding your suggestion about sockets; it's another avenue we're going to pursue. It will allow us to send much more information between the processes than the SendMessage. I haven't done much with sockets yet, but then again, I haven't done much with .NET (until now).
It's all about the learning!
Thanks,
JL