I need a loader object in a container, something that can do a bit of checking in its .init(), instantiate the bizobject and just vanish after that. VFE uses a simple label for that, and I think all Codebook frameworks do that more or less the same way. Which should have worked swimmingly... except it doesn't work anymore.

Enter memberclass. In the specific case at hand, this container contains a grid and a pageframe, both with custom defined memberobject/memberclasslibrary. Their .init()s fire first, no matter what. Here's the event sequence (with form):

.load()
.cnt.grid.customcolumn1.init()
.cnt.grid.customcolumn2.init()
.cnt.grid.customcolumn3.init()
.cnt.grid.customcolumn4.init()
.cnt.grid.customPage1.init()
.cnt.grid.customPage2.init()
.cnt.grid.customPage1.cnt1.resize() && nothing special about this container, not anyone's memberclass
.dataenvironment.init() && now this gets me - why would all these fire _before_ this?
.SixOtherObjectsOnFormInit()
.cnt.bzLoader.member.init() && finally, and too late.

And it gets this far only if I set .bindcontrols=.f., else it bangs immediately after the grid's columns have instantiated - because their controlsources expect the fields to be available, and they would be, once the bizobject is created and has all the aliases open and populated.

Except that the first object defined in a container at the class level was _always_ instantiated before any other member of the container that was added lower in the class hierarchy, or in the last instance (i.e. on a form).

So, how is this circumvented? If the advice is "don't use memberclass", too late, it's all over the place. If it's "load the bizobject _before_ instantiating the container", that means adding a whole layer of management, because the container can't fend for itself, it needs to be led by the arm... exactly the opposite from the intent of such a container (which was supposed to be something you just drop anywhere, Lego style).

How is this solved in VFE or MM? I can't believe nobody had this problem before.