Hanging .Net wait-for with escape?

Posted by Stefan Drissen on 30-Jun-2016 07:14

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?

All Replies

Posted by Mike Fechner on 30-Jun-2016 09:32

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.

Posted by Stefan Drissen on 30-Jun-2016 10:18

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:

  • it reacts to the mouse
  • it reacts to pressing ALT and then single characters
  • it does /not/ react to the combination ALT+single character

There is a pstimer throwing out events every 10 ms (for polling tab control) - but disabling it does not help.

Posted by Mike Fechner on 30-Jun-2016 12:16

My point is, you should not allow any construct that re-runs the Application:Run() a second time at all.

Posted by Stefan Drissen on 12-Aug-2016 00:44
This thread is closed