Yep, getting it to work properly with continuous sub forms took several days of hair pulling.

And even more code if you want to provide feedback to the user of what they've done in a form.
Golden rod color means active control, ready for entry
Green means editing in place, not modified (but this record was copied from another, so it's new)
Blue means entry that validated.

How do I pick all these crazy colors?
They are all in a table, easy to change by the FE user.
However, I pick bright colors for the core modules of the ADS, and let users choose more subdued ones for their applications.

Richard mentioned this site in one of his (hundreds of) videos:
https://htmlcolorcodes.com/color-picker/

If the form is active, I use the "opposite" color of the footer for the header based on the color wheel.
I'm not color adept, so I have to trust the site.

Sorry for stepping on your toes Kevin, but you bring up some timely topics.
And ones I need to revisit after a few years of newer ADS development, just to refresh the memory.
:)

A heads up. Kevin's solution uses a module variable DefaultColor. If you have two forms open at the same time, and switch between them, Access will corrupt the variable between the different calls. This is because Microsoft failed to properly instance a procedure's variables when reusing. It can happen with any modular or static variable.

I just opened 2 Forms and switched between them and it worked fine. Then I opened 3 Forms and switched between all 3 and it still worked fine.

Kevin Try changing the "default" color for each form. Then see what happens. I doubt Microsoft has changed anything in the past two years, but who knows. I'll try my old test that identified this problem later today.

On one form I have filter fields that are a light shade of grey. On another form the default is white. My Notes field is yellow. They all return to the correct color with no problems.

Hmmm, it's probably working because you _LostFocus when you shifted to another form. I'm guessing if you put the forms side by side, and you move to another form, the control color will shift back and forth as you move between the forms.

If the code was a bit more complicated (more than just _Got/LostFocus) you would find that the second form that calls the global procedures would overwrite the variables. That's what my old test did. Based on the example you gave, I retract my heads-up for your OP, but I'll test later if the claim is correct for calling a procedure a second time while the first isn't yet finished. Now that I think about it, my problem was probably exacerbated by DoEvents (buried in a pause procedure) which allows the second form to continue without the first finishing its procedure. See, these are good examples to refresh the memory.