Tab Controls within Tab Controls

[Walt Decker]

Has anyone tried this? If so, what kinds of problems did you run into, if any?

[Michael Mattias]

You mean like one or more of the tab control sheets is itself a tab control with its own set of tabs?

Well, no reason it could NOT work, but depending on how complex the individual tab screens are it's gonna be a dog to keep track of where you are. You are going to be processing WM_NOTIFY messages and calling GetParent() more than Carters' has Little Pills.

Not to mention.... I definitely think I would try to find some kind of prototyping tool which could give you an idea of what it's going to be like to actually USE this thing, because it sounds like a lot of support calls from Susie User.

I think Microsoft's screens using "many" tabs which seem to jump around when you select different tab items were confusing. This might take that to a whole new level of "user-hostility."

Perhaps you should consider describing the application and soliciting "user presentation ideas" from others?

MCM

[Trento Castricone]

EZGUI 4 solves this problem. - Layers -

http://chrisboss.hypermart.net/cgi-bin/Ultimate.cgi

The primary purpose of the layering method is for supporting Tab controls (each Tab's controls are placed on a separate layer). It is also very useful in creating those "wizard" type dialogs seen in many applications. Layers can be used in a variety of ways and are not a Windows concept. They are an EZGUI concept. EZGUI tracks all controls and knows which form they are on and to which layer they are assigned. This allows EZGUI to do all sorts of tricks by using layers.

Layers solve the problem of too little space on a form for all the controls. Layers can be shown and hidden at will.

[Paul Squires]

FireFly Visual Designer also handles "tabs on tabs" as evidenced by Mark Strictland and Marty Francoms huge pharmacy application that uses the tab on tab approach extensively.

[Michael Mattias]

This "Tab on Tab" thing I have to see. Are there demos or screenshots available somewhere?

[email protected]

[Edwin Knoppert]

Walter,

About the private mail, i have sent a link twice but i have the feeling it's blocked or something else happens.
I can read your pm's fine so maybe you should send me your e-mailaddress via pm (or make use of my contactpage).

Edwin,

[Kev Peel]

This whole site is a recommended read for reviews what 'not' to do when designing your GUI interfaces. They even offer (IMO) better ways when a bad design is reviewed:

http://homepage.mac.com/bradster/iarchitect/shame.htm

Check out the following page on tabbed dialogs (the paragraph on Multi-Edit 8 is relevant here)...

http://homepage.mac.com/bradster/iarchitect/tabs.htm

[Chris Boss]

Walt,

The problem with using a control as a parent for a common control, is that common controls usually send the WM_NOTIFY message to its parent and if a control is the parent, you don't have access to its window procedure.

You either have to subclass the parent control to get access to the WM_NOTIFY message or avoid using a control as a parent.

To make things easier, you may consider superclassing a Tab control (to create a totally new window class) and have this superclass foward the WM_NOTIFY messages of any child control to the parent dialog. This would allow you to simply create a parent syle tab control any time you need it (the superclass) it will also forward its childrens WM_NOTIFY messages to the parent dialog.

Another technique is to simply use a dialog as a child of the tab control and then put the other tab on the child dialog.

While using child dialogs as control containers works well, it does tend to increase the number of dialogs you are using in an app and creates the need for more dialog procedures.

The superclass technique may be worth investigating. A single well designed window procedure for a superclass of the Tab control, would allow you to use it over and over again (as a control container) and not have a need for subclassing individual controls or the need for extra dialogs simply as container windows.

[Michael Mattias]

For that matter, the second tab control need not 'really' be a child of another tab control.. but it can look like a child by moving it on WM_SIZE.