Volume Number: 17 (2001)
Issue Number: 09
Column Tag: Programming Techniques

The Under-used UserPane

by Spec Bowers

Presenting a Whole Slew of Nifty Controls

Could you use a QuickTime control, an MLTE control, an HTML Renderer control, a StoneTable control, a WASTE control, a Color Picker control? They're all here - made out of a UserPane.

Of all the controls Apple has created in recent years, the most flexible is the UserPane. It is also the hardest to use. Most of us probably just write special–purpose code in our update handlers or mouse–down handlers rather than bother with the intricacies of a UserPane.

With a simple wrapper class, the UserPane is very easy to use - and it makes other packages easier to use. We have made UserPane controls for QuickTime, MLTE, HTML Rendering, the Color Picker, the StoneTable list manager replacement, and the WASTE text engine. These packages are easier to use thanks to the UserPane.

Figure 1. Four kinds of UserPane

Wrapping a UserPane control around QuickTime, MLTE, or other packages makes the code easy to reuse and greatly simplifies your event handling code. The QuickTime control is almost as simple as a standard pushbutton; the MLTE control is easier than TextEdit.

Your event loop already has code for HandleControlClick, HandleControlKey, SetKeyboardFocus, Activate/DeactivateControl, Hide/ShowControl, and IdleControls. When you wrap a UserPane control around a package like QuickTime, it automatically responds to your existing control handling code. You can put controls for QuickTime, MLTE, HTML Rendering, etc. in a window, a dialog, inside a tab panel - anywhere you put a standard control - and it just works.

This article:

• describes the functions of a UserPane;
• presents a C++ wrapper class that makes it easy to use a UserPane;
• presents several examples of UserPanes;
• shows how to handle a UserPane in a window or dialog

Apple defines several callback functions for a UserPane control:

• A DrawProc draws the content of your control. It might be called to draw a part of the control but usually draws the entire control.
• A HitTestProc returns the part code of the control where the mouse–down occurred. We usually just detect a mouse–down anywhere in the control and return a partcode which represents the entire control.
• A TrackingProc tracks a control while the user holds down the mouse button.
• An IdleProc performs idle processing.
• A KeyDownProc handles keyboard events.
• An ActivateProc handles activate and deactivate events.
• A FocusProc handles keyboard focus - e.g. for Set/AdvanceKeyboardFocus.
• A BackgroundProc sets the background color or pattern for embedded controls.

To install a callback you first create a UPP, then pass it to the control via SetControlData. Later, to prevent a memory leak, you should dispose the UPP. Alternatively, you can adopt a "create once and reuse" protocol. Whatever way you do it, installing a callback is a nuisance. The AMUserPane makes it very simple to install a callback.

The AMUserPane class provides functions for easily installing callbacks and for disposing of UPPs when the control is discarded, provides some standard callback functions, and provides some utility functions to simplify using a UserPane.

To install a DrawProc, just call "SetDrawProc ()":

//—————
void   AMUserPane::SetDrawProc ()
{
   mDrawUPP = NewControlUserPaneDrawUPP (StaticDrawProc);
   ::SetControlData (mControl,
                kControlNoPart,
                kControlUserPaneDrawProcTag,
                sizeof (mDrawUPP),
                (Ptr)&mDrawUPP);
}
There are similar functions for installing a TrackingProc, KeyDownProc, ActivateProc, etc.
AMUserPane declares data members for each callback function:
   ControlUserPaneDrawUPP            mDrawUPP;
   ControlUserPaneHitTestUPP         mHitTestUPP;
   ControlUserPaneTrackingUPP      mTrackingUPP;
   ControlUserPaneIdleUPP            mIdleUPP;
   ControlUserPaneKeyDownUPP         mKeyDownUPP;
   ControlUserPaneActivateUPP      mActivateUPP;
   ControlUserPaneFocusUPP            mFocusUPP;
   ControlUserPaneBackgroundUPP      mBackgroundUPP;
Its constructor initializes each UPP to nil, and its destructor disposes each (non–nil) UPP:
//—————
AMUserPane::AMUserPane ()
{
   mDrawUPP = nil;
   mHitTestUPP = nil;
   mTrackingUPP = nil;
   mIdleUPP = nil;
   mKeyDownUPP = nil;
   mActivateUPP = nil;
   mFocusUPP = nil;
   mBackgroundUPP = nil;
}

