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).
Architect of the SmartComponent Library and WinKit
Is this documented? It's not yet part of the Help.
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.
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?
Well, we are in 11.6.2.008 and seeing the issue. Is possible overridden ProcessCmdKey is not supported?
You received this notification because you subscribed to the forum. To unsubscribe from only this thread,
post as spam/abuse.
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:TabApplied:Publish(THIS-OBJECT, NEW System.EventArgs(), "TAB").
RETURN TRUE. /* processed */
RETURN SUPER:ProcessCmdKey(msg, keyData).
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.
DO ON ERROR UNDO MAIN-BLOCK, LEAVE MAIN-BLOCK ON END-KEY UNDO MAIN-BLOCK, LEAVE MAIN-BLOCK:
IF NOT THIS-PROCEDURE:PERSISTENT THEN WAIT-FOR CLOSE OF THIS-PROCEDURE.
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.