BeforeUpdate or AfterUpdate?

[Gary Schuldt]

I have a text control in which I want all the words the user types in
capitalized (i.e., Proper case).

I know about the VBA function StrConv; not sure at the moment what the
corresponding macro is . . .

however, my question is, which event should trigger the action? It doesn't
need to be displayed in Proper case as they type, but it should be so
displayed when the control loses focus.

I have used the AfterUpdate event before, and I know it works, but I just
got to thinking that BeforeUpdate might be more efficient. I know the
latter should be used when doing validation, but I just want to change the
case.

Thanks.

Gary

 

[Dirk Goldgar]

I have a text control in which I want all the words the user types in
capitalized (i.e., Proper case).

I know about the VBA function StrConv; not sure at the moment what the
corresponding macro is . . .

however, my question is, which event should trigger the action? It
doesn't need to be displayed in Proper case as they type, but it
should be so displayed when the control loses focus.

I have used the AfterUpdate event before, and I know it works, but I
just got to thinking that BeforeUpdate might be more efficient. I
know the latter should be used when doing validation, but I just want
to change the case.

Thanks.

Gary

I'd use AfterUpdate. I don't think BeforeUpdate would be any more
efficient -- and if it were, the difference could not possibly be
significant in the context of human data entry -- so it makes sense to
me to use the BeforeUpdate event only for things that really should be
done before the control is updated. That's pretty much confined to
validation.

 

[Gary Schuldt]

Thanks, Dirk.

It seems to me, though, that capitalization is an example of "automated"
validation and could be easily considered a BeforeUpdate process.

As I understand the AfterUpdate event, it is raised after the value in the
control is copied from the Control Buffer to the Record Buffer. Wouldn't
you want to logically "fix up" a value before it was copied rather than
after?

I'm trying to become a more "intuitive" Access programmer rather than trying
to keep a bunch of rules and conventions in my poor ol' head!

Gary

 

[Dirk Goldgar]

Thanks, Dirk.

It seems to me, though, that capitalization is an example of
"automated" validation and could be easily considered a BeforeUpdate
process.

From my point of view, it's not validation, since there's no plan to
reject the data entered by the user and keep the focus in the control.

As I understand the AfterUpdate event, it is raised after the value
in the control is copied from the Control Buffer to the Record
Buffer. Wouldn't you want to logically "fix up" a value before it
was copied rather than after?

I believe you're right about the sequence of events, but it seems to me
that it makes no difference. The value is going to be (a) modified in
the control buffer, (b) copied to the record buffer, and (c) modified by
the code. Although nothing can happen until action (a) is taken, does
it really matter whether the remaining actions proceed (b), (c) or (c),
(b)?

So to me, the only significant difference between the events is whether
my code might choose to keep the focus in the control. That's why I use
the events the way I do.

I'm trying to become a more "intuitive" Access programmer rather than
trying to keep a bunch of rules and conventions in my poor ol' head!

That's good. As I said, it doesn't really matter in this case. If you
arrive at a convention that makes sense to *you*, that's to your
benefit.

 

[Gary Schuldt]

Thanks, Dirk,

I see your point about where you want the focus to be when you're done
handling that "process".

Just to play around, however, I tried moving a macro reference to upper-case
a text field from AfterUpdate (where I've always had it) to BeforeUpdate,
and I got such a long and inscrutable error message at run-time that I
quickly put it back where it was.

Lesson: Let Sleeping Dogs Lie (no matter how counter-intuitive!)

Gary

 

[Dirk Goldgar]

Thanks, Dirk,

I see your point about where you want the focus to be when you're done
handling that "process".

Just to play around, however, I tried moving a macro reference to
upper-case a text field from AfterUpdate (where I've always had it)
to BeforeUpdate, and I got such a long and inscrutable error message
at run-time that I quickly put it back where it was.

Lesson: Let Sleeping Dogs Lie (no matter how counter-intuitive!)

Huh. I'm curious as to what the message was and why you got it. It's
all very well to let sleeping dogs lie, but sometimes they wake up and
bite you anyway.

 

[Gary Schuldt]

Huh. I'm curious as to what the message was and why you got it. It's
all very well to let sleeping dogs lie, but sometimes they wake up and
bite you anyway.

OK, since you asked: the EH was a macro that used the single action
SetValue to capitalize the contents of the field using UCase.

I've been running it in the AfterUpdate event until today, when I tried it
in BeforeUpdate and got (how do I copy and paste one of these MS Access
popup error messages, anyway?):

"The macro or function set to the BeforeUpdate or ValidationRule property
for this field is preventing MS Access from saving the data in the field.
If the macro includes a SetValue action, set the macro to the AfterUpdate
property of the control instead"

or something close to that. Maybe you can explain what that REALLY means!

Gary

 

[Dirk Goldgar]

OK, since you asked: the EH was a macro that used the single action
SetValue to capitalize the contents of the field using UCase.

I've been running it in the AfterUpdate event until today, when I
tried it in BeforeUpdate and got (how do I copy and paste one of
these MS Access popup error messages, anyway?):

"The macro or function set to the BeforeUpdate or ValidationRule
property for this field is preventing MS Access from saving the data
in the field. If the macro includes a SetValue action, set the macro
to the AfterUpdate property of the control instead"

or something close to that. Maybe you can explain what that REALLY
means!

Huh! I hadn't thought that would be a problem, in all this talk about
which is the right event to use, but I see that our discussion was
pointless -- if you want to modify the value of the control after the
user has modified it, you can't do it in the BeforeUpdate event. Doing
so creates a conflict between the user-entered value Access is trying to
save and the value you've now tried to stuff in there. That's really
all that message is telling you -- "You did something in the
BeforeUpdate or ValidationRule that is keeping me from saving what was
entered. Quit it!"

 

[Gary Schuldt]

Dirk,

so, does that mean you can't EVER modify the user value programmatically in
the BeforeUpdate event? If so, then about its only utility is to issue
disciplinary messages (such as "STop that!") to the user and block them from
proceeding until THEY correct the problem.

Is that more or less how you have been using BeforeUpdate?

Gary

 

[Dirk Goldgar]

Dirk,

so, does that mean you can't EVER modify the user value
programmatically in the BeforeUpdate event? If so, then about its
only utility is to issue disciplinary messages (such as "STop that!")
to the user and block them from proceeding until THEY correct the
problem.

That's what it looks like to me. Oh, maybe there's some complicated way
around it, but it seems clear that you've described the intended purpose
of the event. Yes, you could use the event to modify *other* controls,
but then there'd be no logical reason to prefer BeforeUpdate to
AfterUpdate.

Is that more or less how you have been using BeforeUpdate?

It would be, but I don't actually use it much. I generally use
validation rules, instituted at the table level, instead. I do
form-level validation and consistency checks in the form's BeforeUpdate
event.

 

[Gary Schuldt]

OK, good discussion on those events. I should write a personal White Paper
on the subject!

Thanks again, Dirk!

Gary