Object class is invalid for this container

[SimplyES]

I have a form with a 2-page pageFrame. Page2 has several pageFrames arranged across it (pgfPayments is one of the pageFrames on Page2). This has been working very well throughout development and right up until I compiled the application. When I open the form within the compiled application, it pops up the following:
Error 2005 Error is: Error loading file - record number 122. pgfPayments <or one of its members>. Parent : Object class is invalid for this container

I have tried deleting just record 122 in the .SCX for that form (followed by PACK) but, not terribly surprisingly, that results in other errors most of which are due to dependencies. Removing the elements referred to in the error msg had a similar effect, of course, and compensating for the missing elements by commenting out lines that referred to the removed elements became a major task. So, I rebuilt the removed elements (a couple of pageframes with their contents) so that the form methods had all they needed to do their tasks. I could have copied these from a backup of the form but didn't want to 'import' any lurking problems. The error remains.

My first question is, am I in error using pageFrames inside a pageframe/page? I assume not as VFP allows me to insert them and it works perfectly well when running in design mode.

I don't know if this is significant but whatever I do, however much I remove, replace, adjust etc this error always refers to record 122.

I fear I might have to start from scratch and rebuild the whole form but if someone can shine a light on this, I'd really rather not! Haven't much more hair left to pull out!

 

[Olaf Doschke]

Do you still have an unchanged copy of the file? Because just removing a record means you may render a form totally unusable even just for the form designer.
That means acting like you did is a bad idea, the error isn't saying record 122 is corrupted and deleting it won't help, especially if you delete a pageframe objects record all its inner control refer to this record and now are orphaned, so you solve one problem by getting N new. Such error messages are telling you to look into the record and change it, not remove it.

It's hard to tell what happened in the first place, but surely after doing this you can only revert to an older backup of the form. Without hands on the whole form file it's hard to tell what's wrong with record 122.

Bye, Olaf.

 

[Mike Lewis]

My first question is, am I in error using pageFrames inside a pageframe/page?

Sorry I can't offer much help, but I can answer the above question.

No, you are not in error. There is no problem in nesting pageframes. I have many forms where pageframes are nested three deep or more.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[SimplyES]

Mike: Thanks for the reassurance on that question. When you've gone round in ever increasing circles you can begin to doubt anything!

Olaf: I read somewhere (not on Tek-Tips!) the idea of removing the apparrently-offending and any others that pop up subsequently. Obviously rubbish, but I have, indeed, kept a couple of copies of the original form.
I will go through and check I haven't got a mis-applied .Parent. somewhere, but that should be picked up in design-time running anyway. Otherwise, I feear, its rebuild time.

Thanks to you both.

 

[Olaf Doschke]

I can only imagine the inner pageframe reference to its parent object got wrong in the SCX data. The fix could have been in the Parent field of Record 122.
It get's more apparent how data in an SCX is related to each other, if you query memos into c(254) fields to be able to read them all at the same time, instead of popping up a memo edit window and then skip forth and back in the browse of the scx data.

Select Left(class,254) as class,;
   Left(objname,254) as objname,;
   Left(parent,254) as parent from your.scx

The outmost pageframe should have Form1 as parent (for example) and the inner one of course the name of the page of the parent pageframe. If your inner pageframe parent for example points to the outer pageframe, that's wrong. While a pageframe can be inside another, it must be on a page of a pageframe, a pageframe itself can only have pages as its direct child objects and an inner pageframe must point to a parent page, not a parent pageframe. This only gets obvious in the scx data.

Though the form designer also lets you see pages and you can activate one of them via CTRL+Click on it, the pageframe itself is nothing without pages. In data you may have the wrong relation and that leads to a fixable error, however the data went to it's erroneous state. SCX data is not very well designed in regard of data normalisation, mainly that's due to a compromise of having everything in just one dbf and of course also compatibility. The parent relationship would better be done by an ID value rather than a parent object name. but then each page of a pageframe would also need it's own record.

As example see here:

Though Page2 has no separate record in the scx DBF, the parent relation is not to pgfParent, it must be to a valid pgfParent page.
Your problem could have arisen, when you renamed a parent pageframe page and this didn't get through to the Parent memo of child objects or when you or someone else fiddled with SCX data and changed parent to Form1.pgfParent (speaking of this example: Imagine Parent of pgfChild would be changed to Form1.pgfParent only, without specifying which page), which would of course lead to a "object class is wrong for this container" error, as pgfParent can't directly contain another pageframe.

Bye, Olaf.

PS: For sake of finding any problem, besides the Parent, the Properties Memo is of most interest, it can also contain very many errors, for example when some property is set to an expression evaluated at Load/Create time of the form. I have seen such SCX row errors reported just because a parameterized view of the DE was failing because of a non existant view parameter variable. And there was nothing wrong but that, i.e. that form ran without errors when the view parameter variable was set. No, it's most seldom advisable to just delete the row being reported, especially when it's a parent object with multiple child records depending on it, the problem cascades into mutiple problems. Your secondary 122 row error for example (as it occurred after PACK) was really about previous row 123 and that's most probably a child member of the previous row 122. So how should removing a parent object row not cause further problems? That "advice" may be meant friendly and may work in situations there is an error in a simple thing like a textbox, which has no child object rows.

 

[SimplyES]

Thanks Olaf. I had a look at that - a useful tool to add to the kit! In this case, nothing odd showed up. In order to ensure this isn't simply a case of corruption, I have completely rebuilt the form (without copying anything over from the original) - a good few hours of work, as you can imagine. And what a waste that was! The issue is still there.
As a matter of course, I don't rename pages in a pageframe (Page1, Page2 seems to me to make for easy reference) so the issue isn't there.
This form has a pageframe with two pages. On Page2 there are 7 pageframes. However, 4 of these have only one page. I decided to do this for consistency in appearance. To check that isn't the problem I removed the first single-page pageframe and replaced it with a background shape (as any other normal person would have in the first place!) and repositioned all the controls from that pageframe-page. I also 'rerouted' any refences to those controls. Running in development, this still works fine. As soon as I compile, the background shape produces the same error:

[Err: 2005 Error loading file - record number 98. shpTimeSheet<or one of its members>. Parent: Object class is invalid for this container]

Next I removed the background shape (and all its references) and recompiled. The fault has now moved on to the next single page sub-pageframe.

I am assuming this is a ParentClass problem rather than a problem with an object's Parent property. Nevertheless, I have taken the precaution of replacing any relative references in the form of Parent.Parent, making these direct (thisform.xxxx). However, no change.

The classes I use as base on this page are all unadulterated copies of the VFP originals.

I am at a loss and thus far cannot think of another way to redesign this form to work as we need it to, so, if any of this triggers inspiration, I would be delighted to hear suggestions!

 

[Olaf Doschke]

The error itself points out a wrong baseclass type, eg pages can only be children of a pageframe, or the other way around pages must have a pageframe as parent class, they can't exist on their own or in a shape or in a page. Pageframes can be part of a page, indeed. I inherited an applicartion making the same use of nested pageframes, this works even with a high nesting level, shouldn't be a problem, though single page pageframes could be.

Did you subclass pages? Or the pageframe?

How about making each pageframe double paged at least and in page2.init do RETURN .F., that'll remove page2 at runtime and may save the day.

Bye, Olaf.

 

[SimplyES]

With programming, there are times when things going wrong and being really hard to fathom out is the best thing that can happen, just because the feeling that comes when you finally win the battle is awesome (not to mention being a very great relief)! Thanks to you gents at Tek-Tips I now have a working form.

I tried changing the Pagecount for the single-page pageframes on my form to 2, first with the RETURN .F. in the Page2 INIT (didn't work) then without that line in the INIT (didn't work). Poked around a bit more and found that I had, in fact, changed one item in my baseclass (that is, my baseclass - BPageFrame, the subclass of Pageframe). I had changed the pagecount to 1 as default. I have now changed that back to the standard, 2, and all is calm for Christmas!

So it seems a class based on the Pageframe class should not have the PageCount changed to less than 2.

Thanks again, Olaf.

 

[Olaf Doschke]

Seems so, yes. You also get some bug, if you subclass the container base class and put such a subclass into itself. Seems nesting subclassed objects is somewhat problematic.

Bye, Olaf.