Regarding your last request, Pat, in the case where I did this, I had a belt AND suspenders, so besides the LostFocus actions I ALSO had BeforeUpdate events for the form. So no, bad data wouldn't get saved anyway because you couldn't close the form while it still held unsaved data. You had to SAVE it with valid data or CANCEL the entry before you could close the form. In fact, the available control buttons were dynamic. You weren't given the CLOSE button unless it COULD be closed, and the other "default" close and navigate items were also controlled. As I recall, SAVE and CLOSE could never appear at the same time. The navigation buttons (NEXT and PREVIOUS) were also not visible when CLOSE was not visible, so no one could use a navigation side-effect to save invalid data. And yes, NEXT and PREVIOUS were dynamic and one or the other would be off if you were at first or last record for the table.
I distributed some of the actions to individual controls because of the way I was controlling color as an indicator of good or bad data and because of other reasons. My issue was that with the complexity of the forms - about 30 major ones, all of the validation COULD have gone into a single routine per form, but by splitting out the individual control actions I had smaller - and thus easier to visually verify and debug - action and validation routines. YES, I could have combined them. But for ease of maintenance - and ease of checking the code - I kept them separate. It would have been entirely too easy to lose track of the snippet of code doing the validation for an obscure control when (for a couple of cases) we had 30+ fields to be maintained - mostly for government record-keeping. If the validation was in the individual control events, it was easy to find in Design mode by following the control's .GotFocus and .LostFocus events.
One of the things that happened is that every control had both a GOTFOCUS routine and a LOSTFOCUS routine because I had a dedicated "Help" panel that was maintained by those two events. The GotFocus routine put up a help message specific to that field - which appeared differently when in focus - and the LostFocus routine erased that help as it returned the control to the "not in focus" appearance as modified by the "valid" vs. "invalid" condition. In fact, because of selective role-based locking, record state-based locking, and other considerations, I had something like seven to ten possible states for bound controls, that included different appearance for "focus/not focus" situations, "locked by role", "record closed (completed)", and a special color for new records showing fields "not yet filled in for the first time." Since I used templating, that wasn't that hard to do and - believe it or not - the color coding was well received. Besides which, I had a common color control routine that did the state testing and control coloring in a single call.
Remember, Pat - while I understand a lot of set theory and other types of programming theory, I'm a pragmatist and I was going with what worked in a shop where not every user was a programmer or engineer. The clerks who had to use it needed all the visual cues they could get and I didn't mind providing that. They thanked me for what probably sounds to you like a crazy jumble of code. But I found it easy to debug and manage. The users said they found it easy to use. The boss liked it because he didn't get a lot of complaints. The government managers got their reports in a timely manner. And the IT security people were satisfied that I was locking down things against improper operation. So step back a little, Pat, and allow for different viewpoints caused by different conditions. You know that every shop is the same and every shop is different. Vive le difference!