How can I stop F10 from activating the window menu?

*+The problem is that programs in our GUI application use F10 to jump to

certain fields (user-defined) on the screen, but now when our users are

focused in the Progress GUI window and press F10, the cursor jumps up to the

.NET menu.+*

We can change the Progress code to use F11 instead of F10, but this means re-

training hundreds of users.  Is there any way to keep the old behavior?

>

This partly answers your question ... using the .NET menu strip, you can do something like the following

- add a KeyDown event handler to the Form

- within that you can add code along the lines of

     if Progress.Util.EnumHelper:AreEqual(e:KeyCode,    System.Windows.Forms.Keys:F10) then
     do:
         assign e:Handled = true
                e:SuppressKeyPress = true.
     end.

Using the UltraToolbarsManager, it's a tad more complex, and you go into the world of Windows messages, which is a dark and gnarly place :).

Firstly, make your form create a class that implements the System.Windows.Forms.IMessageFilter interface. This will require a method called PreFilterMessage. (OE Architect can help you add this via the context menu)

Now add some code to catch the F10.

CLASS EffTenFilter implements System.Windows.Forms.IMessageFilter:
     METHOD PUBLIC LOGICAL PreFilterMessage( INPUT-OUTPUT m AS System.Windows.Forms.Message ):
        def var iParam as int.
        iParam = m:WParam:ToInt32().
        case iParam:
            when 121 then
                do:
                    MESSAGE 
                    'pressed f10'
                    VIEW-AS ALERT-BOX.
                    return true.
                end.
            otherwise return false.
        end case.
     END METHOD.
END CLASS.

And lastly,  you need to tell .NET to actually use that filter. So when launching the GUI for .NET window, you'll need to do something along the lines of

         def var oFilter as IMessageFilter.
     def var o as MyAppForm.
     o = new MyAppForm ().
     /* this is the important part */
        oFilter = new EffTenFilter().
     System.Windows.Forms.Application:AddMessageFilter(oFilter).
     wait-for System.Windows.Forms.Application:Run(o)
     /* don't forget to clean up! */
     System.Windows.Forms.Application:RemoveMessageFilter(oFilter).

I've not tried this from a WindowContainer or other embedded form/container.

(There's a fair amount of this kind of info available on the Web (either on the Infragistics forums or other, more generalized programming and also C# or .NET forums. It takes a bit of practice to translate the .NET code - and I highly recommend starting with C#, since it's relatively close to the ABL to make more translation easy - but after a while, it becomes relatively simple.)

Update: Reading the MSDN docs a little more, it seems that you can implement the IMessageFilter completely indepdently of the Form. So I've updated this answer with that info.

Hth,

-- peter

(OE Architect can help you add this via the context menu)

Oh man, If I'd be working for PSC, I wouldn't remind anybody of this function!

It's a shame, that for a company in the business of database applications - where sorting is a basic functionality - this dialog is neither able to sort base class names and their overridable methods by alphabet. Even worse, the random order changes every time you open the dialog. Usually the dialog is a waste of time.

Cut & paste of method headers from the class browser is much more efficient when working with hybrid classes

Peter, thank you for this detailed, quick, and helpful response.  This got us out of a tight spot and we're distributing it to clients as I type this.  Much appreciated!

Update: This works beautifully, except that the lower case "y" doesn't work - nothing happens when you type it into any input field.  We can trap it like F10, but IMessageFilter can't distinguish between "y" and "Y", so we can't even handle it with something like 'apply "y"'.

Also, we tried "subscribe", but it would only work in the .NET form only, but not in any of the embedded Progress Windows.  We tried making our own class inheriting from Progress.Windows.WindowContainer and putting the subscribe in there, but that had no apparent effect.

The users will have to learn to use F11 ...

Weirdly, the code I was using to try out my earlier reply catches lower-case y as F10 for some reason.

Other thoughts, can you catch the 'y' and 'Y' with a KeyUp or KeyDown event? If you look at the System.Windows.Forms.KeyEventArgs class in the Class Browser in OEA of at http://msdn.microsoft.com/en-us/library/system.windows.forms.keyeventargs.aspx . Looking quickly at that, you can catch SHIFT-Y easily enough, but not sure about (capslock) Y.

Also, there are new pub/sub mechanisms for OO (which apply to the Gui for .NET too).

-- peter