//—————
AMUserPane::~AMUserPane ()
{
   if (mDrawUPP != nil) {
      DisposeControlUserPaneDrawUPP (mDrawUPP);
   }
   if (mHitTestUPP != nil) {
      DisposeControlUserPaneHitTestUPP (mHitTestUPP);
   }
   if (mTrackingUPP != nil) {
      DisposeControlUserPaneTrackingUPP (mTrackingUPP);
   }
   if (mIdleUPP != nil) {
      DisposeControlUserPaneIdleUPP (mIdleUPP);
   }
   if (mKeyDownUPP != nil) {
      DisposeControlUserPaneKeyDownUPP (mKeyDownUPP);
   }
   if (mActivateUPP != nil) {
      DisposeControlUserPaneActivateUPP (mActivateUPP);
   }
   if (mFocusUPP != nil) {
      DisposeControlUserPaneFocusUPP (mFocusUPP);
   }
   if (mBackgroundUPP != nil) {
      DisposeControlUserPaneBackgroundUPP (mBackgroundUPP);
   }
}

Look back at SetDrawProc and you'll see that it installs a callback to a function named "StaticDrawProc". AMUserPane provides a member function, DoDraw, which is overridden in each subclass. The StaticDrawProc is a glue function which dispatches to the particular DoDraw of the subclass - the QuickTime DoDraw, or the MLTE DoDraw, for example. During initialization we store a pointer to a specific instance of AMUserPane in the control's RefCon. In each callback we retrieve the control's RefCon, cast it to an AMUserPane pointer, then call the member function.

//—————
void   AMUserPane::Initialize (
   ControlHandle      inControl)
{
   mControl = inControl;
   ::SetControlReference (mControl, (SInt32)this);
}

//—————
pascal void      AMUserPane::StaticDrawProc (
   ControlHandle   control,
   SInt16               part)
{
   AMUserPane*      pane = (AMUserPane*)::GetControlReference (control);

   pane->DoDraw (part);
}

//—————
void   AMUserPane::DoDraw (
   SInt16      part)
{
   // override in each subclass
}

AMUserPane is a base class; it provides common code for a wide variety of UserPane controls. We have made half a dozen subclasses. Let's take a look at some of them.

Our simplest UserPane is a wrapper around the Color Picker. It paints the control's rectangle with a color. If the user clicks the UserPane, it invokes the Color Picker, then redraws the rectangle with the selected color. We overrode DoDraw and DoTracking. The Initialize function calls SetDrawProc and SetTrackingProc to install callbacks.

//—————
void   AMColorSwatch::DoDraw (
   SInt16         /* part */ )
{
   RGBColor      saveColor;
   Rect            rect;

   ::GetForeColor (&saveColor);
   ::RGBForeColor (&mSwatchColor);
   GetControlRect (&rect);
   ::PaintRect (&rect);
   ::RGBForeColor (&saveColor);
}

//—————
ControlPartCode      AMColorSwatch::DoTracking (
   Point            startPt,
   ControlActionUPP   actionProc)
{
   ControlPartCode      result = 0;
   Point            dialogPos = {0, 0};
   Str255            prompt = "\p";
   RGBColor         outColor;

   if (::GetColor (dialogPos, prompt, &mSwatchColor, &outColor)) {
      mSwatchColor = outColor;
      DoDraw (0);
      result = 99;   // any non-zero code
   }

   return result;
}

//—————
void   AMColorSwatch::Initialize (
   ControlHandle      inControl)
{
   AMUserPane::Initialize (inControl);

   SetDrawProc ();
   SetTrackingProc ();
}

The HTML pane is only slightly more complex but illustrates two glitches. The first time we put it inside a Tab control it worked pretty well. Clicking a tab results in HideControl/ShowControl of the panels. Each panel is a simple UserPane with embedded controls. When we hide or show a panel, the Control Manager hides or shows any embedded controls, including our custom UserPane controls. (This by the way is one of the advantages of turning QuickTime, MLTE, etc. into UserPane controls - HideControl, ShowControl and other Control Manager functions work the same as with standard controls.)

There was a glitch, though. When we deactivated the window, suddenly one of our hidden UserPane controls drew something. The Control Manager doesn't call the DrawProc of a hidden control but it may call the ActivateProc. We added a simple "IsVisible" call to test for visibility inside any of our callback functions that might draw anything.

