>>>
>>>This is, as Lutz and Walter already warned, more difficult to integrate. At this points, I assume it will force rewriting our base classes and probably create Visible_assign events for the controls.
>>
>>I'm not sure which way around, but one _ASSIGN or _ACCESS code fires on expected places. (IE ACCESS fires on ASSIGN or the opposite)
>>Check this, because this is all boring slow FoxCode that runs.
>>I would rather Eventbind to (each) CREATE~ or NEWOBJECT. This rarely fires. Newly created object is on top of ZORDER (iow, the last on Objects collection), so you can handle this directly after creation.
>
>I believe that the most common scenario will be that the added object's dimensional and positional properties will be set only after the object is created and added, but before it becomes visible. Catching the moment it becomes visible will probably get the properties already in place.
>
>On the other hand, these properties may be set relative to other objects in the container that, at the time the object is added, may already have been scaled. A finer control may be required for these situations, certainly...

Depends on your new control. If this is something that will run after form's init (or: in) then after CREATOBJECT (NEW~) is perfect.
I think, it just depends how and when your DPI-aware-code normaly runs. The next close place.
For some objects visible is switched heavy
Simple question is how and who scales the added object. If this is something that belongs to the container, to the app, to the form?