Missing expected properties

[The_Doc_Man]

Yes, the temporary table is the way I'll have to go here.

I'm going to build a formal structure during Form_Open based on scanning the controls and populating an array of control data for any control that could ever gain focus (and therefore become user-modified). I'll scan the array at Form_Current to load the new values using each control's default values - i.e. Don't qualify it at all. Just use the name of the control to get whatever it thinks it wants to tell me. Like, x = CStr(Me.Controls("Controlname")) - and maybe encapsulate that Me.Controls reference inside an NZ(x, "<null>") call. Then I can just take whatever it gives me. After that, I can use a LostFocus routine to test the results and enforce the color changes and all the other things I wanted to do.

Doing it that way, I'll be able to pass the form's structure as an argument in my generalized subroutines that will do things like the common color-change stuff and set-up for any auditing that might need to be done. Otherwise, I'd have to repeat all sorts of code and data declarations for every form's class module. Trust me, not my idea of a good time. Doing it as a declared complex data type, I know that every time I use it I will spell everything correctly.

 

[The_Doc_Man]

In final follow-up to this, the "behind-the-scenes" array was a performance nightmare. I took the other suggested path, a SELECT CASE based on the control type. I still have traps for any cases that could bomb on a control lacking a particular property, but at least sanity has been restored.

I ended up with two routines to do the dynamic color changes I wanted to do. One set of routines used for GetFocus/LostFocus "knows" that the control I just named as a parameter is BOUND (because I won't call that routine for unbound controls.) The other set of routines I built does the same sort of thing but with external holders for those few unbound items. And the Get/Lost Focus code there knows to not check.

I hate the result, but now that the code is written, at least I can expect more consistent behavior. And it all stems from the fact that Access is only "mostly" object oriented, so property inheritance is very hard to trace.