//—————
void   AMHTMLPane::DoActivate (
   Boolean      activating)
{
   Rect         cntlRect;

   if (IsVisible ()) {
      if (activating) {
         HRActivate (mHTMLRec);
      } else {
         HRDeactivate (mHTMLRec);
      }
   }
}

This didn't completely solve the problem, however. We saw the HTMLPane's scrollbars even when the pane was hidden. This was because the scrollbars were not properly embedded within the HTML UserPane. The HTML Rendering Lib creates scrollbars on the fly as needed. Those scrollbars end up embedded in the root control. Because they are not embedded in the HTML UserPane they are not hidden/shown along with the pane. Our solution is to look for newly created controls in the root control and embed them in our UserPane control.

Before we call any function that might create other controls we call CountRootControls. Afterwards, we call EmbedNewControls. If there are more controls afterwards than before, those new controls should be embedded in our UserPane, not in the root control.

//—————
UInt16      AMUserPane::CountRootControls ()
{
   UInt16            numControls = 0;
   WindowRef      theWindow;
   ControlRef      root;

   theWindow = GetOwnerWindow ();
   ::GetRootControl (theWindow, &root);
   ::CountSubControls (root, &numControls);

   return numControls;
}

//—————
void   AMUserPane::EmbedNewControls (
   UInt16         inBeforeNum)
{
   WindowRef      theWindow;
   ControlRef      root;
   UInt16            afterNum;
   UInt16            i;
   ControlRef      child;

   theWindow = GetOwnerWindow ();
   ::GetRootControl (theWindow, &root);
   ::CountSubControls (root, &afterNum);
   for (i = afterNum; i > inBeforeNum; i—) {
      ::GetIndexedSubControl (root, i, &child);
      ::EmbedControl (child, mControl);
   }
}

In most of our UserPanes' Initialize functions we call CountNewControls and EmbedNewControls just in case subcontrols are created. The HTMLPane's Initialize is typical. We get a "before" count of root controls, create a new HRReference, then set its bounds to the UserPane control's bounds. We install a DrawProc, TrackingProc, and ActivateProc. Finally, we embed the newly created controls (scrollbars) in the UserPane.

//—————
void   AMHTMLPane::Initialize (
   ControlHandle      inControl)
{
   AMUserPane::Initialize (inControl);

   OSErr         err = noErr;
   UInt16         beforeNum;
   Rect            cntlRect;
   GrafPtr      ownerPort;

   beforeNum = CountRootControls ();

   GetControlRect (&cntlRect);

   ownerPort = (GrafPtr) GetWindowPort (GetOwnerWindow ());
   err = HRNewReference (&mHTMLRec, kHRRendererHTML32Type, ownerPort);

   if (err == noErr) {
      HRSetRenderingRect (mHTMLRec, &cntlRect);
      HRSetDrawBorder (mHTMLRec, true);

      SetDrawProc ();
      SetTrackingProc ();
      SetActivateProc ();
   }

   EmbedNewControls (beforeNum);
}

The HTMLPane was now working well - until we viewed an HTML file that had a frameset. Suddenly, there were two new scrollbars and they were not embedded properly. So we added CountRootControls and EmbedNewControls to the DoDraw function. Other than that, the DoDraw is very simple.

//—————
void   AMHTMLPane::DoDraw (
   SInt16         part)
{
   UInt16         beforeNum;
   Rect            cntlRect;

   beforeNum = CountRootControls ();

   GetControlRect (&cntlRect);
   HRSetRenderingRect (mHTMLRec, &cntlRect);

   RectRgn (mHTMLRgn, &cntlRect),
   HRDraw (mHTMLRec, mHTMLRgn);

   EmbedNewControls (beforeNum);
      // in case last click created new scroll bars
}

The DoTracking function is very simple. About all it does is ask the HTML Rendering library to handle the event. We could have synthesized a mouse–down event from the Start Point but instead we call an external function to get the current event record from our main event–handling code.

//—————
ControlPartCode      AMHTMLPane::DoTracking (
   Point            startPt,
   ControlActionUPP   actionProc)
{
   WindowRef      owner = GetOwnerWindow ();

   ::SetPortWindowPort (owner);
   ::HRIsHREvent (GetCurrentEventRecord ());

   return 99;   // any non-zero code
}

