Jason,
Let me preface by saying this is mostly conjecture on my part because I am not privy to the actual C code used to create VFP. That said:

Actually it does have everything to do with the now obvious difference in how VFP treats objects and forms. What you described is the normal course of events we have all grown to know as instantiation sequence. You explained it very well.

However, there is a marked difference in how VFP treats forms called by the DO FORM construct. For the sake of a simple example, let's say we have a form with pageframe with two pages and one textbox on Page 1.

The normal sequence would be Form.Load - Textbox1.Init - Page1.Init - Pageframe1.Init - Form.Init. During this sequence, THISFORM is available but THISFORM.Pageframe1 is not, THISFORM.Pageframe1.Page1 is not, etc. because they have not set initialized yet. The memory has been allocated and the objects exist as memory constructs but they have not been assigned to the appropriate property of THISFORM yet. You know they have been created because you can access them using the THIS.Parent, THIS.Parent.Parent references where THIS is the Textbox. Parent object references are assigned at the beginning of the Init process for child objects. Parent objects get the appropriate properties assigned object references to the child objects at the end of the Init.

Now the difference. DO FORM must process things different in that when the memory allocation and object contructs are first created, they are assigned to the Parent objects child property (or added to the appropriate collection). So instead of waiting for the end of the Init, it adds one step at the beginning to not only assign the Parent property, but assign the Child as well.

This was rather intersting to ponder. Two distinctly different approaches to object creation. It may have to do with the fact that forms in the guise of screens existed well before classes in VFP/FoxPro. Or it may be that Joe programmer at MS thought it would be cool to do it this way and since it didn't affect the big picture (form instantiation and overall form functionality), it was ignored.

>>Dear David,
>>
>>I do not use the data environmnent and my controls are not bound to any controlsource. My problem is that any command in the INIT method that reference "thisform.pageframe.page1.textcontrol.value" would cause an error. When I take a look in the Debugger the object can only be evaluted up to the "thisform.pageframe" level and beyond this it seems that it is not initialised yet. Strange since the INIT method is called from the "textcontrol". BTW the control that I have is a text box that itself is a subclassed. Could this be the problem?. Thanks.
>>
>
>>>>I have form that has a pageframe and this works fine if i call it via the "Do FORM". Since I have save this form as a Class. I get error in the INIT method of object inside the pageframe complaining that the pages object does not exists. Can someone help me here? Thanks.
>
>What you're seeing has nothing to do with classes and subclasses and everything to do with order of instantiation. INIT() occurs from the inside out. That is to say, even though the page.Init() has been triggered, it does not complete until *all* of the objects on that page finish their Init(). IMO, it happens counter-intuitively, and that's why it's confusing at first... sort of like saying I can have a glass of water without the glass... but it makes sense in the OOP world.
>
>What, exactly, are you trying to accomplish?