Volume Number: 15 (1999)
Issue Number: 4
Column Tag: Programming Techniques

The LayerGroup

by Spec Bowers

A very simple, flexible and useful widget

This article describes a very useful widget which I call a "LayerGroup." The name is derived from the Layers that many drawing programs provide, and from a RadioGroup. A LayerGroup contains and controls multiple Layers, only one of which is visible at a time. Each layer in turn can contain other controls. When a layer is made visible all of its embedded controls become visible, When a layer is hidden all of its embedded controls are hidden. The effect of hiding one layer and showing another layer is to swap in and out a set of controls.

What makes a LayerGroup so useful is that it encapsulates behavior that appears in a great many applications. The appearance varies from one application to another but the behavior is the same: the set of available controls is swapped in and out. Using a LayerGroup makes it very easy to implement this kind of behavior without reinventing the wheel.

What makes a LayerGroup so flexible is that it implements only the behavior, not the visible appearance. The appearance is determined by a control external to the LayerGroup. That control can be anything that produces an integer, such as a TabControl, a Popup, or a Listbox. Figure 1 and the example application show several kinds of LayerGroup.

These LayerGroups all look different but the implementations are essentially the same. The Tab Panel is a TabControl with a nested LayerGroup. The group in turn contains three layers, each with its own set of controls. The Tab Control produces a 1, 2, or 3. That integer is passed to the LayerGroup which shows that one layer. Similarly, the Popup Group Box has a nested LayerGroup. The value of the Popup is passed to the LayerGroup. For the Listbox example, the LayerGroup is not nested but the implementation is otherwise the same: selecting a row causes the row number to be passed to the LayerGroup.

The example application has a fourth LayerGroup which is controlled by a set of edit fields. The item number of whichever edit field is active is used to control the LayerGroup. The effect is that tabbing to or clicking an edit field causes the LayerGroup to display picture and text describing what to enter into that edit field.

In these examples the content of each layer is just one or two items but there could be any number of items. Real applications might have a dozen or more items in each layer. The LayerGroup controls the layers; each layer controls the items in that layer.

The LayerGroup behavior can be seen in many real-life applications. Most likely, the various programmers had to write special-purpose code for each application. The only reusable code I have seen along these lines is in Apple's sample code for the AppsToGo framework, <http://developer.apple.com/dev/techsupport/source/AppsToGo.html>. That code, written prior to the Appearance Manager, is quite complex. With Appearance, the code is simple.

We implemented LayerGroups going straight to Apple's Appearance toolbox and separately for PowerPlant. It would be very easy to implement it for any other class library that supports nested views and hiding and showing. (I am told that the Windows MFC library has such primitive support for nesting that implementing this LayerGroup is complicated.)

//-----
void   SetLayerGroupValue (
   ControlHandle   inControl,
   SInt16      inValue)   // 1-based
{
   SInt16      numLayers = 0;
   SInt16      i;
   ControlHandle   layer;

   CountSubControls (inControl, &numLayers);
   for (i = 1; i <= numLayers; i++) {
      GetIndexedSubControl (inControl, i, &layer);
      if (i == inValue) {
         ActivateControl (layer);
         ShowControl (layer);
      } else {
         HideControl (layer);
         DeactivateControl (layer);
      }
   } // for
   Draw1Control (inControl);
}

That's all it takes to implement a LayerGroup. The code is this simple because the Appearance Manager supports embedded controls. Layers are embedded within the LayerGroup; items are embedded within layers.

The LayerGroup and the layers are vanilla User Pane controls with no visible appearance of their own. We did not write any code for a layer. The Appearance Manager does all the work. When a layer is hidden or shown the Appearance Manager hides or shows whatever controls are embedded in that layer.

The ActivateControl and DeactivateControl calls we added to work around what is probably a minor bug in the Appearance Manager. When an active edit text control was in a hidden layer we saw a blinking insertion point even though the edit text was hidden. The cure is to deactivate a layer. That deactivates the embedded controls.

For PowerPlant, the code is very similar. The layer group is a very simple subclass of LView. The layers are ordinary LViews. Like Appearance (for quite some time prior to Appearance) PowerPlant supports nested items. Hiding (or showing) an LView hides (or shows) all the items nested within the LView. All that CLayerGroup needs is a SetValue member function that is much like the SetLayerGroupValue when using Appearance.