Okay, so we have written a UserPane class. How do we use it? That's the easy part. First, create a UserPane control resource. For a window or a dialog, create a CNTL with procID 256 and initial value 318. This value turns on feature bits for SupportsEmbedding, SupportsFocus, WantsIdle, WantsActivate, HandlesTracking, and GetsFocusOnClick. For a dialog, in its DITL resource create an item of type Control and set its ID to the resource ID of the CNTL resource.

Wherever you declare the variables (data members) for your window or dialog, declare an instance of the UserPane class. We find it convenient also to declare a ControlHandle. You'll also have to #include the UserPane class's header.

#include "AMColorSwatch.h"
   ControlHandle   mSwatchHandle;
   AMColorSwatch   mSwatchPane;

When you create a window, get a ControlHandle to the UserPane control, then initialize the instance of the UserPane class.

   mSwatchHandle = ::GetNewControl (CNTL_Swatch, window);
   mSwatchPane.Initialize (mSwatchHandle);

In your window's event handling code for a mouse–down, call the usual FindControl. If the click is in the UserPane control, call the usual TrackControl or HandleControlClick.

   if (whichControl == mSwatchHandle) {
      if (HandleControlClick (mSwatchHandle, where, curEvent.modifiers, nil) != 0) {
      }
   } else if (mSwatchPane.ClickSubControl (whichControl, where)) {
      // ClickedSwatch ();
   }

What is "ClickSubControl"? If the UserPane has any subcontrols, e.g. scrollbars, then FindControl may find that the click was in the scrollbar. ClickSubControl checks to see if the click was in one of the UserPane's subcontrols. If it was, then ClickSubControl passes the click along to the UserPane class's DoTracking method and returns true. If the click was not in a subcontrol, then ClickSubControl returns false.

//—————
Boolean      AMUserPane::ClickSubControl (
   ControlRef      inControl,
   Point            inWhere)
{
   UInt16            numSubs;
   UInt16            i;
   ControlRef      sub;

   ::CountSubControls (mControl, &numSubs);
   for (i = 1; i <= numSubs; i++) {
      ::GetIndexedSubControl (mControl, i, &sub);
      if (inControl == sub) {
         DoTracking (inWhere, nil);
            // treat it as a click in the userPane
         return true;
      }
   }
   return false;
}

The example application doesn't have any UserPanes in a dialog but it's easy to do. After creating the dialog, call GetDialogItemAsControl to get a ControlHandle to the UserPane. Then Initialize the UserPane instance with the control handle. The Control Manager and Dialog Manager will take care of almost everything. You just add a case to your dialog's switch statement.

There is one other piece of code you will have to add if your UserPane has subcontrols. You'll have to add a Filter function because the Dialog Manager doesn't know anything about the subcontrols. The Filter function will have code like this:

      if (mQuickTimePane.FilterSubControls (ioEvent)) {
         *outItemHit = kQuickTimePane;
         return true;
      }

FilterSubControls checks to see if the event is a mouse–down. If it is, then FilterSubControls calls FindWindow and FindControl, then calls ClickSubControl, which we saw earlier.

//—————
// if the event is for one of our subcontrols
// then process it as if it were for us;
// pass back true to tell Dialog Manager
// that event has been processed
//
Boolean      AMUserPane::FilterSubControls (
   EventRecord      *ioEvent)
{
   Boolean         filtered = false;
   UInt16         numControls = 0;
   WindowPtr      whichWindow;
   ControlHandle   whichControl;
   Point         localWhere;
   short         partCode;
   UInt16         i;
   ControlRef      sub;

   ::CountSubControls (mControl, &numControls);
   if (numControls > 0) {
      if ((ioEvent->what == mouseDown)
      && (FindWindow (ioEvent->where, &whichWindow) == inContent)) {
         SetPortWindowPort (whichWindow);
         localWhere = ioEvent->where;
         GlobalToLocal (&localWhere);
         FindControl (localWhere, whichWindow, &whichControl);
         if (ClickSubControl (whichControl, localWhere)) {
            return true;
               // => click was for this userPane
         }
      }
   }
   return filtered;
}

We've described two of our UserPanes - the Color Picker and the HTML Renderer. The other four UserPanes - for QuickTime, MLTE, StoneTable, and WASTE - are similar. The AMUserPane class, all six UserPane classes, and the example application are available as source code. The controls are useful and easy to use. If you use any of them we would be interested in hearing from you.

These UserPane classes are part of the AppMaker library. The example was 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 these UserPanes are very useful widgets 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.