Should DoCmd.CancelEvent inside an Exit event procedure cancel ensuing events?

[MLH]

I have a form, frmUSPSReturnReceipts, with a control named
NotExpectingGreenTickets. The control's Exit event procedure
follows:

Private Sub NotExpectingGreenTickets_Exit(Cancel As Integer)
If IsNull(Me!NotExpectingGreenTickets) Then
DoCmd.CancelEvent
Exit Sub
End If
End Sub

I slipped in a MsgBox statement that ensures me DoCmd.CancelEvent
runs. I thought cancelling this event meant exactly that the Exit
event would, in fact, be canceled. It doesn't seem logical that other
events normally occurring after an Exit event. But they do. Is that
what was intended? If so, what exactly is the point of canceling an
event. The Exit Sub statement prevents further code in the procedure
from running. I thought CancelEvent was supposed to do something
more.

[Allen Browne]

What happens if you replace:
DoCmd.CancelEvent
with:
Cancel = True

If that doesn't work, what other events are you talking about that still
fire? I would not expect the GotFocus of the next control to fire if Exit
was cancelled, but other events (such as those of the Form) might still
fire.

--
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.

"MLH" <CR**@NorthState.netwrote in message
news:6k********************************@4ax.com...

>I have a form, frmUSPSReturnReceipts, with a control named
NotExpectingGreenTickets. The control's Exit event procedure
follows:

Private Sub NotExpectingGreenTickets_Exit(Cancel As Integer)
If IsNull(Me!NotExpectingGreenTickets) Then
DoCmd.CancelEvent
Exit Sub
End If
End Sub

I slipped in a MsgBox statement that ensures me DoCmd.CancelEvent
runs. I thought cancelling this event meant exactly that the Exit
event would, in fact, be canceled. It doesn't seem logical that other
events normally occurring after an Exit event. But they do. Is that
what was intended? If so, what exactly is the point of canceling an
event. The Exit Sub statement prevents further code in the procedure
from running. I thought CancelEvent was supposed to do something
more.

[MLH]

Responses embedded...

On Mon, 22 Jan 2007 12:31:03 +0900, "Allen Browne"
<Al*********@SeeSig.Invalidwrote:

>What happens if you replace:
DoCmd.CancelEvent
with:
Cancel = True

Pretty much the same thing happens. I get confirmation msg that
the Exit event was canceled. Then the LostFocus event for same
control fires anyway.

>
If that doesn't work, what other events are you talking about that still
fire?

LostFocus event for the same control

>I would not expect the GotFocus of the next control to fire if Exit
was cancelled, but other events (such as those of the Form) might still
fire.

[Lyle Fairfield]

MLH <CR**@NorthState.netwrote in news:q2a9r2drujkriqboqd9fkhucg6588o7t28@
4ax.com:

Responses embedded...

On Mon, 22 Jan 2007 12:31:03 +0900, "Allen Browne"
<Al*********@SeeSig.Invalidwrote:

>>What happens if you replace:
DoCmd.CancelEvent
with:
Cancel = True

Pretty much the same thing happens. I get confirmation msg that
the Exit event was canceled. Then the LostFocus event for same
control fires anyway.

>>
If that doesn't work, what other events are you talking about that still
fire?

LostFocus event for the same control

>>I would not expect the GotFocus of the next control to fire if Exit
was cancelled, but other events (such as those of the Form) might still
fire.

The exit event occurs only when the focus moves from the control to another
control on the same form. The lostFocus event occurs when the control loses
the focus for whatever reason.

So, perhaps the exit event doesn't occur in the cases when the lost focus
event fires but "shouldn't". You could tell by putting a temporary MsgBox
into your Exit Event Code.

Does the exit sub serve any purpose?

Have you considered removing the code and setting the required property of
the underlying field to true? Then Access will handle everything for you.

[Allen Browne]

Okay, that's not intuitive, is it.

Access does indeed fire the LostFocus event of the control, even if the Exit
event if cancelled, but only the first time you try to get out of the
control. If it's already been cancelled previously, LostFocus doesn't fire
again.

Seems like it's been like that for quite some time. Access 97 has that
behavior, and 2007 is the same.

While it's not really what you expect, it should not be an insurmountable
problem. At worst, you would need to create a module-level variable. If you
cancel the Exit, set your variable to True. Check it in LostFocus, and take
no action of the module-level boolean is true. Don't forget to reset it in
LostFocus.

--
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.

"MLH" <CR**@NorthState.netwrote in message
news:q2********************************@4ax.com...

Responses embedded...

On Mon, 22 Jan 2007 12:31:03 +0900, "Allen Browne"
<Al*********@SeeSig.Invalidwrote:

>>What happens if you replace:
DoCmd.CancelEvent
with:
Cancel = True

Pretty much the same thing happens. I get confirmation msg that
the Exit event was canceled. Then the LostFocus event for same
control fires anyway.

>>
If that doesn't work, what other events are you talking about that still
fire?

LostFocus event for the same control

>>I would not expect the GotFocus of the next control to fire if Exit
was cancelled, but other events (such as those of the Form) might still
fire.

[MLH]

Yep. That sounds like a plan. Many thx for the work-a-round.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Mon, 22 Jan 2007 21:40:20 +0900, "Allen Browne"
<Al*********@SeeSig.Invalidwrote:

>Okay, that's not intuitive, is it.

Access does indeed fire the LostFocus event of the control, even if the Exit
event if cancelled, but only the first time you try to get out of the
control. If it's already been cancelled previously, LostFocus doesn't fire
again.

Seems like it's been like that for quite some time. Access 97 has that
behavior, and 2007 is the same.

While it's not really what you expect, it should not be an insurmountable
problem. At worst, you would need to create a module-level variable. If you
cancel the Exit, set your variable to True. Check it in LostFocus, and take
no action of the module-level boolean is true. Don't forget to reset it in
LostFocus.

[MLH]

Good suggestion on the Required property. The control is an unbound
combo box. Perhaps setting its ValidationRule property to Not Null or
something along those lines will mirror your intended effect.

<snip>

>
The exit event occurs only when the focus moves from the control to another
control on the same form. The lostFocus event occurs when the control loses
the focus for whatever reason.

So, perhaps the exit event doesn't occur in the cases when the lost focus
event fires but "shouldn't". You could tell by putting a temporary MsgBox
into your Exit Event Code.

I checked that possibility, embedding a MsgBox alert in there. For
certain, the Exit event is firing.

>
Does the exit sub serve any purpose?

Not really. I was grasping at straws there.

>
Have you considered removing the code and setting the required property of
the underlying field to true? Then Access will handle everything for you.