Followup Question: Null Value in field

[iam]

Ok, I put the following code in the OnExit

Private Sub RecipeName_Exit(Cancel As Integer)
If IsNull(Me![RecipeName]) Then
MsgBox "Please enter a Recipe Name."
RecipeName.SetFocus
End If
End Sub



It is bringing up the Msg Box just fine whether I hit enter or tab on
a the blank field.

BUT

It is NOT then giving focus back to the field so the user can enter a
piece of data. It's moving focus to the next field in the tab order.

Why?

 

[Rick B]

as posted yesterday to a question, the event you code happens BEFORE the
exit event.

You must include a Cancel=True command to cause the exit event to halt.

Hope that helps,

MERRY CHRISTMAS!!!

 

[Rick B]

You could replace your SetFocus line with the cancel line

as posted yesterday to a question, the event you code happens BEFORE the
exit event.

You must include a Cancel=True command to cause the exit event to halt.

Hope that helps,

MERRY CHRISTMAS!!!

Ok, I put the following code in the OnExit

Private Sub RecipeName_Exit(Cancel As Integer)
If IsNull(Me![RecipeName]) Then
MsgBox "Please enter a Recipe Name."
RecipeName.SetFocus
End If
End Sub



It is bringing up the Msg Box just fine whether I hit enter or tab on
a the blank field.

BUT

It is NOT then giving focus back to the field so the user can enter a
piece of data. It's moving focus to the next field in the tab order.

Why?

 

[John Vinson]

It is NOT then giving focus back to the field so the user can enter a
piece of data. It's moving focus to the next field in the tab order.

Why?

Because the Exit event fires after you have *exited* the control, and
moved to the next one.

Use the BeforeUpdate event instead, and set Cancel to true if the user
has left the control blank. You'll want to put similar code in the
Form's BeforeUpdate event as well (just to cover the case that the
user might be using the mouse rather than the keyboard and never
selects the textbox at all).

John W. Vinson[MVP]

 

[Immanuel Sibero]

Hi

Try adding:
Cancel = True
after the MsgBox

HTH,
Immanuel Sibero

 

[iam]

Ok, I modified the following code in the OnExit
to read.....

Private Sub RecipeName_Exit(Cancel As Integer)
If IsNull(Me![RecipeName]) Then
MsgBox "Please enter a Recipe Name."
Cancel=True
RecipeName.SetFocus
End If
End Sub


I will go read some more to find out why I have to do the Cancel
of the whole process in order for the setFocus to do it's thing
properly. To me it's a bit redundant to have to cancel something that
is processing to do another command.

That's why I don't program for a living. This stuff just doesn't come
naturally to me.

Also, for the person who was concerned about someone mousing past the
field, I understand the concern, but I force the focus to this field
in the FORM On Load command.

You folks have taught me good things in many ways. Your help is always
appreciated.

Merry Christmas!!!!

 

[Tim Ferguson]

I will go read some more to find out why I have to do the Cancel
of the whole process in order for the setFocus to do it's thing
properly. To me it's a bit redundant to have to cancel something that
is processing to do another command.

In the order of events, the Exit happens before the control has lost the
focus. Your subroutine sets the focus to the RecipeName control (which is
where it still is) and then finishes. It is not until then that Access
moves the focus to the next control, and your .SetFocus method is long
history by then.

Setting the Cancel flag tells Access not to carry out the rest of the
things it's meant to be doing (like moving the focus) and that is exactly
what you want. Far from redundant, it's vital!

Hope that makes sense.


Tim F

 

[iam]

(e-mail address removed) wrote in

In the order of events, the Exit happens before the control has lost the
focus. Your subroutine sets the focus to the RecipeName control (which is
where it still is) and then finishes. It is not until then that Access
moves the focus to the next control, and your .SetFocus method is long
history by then.

Setting the Cancel flag tells Access not to carry out the rest of the
things it's meant to be doing (like moving the focus) and that is exactly
what you want. Far from redundant, it's vital!

Hope that makes sense.


Tim F

YOU should be writing computer manuals and books if you aren't
already. While I am very good at some things in the computer world
coding has never been one of them because when trying to find answers
in help files or books they always seem to be programmer oriented
instead of explanatory.

IE:

I should be able to:

a> Check for the Null
b> Display the MSG box if the condition exists
and Kick the user backwards without having to CANCEL anything.


Oh well, some day Artificial Intelligence will make this whole process
obsolete.

Probably not in my lifetime though.

 

[John Vinson]

Oh well, some day Artificial Intelligence will make this whole process
obsolete.

I'm reminded of a cartoon (from thirty or so years ago): two
scientists looking at a computer monitor, and one saying "Well, it
figures, I guess; if there's artificial intelligence, there was bound
to be artificial stupidity!"

<g, d & r>

John W. Vinson[MVP]

 

[Tim Ferguson]

a> Check for the Null
b> Display the MSG box if the condition exists
and Kick the user backwards without having to CANCEL anything.

Sorry if you don't like the language that Microsoft uses, but setting
Cancel=True _is_ kicking the user backwards. Think of it this way: what you
are cancelling is the user's request to move to a different control.

If you still don't like it, there is no rule to say the formal parameter
has to be called Cancel:

Private Sub RecipeName_Exit( KickUserBackwards As Integer)

Is IsNull(RecipeName) Then
'....
KickUserBackwards = True
End If

End Sub

Does that make you feel better? If you still don't like even this approach,
and you have an emotional attachment to the SetFocus method, then you'll
just have to use the LostFocus event, which takes place after the focus has
left your RecipeName control and will therefore have a visible effect.

Hope that helps


Tim F