Stop a carriage return to cause Command Button to be activated

[magicdds]

I have a form with list boxes. Upon clicking choices on the list boxes, new
records are added in the subform. Each line on the subform (continuous
display) has a button (called DELETE). If the user clicks on this button, the
record on which the button resides is deleted. The purpose is in case the
user added a record in error, they have a way to delete that record. All the
fields on the subform are set as follows:
Tab Stops - no
Enabled - no
locked - yes

The DELETE Button is set as follows:
Tab Stops - no
enabled - yes
locked - no

The problem is that if the user clicks the mouse on any field in the
subform, the DELETE button becomes highlighted. If the user then hits the
CARRIAGE RETURN, the ON CLICK event procedure takes place, deleting the
current record on the subform. How do I make it so the event procedure in the
ON CLICK occurs with an ON CLICK and not on a CARRIAGE RETURN?

Thanks for any ideas.
Mark

 

[Allen Browne]

Suggestions:

1. Make sure the delete button's Default property is No.

2. Make sure the delete button is not the first one in the tab order of the
subform. In form design, Tab order is on the Arrange tab in Access 2007, or
on the View menu in previous versions.

In a main form this doesn't matter, but there are cases in a subform where
Access sets focus to the first control in the tab order, even if its TabStop
is No.

 

[magicdds]

Thanks for trying, but:

1. The default property was set to NO
2. The delete button was set to the last item in the tab order.

Does anyone have any other ideas?

 

[Allen Browne]

Was it the first one?

 

[magicdds]

No. If the user clicks anywhere on the subform, the delete button on the
record where the user happened to click, is the delete button that gets
activated when a carriage return is pressed. As such, that is the record that
gets deleted.

 

[Allen Browne]

This should not be the case, but you must have some other control in the
subform that can accept the focus.

 

[Dirk Goldgar]

I have a form with list boxes. Upon clicking choices on the list boxes, new
records are added in the subform. Each line on the subform (continuous
display) has a button (called DELETE). If the user clicks on this button,
the
record on which the button resides is deleted. The purpose is in case the
user added a record in error, they have a way to delete that record. All
the
fields on the subform are set as follows:
Tab Stops - no
Enabled - no
locked - yes

The DELETE Button is set as follows:
Tab Stops - no
enabled - yes
locked - no

The problem is that if the user clicks the mouse on any field in the
subform, the DELETE button becomes highlighted. If the user then hits the
CARRIAGE RETURN, the ON CLICK event procedure takes place, deleting the
current record on the subform. How do I make it so the event procedure in
the
ON CLICK occurs with an ON CLICK and not on a CARRIAGE RETURN?

Thanks for any ideas.
Mark

Pardon me for jumping in.

Mark, if all the other controls on the subform are disabled, as you say,
then the DELETE button is going to get the focus whenever you click anywhere
on the subform, since it's the only enabled control.

Now, the Access command button is designed to respond to the Enter key,
pressed when the button has the focus, exactly as if the button had been
clicked. The Click event fires. To suppress this built-in behavior, you
can write an event procedure for the button's KeyDown event, in which you
detect that the Enter key has been pressed, and "swallow" the keystroke so
that the button doesn't process it. Here's an example:

'----- start of example code -----
Private Sub cmdDelete_KeyDown(KeyCode As Integer, Shift As Integer)

If KeyCode = vbKeyReturn Then
KeyCode = 0
End If

End Sub
'----- end of example code -----

That should be all you need to do to suppress the unwanted behavior.

 

[magicdds]

That did the trick

Thanks Dirk.

Pardon me for jumping in.

Mark, if all the other controls on the subform are disabled, as you say,
then the DELETE button is going to get the focus whenever you click anywhere
on the subform, since it's the only enabled control.

Now, the Access command button is designed to respond to the Enter key,
pressed when the button has the focus, exactly as if the button had been
clicked. The Click event fires. To suppress this built-in behavior, you
can write an event procedure for the button's KeyDown event, in which you
detect that the Enter key has been pressed, and "swallow" the keystroke so
that the button doesn't process it. Here's an example:

'----- start of example code -----
Private Sub cmdDelete_KeyDown(KeyCode As Integer, Shift As Integer)

If KeyCode = vbKeyReturn Then
KeyCode = 0
End If

End Sub
'----- end of example code -----

That should be all you need to do to suppress the unwanted behavior.

--
Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)

 

[magicdds]

Dirk,

Is there also a way to do this:

On the mousedown property, cancel the mouse click (Or, if a certain
condition is met, swallow the mouse click so that it does not get processed)?

Thanks

 

[Dirk Goldgar]

Dirk,

Is there also a way to do this:

On the mousedown property, cancel the mouse click (Or, if a certain
condition is met, swallow the mouse click so that it does not get
processed)?

It's an interesting question, from a technical standpoint. Although the
help file says that all the events that can be cancelled have a Cancel
argument in the definitions of their event procedures, and MouseDown does
not, I find that I can in fact cancel the MouseDown event. In a test form,
I made a command button and gave it event procedures like this:

Private Sub Command0_Click()

MsgBox "Click event fired!"

End Sub

Private Sub Command0_DblClick(Cancel As Integer)

Debug.Print "DblClick"

End Sub

Private Sub Command0_MouseDown( _
Button As Integer, _
Shift As Integer, _
X As Single, Y As Single)

Debug.Print "MouseDown"
DoCmd.CancelEvent

End Sub


Private Sub Command0_MouseUp( _
Button As Integer, _
Shift As Integer, _
X As Single, Y As Single)

Debug.Print "MouseUp"
End Sub

In testing, I found that if I just clicked on the command button, the Click
event never fired. The Immediate window showed that the MouseDown event had
fired, but the MouseUp event did not. So cancelling the MouseDown event
"swallowed" both MouseUp and Click.

BUT if I *double-clicked* on the command button, then the events MouseDown,
DblClick, MouseUp, and Click all fired. So if I want to prevent the Click
event from firing, even if the user double-clicks the button, I have to
cancel the DblClick event. When I change that event procedure to this:

Private Sub Command0_DblClick(Cancel As Integer)

Debug.Print "DblClick"
Cancel = True

End Sub

.... I find that only the MouseDown and DblClick events fire.

So, to answer your question from a technical standpoint, yes: it's possible
to "swallow" the mouseclick -- or at least cancel it -- in the MouseDown
event. That's true for a command button, anyway.

From a practical standpoint, though, why would you bother to do this? Why
wouldn't you just apply whatever conditions you wanted in the button's Click
event? That seems a lot simpler, more reliable, and more natural to me.