Hi Tracy,

Ideas below:

1) Make each page's controls (and code) a container. Instantiate all the containers and save their references into a collection before you get to the form. Hand the collection to the form or page frame when that control instantiates, letting its code determine which of the containers/pages are desired and setting the page count of the page frame respectively (this was the way I accomplished this when I used pageframes).

2) Same concept, different approach: after you move each page's controls into a container, have a separate "behavior class" for each container with that container's code (so that you can fire whatever you want whenever you want). Instantiate all the *code classes* (which are non-visible) at the front; only instantiate the pages you want/need in the same manner as above.

3) The way I do everything now: I don't use pageframes; instead of that, I:
-- a) create a base form with my common controls (if any -- I like to use a TreeView for navigation) and an open area ;
-- b) create a base container which is exactly the same size as that open area ;
-- c) create a base custom "behavior" class
-- d) design each page as a subclass of that base container (or copy it from your existing pages), with the desired controls but no code ;
-- e) create a behavior class for each specific page container, which is a subclass of the base behavior class, usually with methods that employ BINDEVENT() to link themseleves to events of their parent container's controls and methods ;
-- f) create a behavior class for your base form, again binding to events on the form, which manages which container is shown at what time ;
-- g) tie it all together with a *single* property in the base container specifying the desired behavior class for that container and a method that instantiates that behavior class upon instantiation of the container.

This buys you several things:
-- there's little, if ANY, code in your visual classes (my main form has ONE line of code, and my visual containers have NONE)
-- you can just instantiate the behaviors if that's all you need
-- you can separate the behavior from the controls, allowing you to use the same behaviors with multiple interfaces
-- you only have to instantiate the visible controls you want/need/have rights to
-- the number of available pages (containers) is unlimited

These are just ideas...YMMV. Let me know if you need some code or further detail for any of these, and I can probably come up with some drawings and/or samples.

Evan

>I have code that removes and adds pages from a pageframe as needed, but I want to do something different. I want the pages to exist but just be invisible and not accessible by the user. This is because I have code in the pages that I call from page1 and I want that code to run even if the user doesn't access or need to see the other pages. Granted, the code could be moved but I would prefer to leave the code as is but just make the additional pages invisible if possible. For some users the pages will be visible and accessible, but others they should only see 1 page tab. Anyone seen anything like that? Right now I have the other pages enabled = .F. when the user doesn't want to use them, but I would like them to be hidden, but not removed. I don't want to remove them, nor do I want to remove the tab for the 1st page nor do I want to stretch the tab all the way across when the other pages are not there.