FiveTech Software tech support forums

To All

I have tried to search the forum on how to turn off the ESC key .. just can not seem to find it ( in english ).

I want to be able to set the ESC key off for my application globally.

Thanks
Rick Lipkin
SC Dept of Health, USA

Rick,

If you want to disable it for dialogboxes, then the easiest way is to modify the Class TDialog:

Search for VK_ESCAPE and comment out the calls to ::End()

Rick,

>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.

James

James

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..

Just my 2 cents there ..
Rick

Rick,

>if you hit the ESC key and do not select OK or Cancel...

Is your listbox on a dialog? If so, can't you just code it so the Esc key and Cancel button do the same thing?
James

James

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


//----------------------
Func MTRPGET( cNAME, cMODE, oOBJ, oRs, cTABLE )

LOCAL oDLG,oLBX
LOCAL oBTN1,oBTN2,oBTN3
LOCAL oRsMTP, oErr, cSQL

IF cNAME = "ALL" .and. cMODE = 'R'
RETURN(.T.)
ENDIF

IF EMPTY( oOBJ )
oOBJ := " "
ENDIF

IF cMODE = "E"
DO CASE
CASE cTABLE = "AGENCY"
IF cNAME = oRs:Fields("MOTORPOOL"):Value .and.;
oRs:Fields("MOTORPOOL"):Value <> SPACE(LEN(oRs:Fields("MOTORPOOL"):Value))
RETURN(.T.)
ENDIF
CASE cTABLE = "VEHICLES"
IF cNAME = oRs:Fields("MOTORPOOL"):Value .and.;
oRs:Fields("MOTORPOOL"):Value <> SPACE(LEN(oRs:Fields("MOTORPOOL"):Value))
RETURN(.T.)
ENDIF
CASE cTABLE = "MPOOLOC"
IF cNAME = oRs:Fields("mtrpool"):Value .and.;
oRs:Fields("mtrpool"):Value <> SPACE(LEN(oRs:Fields("mtrpool"):Value))
RETURN(.T.)
ENDIF
ENDCASE
ENDIF

oRsMTP:= TOleAuto():New( "ADODB.Recordset" )
oRsMTP:CursorType := 1 // opendkeyset
oRsMTP:CursorLocation := 3 // local cache
oRsMTP:LockType := 3 // lockoportunistic

cSQL := "SELECT * FROM MTRPOOL where AGENEID = '"+xAGENEID+"' order by AGENCY,MTRPOOL"

TRY
oRsMTP:Open( cSQL,'Provider='+xPROVIDER+';Data Source='+xSOURCE+';Initial Catalog='+xCATALOG+';User Id='+xUSERID+';Password='+xPASSWORD )
CATCH oErr
MsgInfo( "Error in Opening MTRPOOL table" )
RETURN(.F.)
END TRY

IF EMPTY( cNAME )
cNAME := "BOGUS"
ENDIF

cNAME := UPPER(ALLTRIM(cNAME))

IF .not. oRsMTP:eof
oRsMTP:MoveFirst()
ENDIF

oRsMTP:Find( "MTRPOOL LIKE '"+cNAME+"%'" )

IF oRsMTP:eof
oRsMTP:MoveFirst()
ENDIF


DEFINE DIALOG oDlg RESOURCE "MTRPSLCT" ;
COLOR "W+/W" ;
TITLE "Motorpool Select" ;

REDEFINE LISTBOX oLBX FIELDS ;
oRsMTP:Fields("MTRPOOL"):Value ;
HEADERS "Motorpool" ;
SIZES 100 ;
ID 111 of oDlg ;
UPDATE

REDEFINE BUTTON oBTN2 ID 113 ;
ACTION ( zPOOLID := oRsMTP:Fields("poolid"):Value, ;
zMTRPOOL := oRsMTP:Fields("MTRPOOL"):Value, ;
oOBJ:Refresh(), ;
oDlg:END() )

REDEFINE BUTTON oBTN2 ID 112 ;
ACTION ( oDlg:END() )

REDEFINE BUTTON oBTN3 ID 114 // ;
* ACTION ( _Mtrpview("A"), ; // mtrpview.prg
* oLBX:ReFresh() )

oLbx:bLogicLen := { || oRsMTP:RecordCount }
oLbx:bGoTop := { || oRsMTP:MoveFirst() }
oLbx:bGoBottom := { || oRsMTP:MoveLast() }
oLbx:bSkip := { | nSkip | Skipper( oRsMTP, nSkip ) }
oLbx:cAlias := "ARRAY"

ACTIVATE DIALOG oDlg ;
ON INIT ( if( (xSUPER = 'Y' .or. xADMIN = 'Y' ), ,oBtn3:Hide() ) )

oRsMTP:CLose()
SysReFresh()

RETURN( .T. )

//-------------------------------
STATIC FUNCTION SKIPPER( oRsx, nSkip )

LOCAL nRec := oRsx:AbsolutePosition

oRsx:Move( nSkip )

IF oRsx:EOF; oRsx:MoveLast(); ENDIF
IF oRsx:BOF; oRsx:MoveFirst(); ENDIF

RETURN( oRsx:AbsolutePosition - nRec )

// end mtrpslct.prg

Rick,

>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.

If you still need help, let me know.

James

Rick,

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.

James

James

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 ..

Let me think about this some ..

Rick

Rick,

>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?

James

James

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 ..

I will let you know

Thanks
Rick