OpenEdge 11.6 x64 (but also with 11.4 x64)
Recently, to be able to easily start .Net windows we replaced our main classic ABL wait-for with a .Net wait-for, so our main loop now looks like:
wait-block: REPEAT ON STOP UNDO, RETRY ON QUIT UNDO, LEAVE wait-block ON ENDKEY UNDO, RETRY ON ERROR UNDO, RETRY : WAIT-FOR System.Windows.Forms.Application:Run(). END. /* wait-block */
This has led to some peculiar not nicely reproducible behavior. When starting a program from our main menu and banging the escape key, sometimes the session hangs. The hang is curious, in that the classic menu widgets still respond (ie menus can be expanded and collapsed) but nothing happens. Attempting to close the main window using the window icon also does nothing. The entire session is frozen, but the menu widgets are still responding. When pressing CTRL+BREAK all activity resumes back to normal.
When launching from PDSOE and pausing the frozen session with the debugger shows that the AVM is on the WAIT-FOR line.
I found some ProKB articles on freezes when using the .Net wait-for when using 11.6.1 - but our problem is on 11.4 and 11.6 and it all works fine unless the escape key is hammered....
Any pointers?
I don't think you can re-run the Application:Run() - but that's what's happening because of the ON ENDKEY, RETRY handling instruction.
Thanks for the pointer Mike, unfortunately no dice.
I've removed the endkey and added a retry block with message. It does not help.
I've removed the entire wait-block and added a sanity message before the :Run() . It does not help.
I have searched the code base, this is the only :Run().
So I am pretty sure that I can rule out Run() being executed more than once.
When the wait-block is still in place, CTRL+BREAK triggers on stop resulting in a retry resulting in :Run() being executed again and restoring everything back to normal.
Another interesting observation on the active menu when in frozen state:
There is a pstimer throwing out events every 10 ms (for polling tab control) - but disabling it does not help.
My point is, you should not allow any construct that re-runs the Application:Run() a second time at all.
And the answer is: