>Are there known do's and don't when using pageframes within pageframes?
>
>I am creating a form based on "cBizObjNoListMaintForm" where I have
>placed a pageframe on the first page of the pageframe provided as part
>of the class (parent pageframe). The second pageframe's(child)purpose is to have enough field space for the business object I placed on page 1 of the parent pageframe. No controls or additional business objects will be added to this child pageframe.
>
>When I try to enter the builder for the business object on page one of
>the parent pageframe, the builder gets errors in the following order:
>1) In statusbar the message "SecurityDBC_Name not found in APPINCL.dbf"
>2) Error message appears:
> Program Error
> "PAGES" is not object
>3) After continuing:
> MereMortals Builder
> Alis MMEC_Pagessecurity is not found
>
> USE in MMEC_PageSecurity.
>
>Are there specific do's and don't when using/adding pageframes to forms and other pageframes in the framework?
>
>I change the page names from PAGE3, PAGE4, etc to meaningful names for the pages I added to both the parent and child pageframes. PAGE1 and PAGE2 could not be changed. Is changing the page names part of my problem?


I'm not a MM expert, but have used it with nested pageframes and ran into some problems myself.

1) PAGEFRAMES: Look in the class definition for cPageFrame in cContrls.vcx. There's a method named AddUIEnabler(). At runtime, each page gets its own instance of UIEnabler from kCustCtl.vcx. This object is tightly coupled to is presumed use on the "primary" pageframe on a BizObj form. Its' UIEnable() method can call ThisForm.New(), trigger recursive calls to objects' Refresh() methods and other behavior that is NOT desirable in nested pageframes.

One solution is to override the AddUIEnabler() method so those UIEnable objects never get created at all. Fortunately there are no other objects that refer back to the UIEnablers, so this works. It might be better to use a pageframe class that does not descend from cPageFrame. That way you can control it much better. You can use the class browser to change the Parent Class of your nested pageframes. HOWEVER, to also change all *references* to your pageframe in the project, open all affected classes in the same instance of Class Browser before performing the surgery. And OF COURSE back up the entire project before attempting this.

2) PAGE NAMES. I believe there's framework code that *assumes* the pages will be named Page1, Page2, etc. when it iterates through all pages on the pageframe. That would definitely be a problem, and I recommend changing them back. Also, the original Codebook used a set of constants name PAGE_LIST, PAGE_SELECTIONCRITERIA, PAGE_DATAENTRY. These were referenced in code. These "constants" however are data-driven, meaning they evaluate at run-time, not at compile-time as you'd expect constants to do. Look in the Include\AppIncl.dbf table at the last 3 entries. AppIncl.h shows the constant definitions, which call a function that looks up the values in the AppIncl table. You might try changing the values in the "string" fields to what you want them to say and see if that works.

Definitely check out what the UIEnabler is doing. It's very hard to trace through the code because the navigational toolbar references _Screen.ActiveForm, which sees the Debugger as the ActiveForm and blows you out of your debugging session. The only way around this is to alter framework code, which is not a task for the faint-hearted.

Sorry I can't be more specific, but I "feel your pain" and hope this leads you in the direction of solving your problems.