The embedding model has many advantages, one of which is that it makes it possible to treat a set of items as a group. By acting on a common parent, you can move, disable, or hide groups of items. Disabling the root control of a window, for example, will disable all items in the window.
Doing things like switching tabs becomes remarkably easy. You can simply use a blank user pane control as the common parent for all items in a particular "page" of a tab control. After creating as many user panes as you have tabs, you can just hide one and show the next when a tab is clicked. All the controls embedded in the user pane will be hidden and shown automatically when the user pane is hidden and shown.
In hiding, showing, disabling, and enabling groups of controls, it's important to preserve the state of an item when it's hidden or disabled so that when its parent is shown or enabled, the item appears in that same state. To accomplish this, we've added the concept of latency. Controls are considered latent when they're disabled or hidden only because their parent control is disabled or hidden. It's effectively saying, "This item should be enabled (or shown) when its parent is enabled (or shown)." If you disable a control that's latent, it becomes truly disabled and won't be enabled when the parent is enabled. Likewise, if you enable a control whose parent is disabled or latent, the control becomes latent until its parent is enabled.
When enabling and disabling controls, to ensure that this latency information is always correct, you should use the new routines DeactivateControl and ActivateControl instead of just setting the highlight with HiliteControl, as you undoubtedly have always done in the past. It would be smart to use these routines even when no embedding or latency is involved - they'll set the highlight code correctly and redraw the control. For controlling visibility, the old HideControl and ShowControl routines have been modified to deal with latency when an embedding hierarchy is present for a window.
