Okay, tell me then how can you setup a bound form to allow
a user to click on a command button without first
triggering the data validation checks in the previous
control?
Normally, you do want data validation checks to take
place, but there are few minor exceptions to the rule as
it depends on what the command button is setup to do. In
order for me to be able to set this up, I had to first,
setup something that would act much like the
CausesValidation Property and the Validate Event that VB6
has. That means, I had to use the Exit Event to setup the
control that's to be validated and setup the Enter Event
for the control(s) of when you want validation to take
place. For those minor few instances that you wouldn't
want the validation check to take place, you simply don't
setup the Enter Event for that purpose. The third thing I
had to do, I had to use the Public statement to have the
control validation code in place, which then use a
centralized code to execute the validation checks. I used
the CallByName function within the centralized code to
execute the specific control's validation check. If this
check passed, the focus would remain at the control that
had recieved the focus from the previous control that just
checked, and if it failed, it would return the focus to
the previous control (the control that was just checked).
Maybe a clearer picture
Control A has focus
User enters info into Control A
As Focus leaves Control A, code gets the necessary
information to be able to run the validation check on it
provided the Exit Event is setup. Note, there is no
actual validation taking place at this point of time.
Control B's Enter Event triggers, and if it's setup to
validate previous control, which acts much like the
CausesValidation Property in VB6, the Centralized
Validation Check command is triggered.
Centralized command get Control A's name, then uses the
CallByName function to trigger it's Validate code provided
that code is setup. All Validate codes are setup as
functions so as they can return either true or false. If
there is no macro by the name it's expecting, it will
assume that it passed anyhow. If the centralized Validate
gets a true or no macro response, then control B keeps
it's focus, but if the centralized Validate code gets a
false response, the focus is returned to Control A with a
message on the form stating why (which is done within the
control's Validate code).
Given that's how my code works for validation purposes,
and if I recall correctly, Access's error checking and
updating the field (and potentially the record, if it's
the last field of the record) is done between the
BeforeUpdate and AfterUpdate events on the control when
it's on a bound form. For that reason along with what I
had to do to get around the issue (making the forms more
user friendly for mouse users as otherwise, in the few
minor instances, it will only give them headaches), that's
why bound forms don't work for me.
Summary:
All events of the previous control are triggered before
the Enter Event on the next control is even triggered.
For Keyboard users, this could be handled via the KeyDown,
KeyPress, and KeyUp events, but for mouse users, the only
thing that would be getting the mouse event is the control
they click on, but if the previous control cancels the
updating/exiting, the control that the mouse was clicked
on, it's Enter event will not get triggered cause it won't
have the chance to get the focus. In most cases, this is
fine, but for those controls that deals with such actions
that you don't want the same validation checks to take
place on the control that's losing it's focus, like either
resetting the form or backing out of the form, this is
where bound forms fails.
Hope this gives you why I stated as I did. Maybe, just
maybe, I require higher standards on both sides (user
friendly and data validation) than other developers. A
lot of this comes from the fact I have been on the other
side of the data entry in the past, including the fast
pace required working as a Data Transcriber at the IRS
(minimal speed for ALPHA-NUMERIC, 7000 keystrokes per hour
which involves a lot of switching back and forth between
the qwerty keyboard and the numpad). Some things I liked
how it was done, other things, I didn't. As time went
along and my computer skills continued to develop on my
own, since I had done it as a hobby prior to it becoming
professionally, I got into validating data, creating and
running reports from that data. Now I'm in the position
to look at how we are entering the information, what can
we do to improve on the quality of that data while at the
same time, making it more user friendly without the system
taking too much time.
Ronald R. Dodge, Jr.
Production Statistician
Master MOUS 2000
