Had to mull the topic for a bit, as I see myself arguing conflicting POV and actions
YMMV is right on target: "architecture" has personal preference, politics and quasireligous problems

>>Recursing to call a method OTOH might include activeX controls as well
>
>Specially on fonts the AX thingies require special handling - sometimes you need to insert an .object reference, and most of the time they have a .font property set, so it's not oObj.FontBold, it may be oObj.object.font.bold so YMMV, there's no general rule. And that's exactly the reason why setAll() may not work on them, so calling your own code recursively on the whole form is the safer way to go. And, mind you, not on form.init(), that may be too early, but perhaps on .show(), or even .activate(), when all the objects which were added later are, hopefully, in existence.

Since late first decade I try to fit my mindset to the project and its main dev -
had a stint before where partial redesign was needed and ran too often into human inertia.

My main rules for embedded stuff like activeX are:
try to find a way without (after replacing DTPicker with pure vfp often job is done)
code chunky, not chatty when marshalling thread or process border
aim for KISS as mental debugging is sometimes hampered by thinking in wrong environment

Personally coded on the activeX side first (slow machines back then)
Maintainance grew more difficult, esp with dev fluctuation.

Nowadays I prefer to wrap each component and code in container or custom wrapper
Although rule 2 might lead to minimal chunky methods (example: setting all font attributes)
=setallfont(cFontname, nSize, lBold, lItalic, lUnderline, lStrikeout, cListControls)
implemented in language natural to the activeX control
Then code to the interface or inside isolated wrapper code.
But get a feel for the mindset "common around the project" in advance

>>Sometimes I had special invisible control as "focus anchor" for prog visual alter(c)ations
>
>The invisible control is something you must have if you have toolbar buttons, because they never get focus (never tried with a textbox or combo on toolbar, hmmm...). Alternately, in any .save() method, buttoned or not, shift focus to this invisible control, save, return to previous control.
>
>But no, the focus is not on this listbox, and it wasn't added afterwards or any such funny business. That listbox has code only in its requery() and doubleclick() - it's for navigation to related records. Why would it not react to the setall() is beyond me, i.e. not my problem at all and I'm not interested in investigation of it.

I try to stay away from actual GUI code - fwk code much better for my nerves