xinjie,
it's clearly a solution to have a base class and thereby use the inheritance or simpler "write once, use many times" principle. But pages as memberclasses are a bit of a pain to use.
In an existing project with existing pageframes, when you first set the Memberclass you see this warning message:
What concretely hapens when you change the memberclass of a pageframe is all pages get deleted and replaced by new but empty pages of the pageclass you pick (well, or whatever you put into your pageclass).
So that makes it hardly practical to replace pages of existing pageframes in existing classes or forms of a project. And this also is true, if you'd switch from one memberclass to another.
At runtime you can set the memberclass and membeclasslibrary properties without them affecting existing pages, but that also means they stay whatever they are, the member propertis will only affect new members you create, for example by simply increasing the pagecount. That still doesn't make it easy to change from the usual page to a member pageclass.
If you plan it ahead of time for a new project, it can be very, just also plan ahead it is not simply modifying a property to change to another class, within the designer that triggers deletion and recreation of pages and all details you have in them are lost, all controls of pages, all code you put into them is not copied over into the empty new pageclass.
You could make it your default to not design pageframes at designtime, only add empty pageframes into forms. Give them a list of pageclasses they add one by one at initialization. Then edit/maintain the single pageclasses. It makes maintaining pages - let's say - different. You'd have the single page classes in one or more VCXes or PRGs and each page can be opened in parallel into the class designer (to surprise you with an advantage) to maintain them. This possible parallel editing is contrasted by not being able to navigate a pageframe of a form in design mode to have all your editing in the actual form or form class. It doesn't break encapsulation, as that's not about having all your code in one file, of course, but it becomes less practical when you want to use intellisense to address elements on other pages or on the form outside pageframes, you can still program a path like This.Parent.OtherPage.ControlX.property=value, but intellisense won't list you the controls of Otherpage as if it already was in the pageframe as a sibling page. So you do such programming "blindly". Well, in terms of encapsulation it is indeed bad style to reach outside of THIS, but making the pageframe the encapsulation scope, a page adressing another page is within this boundary, and that's taken away from you.
Anyway you do it in detail, it's not easy to fit memberclasses into already existing pageframes, so solving that page tab styling on the level of a pageframe class would be more practical than on the level of a base class for pages. No matter how nicely it would be to have a page base class that all further pages inherit from.
I can also understand the decision about that IDE step to delete all pages and recreate new ones. A pageclass can include controls and code, even if you would limit yourself to pageclasses that are empty and so could allow all the existing "furniture" of the old pages to move over. In the general case you could have overlap, the old page and the new member pageclass can have code in the same method, how do you merge that?
The different behavior of making a change to memberclass/memeberclasslibrary at design time and at runtime makes it a feature inconsistent to work with. On the other hand, if they'd use the runtime behavior at designtime, setting member classes would do nothing to the pages you already designed and I doubt many developers would then understand the meaning of them at all.
Chriss