It is very easy to create a LayerGroup:

• Make a LayerGroup control.
• Make Layers nested within the LayerGroup.
• For each Layer, make whatever nested items you want.

You could create these controls programatically but obviously the preferred way is to create the controls from resources. For Appearance, dialogs use DITL and CNTL resources. The location and size of controls implies the nesting order. (To nest a control, specify coordinates that are completely within a preceding item.) CNTL resources are also used for windows but you have to write code to create each control and to specify how the controls are embedded. For PowerPlant, both windows and dialogs are created from PPob resources.

For a Dialog Using Appearance

Create DITL and CNTL resources. The LayerGroup and Layers are User Pane controls (procID 256) with Initial Value 2 to specify that the control supports embedding.

In your code, create the dialog via GetNewDialog:

      mDialog = GetNewDialog (inResID, nil, (WindowPtr) -1L);

For convenience later, get a ControlHandle for the LayerGroup:

      GetDialogItemAsControl (mDialog, kLayerGroup,
                                          &mLayerGroupHandle);

Respond to a hit in the controlling item (e.g. the TabControl, Popup, or Listbox) by changing the LayerGroup's value:

      choice = GetControlValue (mControllerHandle);
      SetLayerGroupValue (mLayerGroupHandle, choice);

For a Window Using Appearance

Create CNTL resources. The LayerGroup and Layers are User Pane controls (procID 256) with Initial Value 2 to specify that the control supports embedding. In your code, create each control by GetNewControl, then EmbedControl:

      mLayer1Handle = GetNewControl (CNTL_Layer1, window);
      EmbedControl (mLayer1Handle, mLayerGroupHandle);

Respond to a click in the controlling item (e.g. the TabControl, Popup, or Listbox) by changing the LayerGroup's value:

      LGetSelect (true, &selectedCell, list);
      layer = selectedCell.v + 1;      // layers are 1-based
      SetLayerGroupValue (mLayerGroupHandle, layer);

The Appearance SDK provides an FKEY for creating a dump of the control hierarchy. This is what the Listbox example looks like:

Root pane
   Control pane (Scroll Bars)
   Control pane (List Box)
   Control pane (User Pane) - LayerGroup
      Control pane (User Pane) - Layer one
         Control pane (Push Buttons)
         Control pane (Static Text)
      Control pane (User Pane) - Layer two
         Control pane (Group Box)
            Control pane (Radio Group)
               Control pane (Push Buttons)
               Control pane (Push Buttons)
      Control pane (User Pane) - Layer three
         Control pane (Static Text)
         Control pane (Edit Text)
      Control pane (User Pane) - Layer four
         Control pane (Popup Button)

For PowerPlant

Create PPob resources. The LayerGroup's classID is 'LGrp'. (A custom CTYP resource for Constructor is with the source code.) Each layer is an LView (classID 'view').

In your code, register the LayerGroup and LView classes:

      RegisterClass_(CLayerGroup);
      RegisterClass_(LView);

For convenience later, get a pointer to the LayerGroup:

      mLayerGroup = (CLayerGroup*) FindPaneByID ('XXXX');

In the ListenToMessage method respond to a hit in the controlling item (e.g. the TabControl, Popup, or Listbox) by changing the LayerGroup's value:

      case msgTabs:
         mLayerGroup->SetValue (mTabControl->GetValue ());

A simple variation is to create only two layers with the first one empty. When controlled by a checkbox the effect would be to hide or show a set of controls.

For PowerPlant, we implemented a variation which uses a pane ID instead of an ordinal number. It finds and shows the layer with the matching pane ID. We also specified a particular pane ID as a default, a layer to be shown if no other layers match the requested pane ID.

If there are many layers and/or many items within layers and if running on a slowish machine, the cost to create all of the layers with all of their items might be noticeable. A performance enhancement would be to defer creating the items within a layer until that layer is first made visible. If the user happens not to show some layers then there would be no time spent making the items within those layers.

These examples were created using AppMaker, which generated both the resources and the source code. Whether you use AppMaker or you do it by hand, I think you will find that the LayerGroup is a useful widget to have in your toolbox.

Spec Bowers is the founder, cook, and chief bottle washer at Bowers Development. He has been developing programming tools for most of his career. You can contact him at bowersdev@aol.com or see the web page at http://members.aol.com/bowersdev.