>>You can even do better: addobject() each singular control via timer at intervals of 0.1s - the singular control is fast enough so app still is responsive. Stop timer if page not fully loaded is accessed and load that, resume timer...
>
>Very interesting. It would be hard to control the appearance, no?

Nope. This was done with pages of a pgf, and only to those currently not visible. Pages have .completed property, if accessed when .completed is .f., action described in 2. sentence goes to work. See: nothing to see ;-)

Another scenario I used "background processing" in vfp was a "customer view" of all insurance contracts held for that customer, which were shown in more detail after pressing a dynamically generated link for those types of contracts customer held. Old style FPW code for that was really performant, reusing fwk for ported resulted in huge slowdown to precalculate, esp. in version built by customer in-house, which "optimized" precalculated everything down to callable forms by calculating each form anew on each call to cut down on "first visible time".

First optim approach here was to cache once calculated forms - still slower by a factor of 3-5 compared to FPW on first call. Those screens were then cached in a .aLinkForm, making subsequent recalls of already built faster than typical FPW "rechecks", which positioned via xBase code again where those forms worked on private DS with lots of cursors selected into.

Then I added the background processing (splitting larger forms into load batches, each Cursor a single step) and was able to build the "uncreated" forms in background - had a special mode flagging the color of .completed vs. !.completed links. Those were ALWAYS faster than old FPW code, if in demo I was certain to always enter forms I was certain were already .completed - acknowledging the fact that "perhaps single forms not precalculated might add slight bump on first call"...

Learned the basics of processing in "human background time" back in DOS days - ModulaII already had background tasks similar to the time-slicing done in 16-bit WinDoze and was up to that task.

>One thing I've always thought we missed in OOP, is dynamic composition. If I have a textbox class and a container holding a textbox, they start at the same genetic level. If I subclass this into my framework, the textbox and the container are at the right level, but the contained textbox is not.

I am a big believer in having knowledge of dynamic composition - as long as that is not considered the main approach.

IMO contained textbox most of the time should know its role - input of text, numerics, pwd, perhaps money or dates. Relying there on dynamics might lead you straight into XAML interpreting variables or Spring configuration woes. Execeptions might be validation screens somewhere between MsgBox and hand-coded subform.

Making most if not all container inheritance dynamic is IMO as big a fallacy as depending only on inheritance, esp. if inheritance is not shallow or results in god classes. I prefer truly dynamic composition in a controller/actor(facade) pattern, where actor classes are loaded into specific roles (defined via .oRoleproperty) from property strings .cRoleproperty - "function blocks" easy to name and grok.

Then controller makes basic template calls over standardized / interfaced methods of actors to allow easy specialisation. Example: RPC calls via different protocols (SFTP, xRPC, SOAP, REST) to differing services (DataSchema, DataLoad, DataFormat, DataParse) using different verification (cert, pwd, oAuth) following the slightly different state rules... Classes loaded as actors can also be Controllers, specializing sub-task needs.

Results in specialized objects elsewhere relying on monkeypatching like Python or Javascript allow by assigning methods into objects, first order functions or JS backpatching inheritance, but gets unwieldy if trying to do too much/too fine grained.

Important for me: Easy enough to explain just by following the screen or file logs of actions infused with class info to new devs without writing long docs ;-))