Stop a carriage return to cause Command Button to be activated

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

magicdds - 03 Apr 2008 02:49 GMT

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

Reply to this Message

Allen Browne - 03 Apr 2008 03:10 GMT

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.

Signature

Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

>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
[quoted text clipped - 22 lines]
> Thanks for any ideas.
> Mark

Reply to this Message

magicdds - 03 Apr 2008 05:24 GMT

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?

> Suggestions:
>
[quoted text clipped - 34 lines]
> > Thanks for any ideas.
> > Mark

Reply to this Message

Allen Browne - 03 Apr 2008 07:04 GMT

Was it the first one?

Signature

Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

> Thanks for trying, but:
>
[quoted text clipped - 48 lines]
>> > the
>> > ON CLICK occurs with an ON CLICK and not on a CARRIAGE RETURN?

Reply to this Message

magicdds - 03 Apr 2008 14:10 GMT

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.

> Was it the first one?
>
[quoted text clipped - 50 lines]
> >> > the
> >> > ON CLICK occurs with an ON CLICK and not on a CARRIAGE RETURN?

Reply to this Message

Allen Browne - 03 Apr 2008 14:57 GMT

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

Signature

Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

> 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
[quoted text clipped - 64 lines]
>> >> > the
>> >> > ON CLICK occurs with an ON CLICK and not on a CARRIAGE RETURN?

Reply to this Message

Dirk Goldgar - 04 Apr 2008 03:42 GMT

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.

Signature

Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)

Reply to this Message

magicdds - 10 Apr 2008 05:56 GMT

That did the trick

Thanks Dirk.

> >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
[quoted text clipped - 47 lines]
>
> That should be all you need to do to suppress the unwanted behavior.

Reply to this Message

magicdds - 11 Apr 2008 12:51 GMT

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

Reply to this Message

Dirk Goldgar - 11 Apr 2008 15:09 GMT

> Dirk,
>
[quoted text clipped - 3 lines]
> 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.

Signature

Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)

Reply to this Message