Why doesn't A97 cancel the click event?

[MLH]

I tried the following code to prevent a checkbox from being
updated (going from a value of Null to True, from True to
False or from False to True). I was surprised it did not work.

Can anyone offer a sensible, logical, insightful reason as to
why Microsoft does not want to let programmers stop this
event?

Private Sub NoOwnerInfoChkBox_Click()
If CurrentVehicleJobID = 0 Then
DoCmd.CancelEvent
DoCmd.GoToControl "CanclBtn"
End If

End Sub

[fredg]

On Sun, 14 Aug 2005 14:05:20 -0400, MLH wrote:

I tried the following code to prevent a checkbox from being
updated (going from a value of Null to True, from True to
False or from False to True). I was surprised it did not work.

Can anyone offer a sensible, logical, insightful reason as to
why Microsoft does not want to let programmers stop this
event?

Private Sub NoOwnerInfoChkBox_Click()
If CurrentVehicleJobID = 0 Then
DoCmd.CancelEvent
DoCmd.GoToControl "CanclBtn"
End If

End Sub

Wrong event.
Code the Check Box BeforeUpdate event:

If CurrentVehicleJobID = 0 Then
Cancel = true
End If

You will be returned to the [NoOwnerInfoChkBox] control.
--
Fred
Please only reply to this newsgroup.
I do not reply to personal email.

[Tim Marshall]

MLH wrote:

Can anyone offer a sensible, logical, insightful reason as to
why Microsoft does not want to let programmers stop this
event?

Oh for the love of god, stop whinging and constantly complaining. It's
an outward sign of an inward inability to cope. And the funny part of
it is you're whinging constantly about probably the most robust of the
Access family, Access 97.

Use the f**king help file rather than constantly posting and then
answering your own posts - it's probably the best help file of any
system I've ever seen.

I work with many different trades and the old adage is true: It's a poor
craftsman who blames his failures on his tools.

The other expression which I learned maintaining and commanding armoured
fighting vehicles in the army: use the correct tool for the right job.

You seem to be continually falling into the wrong pit for both these
expressions.
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "What's UP, Dittoooooo?" - Ditto

[MLH]

Know about that one. Have used it for a decade. Do you
know why CancelEvent will cancel the update event but
not the click event? Usually, event properties that don't
appliy to an event are not listed in the event properties
window. This one, however, is - but it seems to have no
effect.

Wrong event.
Code the Check Box BeforeUpdate event:

If CurrentVehicleJobID = 0 Then
Cancel = true
End If

You will be returned to the [NoOwnerInfoChkBox] control.

[Larry Linson]

"MLH" wrote

. . . Do you know why CancelEvent
will cancel the update event but
not the click event?

No, it would only be speculation: but perhaps they thought there was no
"associated action" to cancel... if you want to leave without executing the
VBA code, it is easy to structure your VBA code to do so. On the other hand,
cancelling Before Update cancels not the BeforeUpdate event (it has already
fired) but the actual data update.

In my use of BeforeUpdate and Cancel, I have always set the Cancel argument
to True before exiting, not used .CancelEvent as you did. And, there is no
Cancel argument on the Click event.

Larry Linson
Microsoft Access MVP

[MLH]

Thx for input, Larry. What confused me on this was my understanding
that CancelEvent cancelled not only the event ordered to be cancelled,
but the entire chain of ensuing events. EG, there cannot be an
AfterUpdate event w/o an Update event which logically should not occur
if CancelEvent runs in the BeforeUpdate code. No error is returned
upon processing CancelEvent during the Click event code. So naturally,
one would assume that the Click event and all ensuing events was
cancelled. But that is not the case.

So, I thought there might be some logic behind the scenes that some
one in this group might know about. The "associated action" you
mention should be ALL ensuing events, at the very least.

No, it would only be speculation: but perhaps they thought there was no
"associated action" to cancel... if you want to leave without executing the
VBA code, it is easy to structure your VBA code to do so. On the other hand,
cancelling Before Update cancels not the BeforeUpdate event (it has already
fired) but the actual data update.

In my use of BeforeUpdate and Cancel, I have always set the Cancel argument
to True before exiting, not used .CancelEvent as you did. And, there is no
Cancel argument on the Click event.

Larry Linson
Microsoft Access MVP

[Bri]

Tim Marshall wrote:

I work with many different trades and the old adage is true: It's a poor
craftsman who blames his failures on his tools.

Heard an interesting variation on this just last week:

"Its not the arrow, its the Indian"

--
Bri

[Bob Quintal]

MLH <CR**@NorthState.net> wrote in
news:dp********************************@4ax.com:

Thx for input, Larry. What confused me on this was my
understanding that CancelEvent cancelled not only the event
ordered to be cancelled, but the entire chain of ensuing
events. EG, there cannot be an AfterUpdate event w/o an Update
event which logically should not occur if CancelEvent runs in
the BeforeUpdate code. No error is returned upon processing
CancelEvent during the Click event code. So naturally, one
would assume that the Click event and all ensuing events was
cancelled. But that is not the case.

The issue is that certain actions can be undone. Others cannot. You
cannot undo a mouse click. or tabbing into a field. You can undo
the event triggered by clicking on the checkbox, which is toggling
the state of the checkbox, the CancelEvent will only stop the code
from running, and undo any undoable changes.
--
Bob Quintal

PA is y I've altered my email address.