Access Key Firing on Disabled Control - Bug?

[DrJavaJoe]

If you disabled a command button in the validate event of a textbox and then try to click on that command button from the textbox, the command button's click event will not fire because the validate event fired first disabling the button. But if instead of clicking you use the command button's access key you'll notice that the button still becomes disabled but this time fires the click event.

Here is some code to demonstrate.

Option Explicit

Private Sub Form_Load()
Command1.Caption = "&Command1"
Text1.TabIndex = 0
End Sub
Private Sub Command1_Click()
MsgBox "Command1 Clicked"
End Sub
Private Sub Text1_Validate(Cancel As Boolean)
'Bad data so disable command1
Command1.Enabled = False
MsgBox "Command1 is now disabled."
End Sub


Two strings walk into a bar. The first string says to the bartender: 'Bartender, I'll have a beer. u.5n$x5t?*&4ru!2[sACC~ErJ'. The second string says: 'Pardon my friend, he isn't NULL terminated'.

 

[mattKnight]

Not a bug as I see it, but correct operation...
To see what I mean add a checkbox to the above form check1 and add the following code

Option Explicit

Private Sub Form_Load()
    Command1.Caption = "&Command1"
    Text1.TabIndex = 0
End Sub
Private Sub Command1_Click()
    MsgBox "Command1 Clicked"
End Sub
Private Sub Text1_Validate(Cancel As Boolean)
    'Bad data so disable command1
    Command1.Enabled = False
    MsgBox "Command1 is now disabled."
[COLOR=red]Cancel = cbool(check1,value)[/color]
End Sub

As you set & clear the check box, the behaviour will alter (with check checked, no click event fires, if cleared, clickevent fires)

Take Care

Matt
If at first you don't succeed, skydiving is not for you.

 

[mattKnight]

oops
Check1.Value obviously...

Take Care

Matt
If at first you don't succeed, skydiving is not for you.

 

[mattKnight]

Arrgh,

don't forget to set Check1.CausesValidation to No..

Take Care

Matt
If at first you don't succeed, skydiving is not for you.

 

[DrJavaJoe]

I do understand your point but in my situation I did not want Cancel = True. This textbox's value is valid but due to it's change, the value of another field changes to an invalid value requiring further input from the user and thus disabling the command button. So after making changes to this textbox the user decides to either click the command button or hit ALT C, but did not realize that this change affected another field which in turn disables the command button, preventing them from clicking it. So they try to click the command button and nothing happens because it becomes disabled but if they use the Access key it becomes disabled but still fires the command button's click event. This is not the behavior that I expected.


Two strings walk into a bar. The first string says to the bartender: 'Bartender, I'll have a beer. u.5n$x5t?*&4ru!2[sACC~ErJ'. The second string says: 'Pardon my friend, he isn't NULL terminated'.

 

[BobRodes]

<This is not the behavior that I expected.

I can see why. Intuitively, one would expect Alt-C to duplicate the behavior of clicking on the Command button. I'll bet it has to do with something like keyboard interrupts taking precedence over mouse interrupts. As I'm sure you know, there are any number of ways to work around this, but it's at the very least counterintuitive.

So, maybe it's not a bug, but it's hard for me to support the idea that it's a correct operation, too, apologies to Mr. Matt.

Bob