I love every time I get the opportunity to promote 599cd, the product line, and this very forum. Excellent does not begin to give justice to what comes out of here. Thank you Richard for this magnificent creation.
And thank you to Alex. We have conversed several times via this forum, and you have no idea how much help you have been to me.
And finally, the nature of all the tutorials and seminars, along with the forum, lays the foundation for designers/developers, at any level of expertise. Lessons learned here prepare students to think through Access problems so each one of us has the flexibility to make Access most fit our individual needs. Thank you 599cd.
So to business. My DB has many name field throughout the database. A pet peeve of mine is people who fail to follow the most basic grammar rules. Everyone knows that  bob smith  or  BOB SMITH  is supposed to be  Bob Smith . (Don t judge me  hahaha!)
There are several paths to get there, but respecting brevity of code, I went on the search for an event when users  move from 1 control to another (can t do it).  The form infrastructure does not have an event for moving from control to control.
I found this class module:
http://stackoverflow.com/questions/10655262/active-control-change-event-ms-access
When the form loads, this creates a collection of specific controls by type, and looks for specific events in in the control to run a custom event that converts the contents of the field to vbProperCase. (I know I could write code for each control that is affected in this. It would be around 300 lines of code that are basically doing the same event.) I have learned that that simple approach comes with Gremlins. It makes all the code harder to follow, slower to run, and absolutely miserable to troubleshoot. Whoever said less is more couldn t be more on-target respecting the authoring of code. The work I have done cuts out over 200 lines of code.
But it left some challenges to work through. In its original form, the code would execute when you would click on the specific control. Now Ive already gone through this much work, making the end-user click on the field would be counter-productive to what I wanted to accomplish. Seemed to me that if the event fired on the control afterupdate, I would incorporate automation and consistency to the fields. Sounds reasonable, right?
No, not right! Infact WRONG, WRONG, WRONG. If I would put  bob  then [ENTER] in the first name field, the control would update to  Bob , then after update would run again. And to credit Richard in the Web Sync seminar for this piece of knowledge - it created a perpetual loop. So it would change to vbpropercase then after update would run again (it doesn t seem to matter that it changed it to the exact same thing) .until pigs fly.
At the bottom of the module, it would get rid of the custom event. The event that did the cleaning is called Class_Terminate. Class_Terminate will run principally when the focus goes out of scope of the collection in this case. Its job is to clean up the collections, and free the memory allocated to the collections.
I noticed a few nights ago I noticed that after Class_Terminate would finish the VBA code would go back to running before the crash occurred. This really threw me off. (But I can now explain that too).
The Class Module adds reference to the custom event and the custom event is fired in the after_update event of all controls in the collection. Class_Terminate gets rid of the reference and the collection. In effect, it is trying to perform an event on a control in a collection that has already been broken up. The collection doesn t exist, so Access knows what it is supposed to do, but has no idea where  to do it.
Because it is in the midst of a perpetual loop, it goes back to the same missing collection until it crashes.
Finally, I tried error trapping. I am not 100% sure why I could not trap an error through this until I realized, there is no code to step through to find the crash. If I understand it correctly, Class_Module will only make a reference to the Subroutine, not hard-write the code into the control event. It sees that the focus moved from 1 control to another, so it looks for the proper control type, and other qualifiers. If this control exists within the collection, then the code goes back to the custom script, but is unable to run it because the collection, ergo the reference to the control within the collection does not exist.
I will be experimenting with other events or ways around this problem and keep you all up to date.
I apologize for the long-windedness, but I am pretty gratified to figure this one out, I owe it to all of you who have helped me learn Access over the past several years, and although self-serving; I gotta admit, this is a pretty technical problem to work through and I wanted to share it with all of you as well.

---

Reply from Alex Hedley:

Thanks for the kind words Scott.

Have you seen my video? MS Access - Check for Empty/Null Controls
I can't seem to find the corresponding blog post or Tip entry on the site, need to update that!