And how does this help if the user
Doesn't enter the Combobox at all
or
Enters the combobox but doesn't select a value, merely Yabs to the next
control?
Remember, the user asked WHAT event (before, or after update) of the combo
box to use. I think is VERY clear that the before update event is the clear
winner. We were only given two choices by the user.
Of course I assume that most people here will also assume that in addition
to the above testing of the controls, there has to be some code that
eventually writes out, or uses this data (and tests that data before hand).
However we do want to give the user warning at the time when he uses the
combo box, but we WILL STILL need additional code if the control(s) NEVER
receive the focus.
Thus, I am of course assuming that the user Obviously realizes that
additional code at update time (or examine time) will be required. In fact I
don't know of any access developer that assumes that you can just use any
event on a control to verify the final data before writing out. We've never
EVER had that ability anyway. You either use data engine integrity or you
put in your own special code that test things and use your own custom
messages.
Furthermore we don't know if the users actually updating data, and with the
given information given we actually can NOT make that assumption.
The only thing we have at this point in time is which of the two events to
use, and clearly in my humble opinion of the before update event is the
correct event to use. We *could* use lost focus, but then again, why? We are
back to square one if the control NEVER receives the focus!!!
So, in addition to using the before update event, if the control never
receives the focus, and the control is never modified, then I have to assume
that most people here have concluded that additional code WILL be needed
when the data needs to be used.
So perhaps I'm assuming too much here. Perhaps the obvious conclusion that
additional checking code will be needed at update, or at the time when the
data used perhaps was too much of an obvious conclusion on my part (but in
effect we've always had to do it that way).
So, yes....if I was coding this, I would use
1) the before update event of the control
and,
2) Additionally I would also have code at update (or examine time) that
tests the data. (so, fair question on your part).
Of course the person could use the lost focus event, but as we mentioned if
the control never gets the focus, then we still need the code at
update/examine time. Furthermore the lost focus event does not have a cancel
event, and I know that experienced developers will instinctively and
naturally look to the before update event for the controls validation code.
There might be a VERY small UI advantage to using the lost focus event, I
think this advantage does not out weigh the fact that every developer is by
natural instinct to look and find the verification code for that control in
the before udpate event. That's where verification code traditionally goes.
The above approach is pretty much par for the course, and a lot of my forms
do have the testing code in the before update event of a contorl, and ALSO
that of the form's before update event (or this case an unbound form, when
the data is to be used).
Why not use the standard and longtime and long established method of testing
for controls by using the built in cancel feature? About the only downside
is there are cases when the user might tab through the control and not enter
anything. However, perhaps they WANT to do that, and perhaps they're going
to tab BACK into the other control when they get the appropriate information
for that control.
So, my approach gives the user freedom to move around anywhere in the form
in any direction, and enter data in THEIR order. At the end of the day we
STILL have to test the code at use/update time anyway.
I think it's a reasonable user interface to let users move around at will,
and not nag them unless they actually change the control value.
And I think it's a reasonable programming approach to put verification code
where 99% of developers will expect the verification code to be placed....
Your mileage and thoughts may vary and your view may be different on this
issue...this is not the "only" way to approach this...
