Dialogs, wait-for, and methods w/ return values - Forum - OpenEdge Development - Progress Community

Dialogs, wait-for, and methods w/ return values

 Forum

Dialogs, wait-for, and methods w/ return values

  • Since it is almost 8 years, what is the status on this limitation?

  • Huh?  This has been fixed since version 11 or 10.2B using -IOEverywhere 1 (the default in 11).

  • Which release are you on?
     
    And just in case you are on historic 10.2B, on which service pack?

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • Is this documented? It's not yet part of the Help.

  • Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • Maybe I am interpreting the KB wrong, but the KB reads that in 11 and up, you specify -IOEverywhere 0 to turn it off otherwise the default is on.

  • Which is exactly what Laura wrote. -IOEverywhere 1 is the default from 11.0 on. From 10.2B02 or 10.2B03 you could use -IOEverywhere to activate the at that time undocumented fix.

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • Well, we are in 11.6.2.008 and seeing the issue. Is it possible that overridden ProcessCmdKey is not supported?

  • Can you share details about the code? And the error message?

    Sent from Nine

    Von: jquerijero <bounce-jquerijero@community.progress.com>
    Gesendet: 26.01.2017 8:23 nachm.
    An: TU.OE.Development@community.progress.com
    Betreff: RE: [Technical Users - OE Development] Dialogs, wait-for, and methods w/ return values

    Update from Progress Community
    jquerijero

    Well, we are in 11.6.2.008 and seeing the issue. Is possible overridden ProcessCmdKey is not supported?

    View online

     

    You received this notification because you subscribed to the forum.  To unsubscribe from only this thread, go here.

    Flag this post as spam/abuse.

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • My control raises an event TabApplied inside ProcessCmdKey. The handler will eventually call a .w using WAIT-FOR (dialog-box). I get the 'Encountered an input-blocking statement while executing a user-defined function or non-vloid method: 'ProcessCmdKey' that is invalid within the current runtime context.'

    Here is the method override code:

     METHOD PROTECTED OVERRIDE LOGICAL ProcessCmdKey( INPUT-OUTPUT msg AS CLASS System.Windows.Forms.Message, INPUT keyData AS CLASS System.Windows.Forms.Keys ):

       IF Progress.Util.EnumHelper:AreEqual(keyData, System.Windows.Forms.Keys:Tab)  AND

          THIS-OBJECT:ByPassTab THEN

       DO:

         THIS-OBJECT:TabApplied:Publish(THIS-OBJECT, NEW System.EventArgs(), "TAB").

         RETURN TRUE. /* processed */

       END.

       ELSE

         RETURN SUPER:ProcessCmdKey(msg, keyData).

     END METHOD.

  • We will  need more information. The code above looks fine but now we need to look at the code that does does the wait-for and the frame it is waiting on. If it's really a dialog-box, then it should work (unless there is a bug that we are not aware of).

  • This is the code inside the main-block. This will display a non-modal window. 

    MAIN-BLOCK:

    DO ON ERROR   UNDO MAIN-BLOCK, LEAVE MAIN-BLOCK
           ON END-KEY UNDO MAIN-BLOCK, LEAVE MAIN-BLOCK:

     RUN enable_UI.

     IF NOT THIS-PROCEDURE:PERSISTENT THEN
         WAIT-FOR CLOSE OF THIS-PROCEDURE.

    END.

  • Well, I completely missed the title regarding DIALOG-BOX. So non-modal window is still off limits?

  • Sorry, there is still one case that you cannot do.  That is using a new WAIT-FOR for a non-modal window when there is already a .NET form on the screen with its own WAIT-FOR and doing this when there is a non-void method or function on the procedure stack.  If that is what you're doing then you will get an error.  And as Fernando said, if it really is a dialog box then it should be allowed and you should log a bug.

    Regarding non-modal windows, we have been telling people for many years that their should only be one WAIT-FOR for all non-modal windows.  DIalog boxes will always have a new WAIT-FOR, but otherwise there should only be one.  With the introduction of .NET this became even more significant.  .NET has the same rule, but they actually enforce it!  This puts limitations on what we can allow.

  • So this means all non-modal windows can only be run as persistent from a call stack with non-void method.