Followup Question: Null Value in field

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

iam@notarealisp.com - 22 Dec 2004 19:25 GMT

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?

Reply to this Message

Rick B - 22 Dec 2004 19:43 GMT

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
>
[quoted text clipped - 14 lines]
>
> Why?

Reply to this Message

Rick B - 22 Dec 2004 19:49 GMT

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.
[quoted text clipped - 23 lines]
> >
> > Why?

Reply to this Message

iam@notarealisp.com - 22 Dec 2004 22:29 GMT

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

Reply to this Message

Tim Ferguson - 23 Dec 2004 18:28 GMT

> 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

Reply to this Message

iam@notarealisp.com - 23 Dec 2004 20:21 GMT

>> 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
[quoted text clipped - 14 lines]
>
>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.

Reply to this Message

John Vinson - 23 Dec 2004 22:58 GMT

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

Reply to this Message

Tim Ferguson - 24 Dec 2004 08:35 GMT

> 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

Reply to this Message

Immanuel Sibero - 22 Dec 2004 19:46 GMT

Hi

Try adding:
Cancel = True
after the MsgBox

HTH,
Immanuel Sibero

> Ok, I put the following code in the OnExit
>
[quoted text clipped - 14 lines]
>
> Why?

Reply to this Message

John Vinson - 22 Dec 2004 19:51 GMT

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

Reply to this Message