>I want to be able to set the ESC key off for my application globally.
I wonder why? This is a standard way to cancel whatever you are doing. As a user, I would be quite frustrated by the Esc key being disabled. Users always want some way to either undo or cancel whatever they are doing. Not allowing this is going to force them to cheat--and this is often going to pollute the database with bogus data.
In all my listbox look up code .. I return values from a data row and populate a form .. I can enter a value in a get .. then the valid starts the listbox of values .. if you hit the ESC key and do not select OK or Cancel .. the origional get value remaines and is saved to the form table .. not desirable in a SQL environment when I need to save the primary key as well as the value of the row picked.
Granted .. this is a small and rare occurence but I would just as soon disable ESC all together..
The list box is a listbox within a dialog that is activated from a Valid on a get. I think the ESC behavior is more a function of the Valid than the listbox .. however, I would like to 'trap' the ESC key press within the listbox and force the 'cancel' route .. here is a typical code snipit ..
REDEFINE GET oMTRPOOL VAR zMTRPOOL ID 135 of oGRPS PICTURE "@!" ; when ( xSUPER = 'Y' .or. xADMIN = 'Y'.or. xMGR = 'Y' .or. xTECH = 'Y' ); valid MTRPGET( zMTRPOOL, cMODE, oMTRPOOL, oRsVEH, "VEHICLES", zPOOLID ) UPDATE // mtrpslct.prg
>I would like to 'trap' the ESC key press within the listbox and force the 'cancel' route .. here is a typical code snipit ..
You do it just the way I showed in my sample code. It appears that it will work fine in your code. The trick is to create a flag var (I used lOK). Initiaize it to .f. then set it to .t. only when the OK button is pressed. Then after the ACTIVATE DIALOG... code you process both the Cancel button and the Esc key if the flag is false.
I looked at your code some more and now I am not sure what problem you are having. It appears that you have a dialog with a listbox and three buttons, one of which is Cancel. I assume this is the Cancel button:
REDEFINE BUTTON oBTN2 ID 112 ; ACTION ( oDlg:END() )
If so, I don't see any difference between this and the Escape key. Both just end the dialog. Only the OK key is processing data. In your first message you stated:
>if you hit the ESC key and do not select OK or Cancel .. the origional get value remaines and is saved to the form table.
I don't understand how this can be happening since the MTRPGET() function always returns .t. (at least once you get to the dialog part of the function). So, it doesn't seem like it would make any difference whether you used the Esc key or pressed a button.
Lets say you entered the word BOGUS in the get .. and hit enter .. the valid fires and since there was no match .. the listbox gots to the top .. if the user presses ESC .. there is nothing returned because ( as you see ) .. OK only returns values thru that conduit.
When the lisbox closes .. you are still left with the word BOGUS in the get and if the user does not pay attention .. that field will be saved with the wrong associated key ..
I guess I could pass space(len( field )) back if the OK button was not pressed and trap the blank field in the business rules .. never really thought this thru .. I have hundreds of these 'clone' listbox look ups ..
>Lets say you entered the word BOGUS in the get .. and hit enter .. the valid fires and since there was no match .. the listbox gots to the top .. if the user presses ESC .. there is nothing returned because ( as you see ) .. OK only returns values thru that conduit.
Yes, that makes sense. However, the word BOGUS should still exist in the GET when you press the Cancel button also. Does it not?
YES .. the cancel buton leaves the origional input in the get which is the same behavoir as ESC ..
I can see that I need to re-work the end of my list box look ups and force a blank back to re-set the get and deal with the blank on the post form business rules ..
Glad you made me think this thru .. been using the same code for years .. never really caued me much trouble until I started fiddling with it ..