Colleagues,
here's the trap I (ungracefully) have fallen into:
LASTKEY() function, when called in the CommandButton.Click event procedure returns ASCII code 27 (Esc) if the button's Cancel property set to True!
In my case it was User Name and Password entry screen, with two labels, two text boxes, and one command button. I set cmdOK.Cancel to True, thinking that user might have been allowed to access some of the reports which are not password-protected. If that was the case, then user might just slap Esc key, and program will proceed and show the unprotected reports, while making the protected ones hidden from this user.
Imagine my amazement when one of the customers called and said that if he enters name and password and hits Enter - he can see the reports' list, but if he clicks on OK button - he can't see nothin'! (There was only one report, and it was password-protected).
Turned out - and it took me more than hour in debug mode - that LASTKEY() in the cmdOK.Click procedure returns 27 (Esc) instead of 151 (Mouse_Click)!
Here's the code snippet from frmPW.cmdOK.Click procedure:
The workaround was obvious: I turned off button's Cancel property, turned on form's KeyPreview property, and moved the code (with obvious modification) into frmPW.KeyPress procedure. After that everything worked as I wanted.
I also found that there's special class, CancelButton, put in by Microsoft. When you set Cancel property to True, your normal CommandButton turns into that Cancel button. But why it also issues code 27 as last key pressed on mouse_click event - that's beyond my comprehension.
Just thought you should be aware of such trap "by MS design".
Thanks!
Regards,
Ilya
here's the trap I (ungracefully) have fallen into:
LASTKEY() function, when called in the CommandButton.Click event procedure returns ASCII code 27 (Esc) if the button's Cancel property set to True!
In my case it was User Name and Password entry screen, with two labels, two text boxes, and one command button. I set cmdOK.Cancel to True, thinking that user might have been allowed to access some of the reports which are not password-protected. If that was the case, then user might just slap Esc key, and program will proceed and show the unprotected reports, while making the protected ones hidden from this user.
Imagine my amazement when one of the customers called and said that if he enters name and password and hits Enter - he can see the reports' list, but if he clicks on OK button - he can't see nothin'! (There was only one report, and it was password-protected).
Turned out - and it took me more than hour in debug mode - that LASTKEY() in the cmdOK.Click procedure returns 27 (Esc) instead of 151 (Mouse_Click)!
Here's the code snippet from frmPW.cmdOK.Click procedure:
Code:
IF LASTKEY() = 27 && Esc was hit
gcPW = ""
gcUser = ""
glGenPW = .F.
RELEASE THISFORM
RETURN TO Main
ENDIF (LASTKEY() = 27 && Esc was hit)I also found that there's special class, CancelButton, put in by Microsoft. When you set Cancel property to True, your normal CommandButton turns into that Cancel button. But why it also issues code 27 as last key pressed on mouse_click event - that's beyond my comprehension.
Just thought you should be aware of such trap "by MS design".
Thanks!
Regards,
Ilya
