UOrnaments: Half-price Icons

Thomas E. Burns

What if you want to display a bunch of icons, but find that TIcons are too big and slow? This type of situation calls for a class of objects that know how to draw themselves, but don't process events. To minimize memory usage, it's nice if these classes require only one instance per icon, no matter how many places an icon appears within a view.

I developed two classes for this purpose, TOrnament and TOrnamentServer, have proven useful. TOrnament is a simple abstract class that defines objects that know how to draw themselves within a view, but do not respond to events. Because of their simplicity, ornaments are about twice as fast at drawing and consume far less memory than similar views. TOrnamentServers make using ornaments easy and efficient by managing their creation and imaging.

Using ornaments

Adding ornaments to a view is straight-forward. First, by modifying your ISomeView and IRes methods, ask the appropriate OrnamentServer, gPictureOrnamentServer for pictures or gIconOrnamentServer for icons, to load the ornament. The AddOrnament method will either create and initialize the ornament, if it hasn't already been created, or increment the ornament's reference count.

gPictureOrnamentServer->AddOrnament( kTestPicture );

Then add code to your view's Draw method that draws the ornament. This example draws the ornament kTestPicture in your view(this) at location where with highlighting hlOff:

gPictureOrnamentServer->Draw( this, kTestPicture, where, hlOff );

The final step is to delete the ornament in the view's free method. DeleteOrnament will decrement the ornament's reference count and, if the reference count is zero, free the ornament.

gPictureOrnamentServer->DeleteOrnament( kTestPicture );

Even though ornaments do a lot of work for you, only four methods are needed to implement a new subclass. I will stroll through the implementation of TPictureOrnament and TPictureOrnamentServer to demonstrate the creation of new ornament subclasses.

Implementing TPictureOrnament

Subclasses of TOrnament are used to implement specific, resource-based images, such as pictures and icons. Because TOrnament implements the methods used for reference counting, Add and Delete, its subclasses need to implement only three methods: IPictureOrnament, Draw and GetExtent.

The IPictureOrnament calls IOrnament and then loads the picture resource. IOrnament merely calls IObject, sets the reference count to zero and sets fRsrcId to rsrcId. The essential code (without failure handling) for the IPictureOrnament method is:

virtual pascal void
TPictureOrnament::IPictureOrnament
(
    short   rsrcId
)
{
    this->IOrnament( pictureRsrcId );
    fPicture = GetPicture( fRsrcId );   // fPicture holds the
                                        // picture
    FailNILResource( (Handle)fPicture );
}

The Draw method is the core of an ornament. Its implementation will, of course, vary greatly for different classes of ornaments. Typically, a Draw method will call inherited::Draw (which calls PenNormal()), load and make unpurgeable the ornament's resource, and then draw with the appropriate highlighting. Because the code for drawing pictures is rather long and specific for 'PICT' resources, I will only show the definition for the method.

UOrnaments
virtual pascal void
Draw
(
    TView*              theView,    // view to draw in
    const VPoint&       where,      // top,left corner to draw at
    HLState             hilite      // the hilite to use
);

The next method, GetExtent, returns an ornament's size in a Point. This method is usually very similar to Draw. It must load and make unpurgeable the ornament's resource and then calculate its extent. Here's TOrnament's definition of this method:

virtual pascal Point
GetExtent
(
    void
);

The next step for creating a new ornament is to make a subclass of TOrnamentServer that overrides the DoMakeOrnament method. The function of TOrnamentServers is to manage the interactions between views and ornaments. A view never needs to refer to an ornament directly; it always uses an ornaments resource number instead. The advantages of this setup are:

• A view can assume that it always needs to load and unload an ornament because TOrnamentServer will only do what is necessary. TOrnamentServer loads an ornament only once and then unloads it only after all views are finished with it.
• There is no need for a view to add instance variables just to keep track of all the ornaments it is using.
• Memory is saved because an ornament is loaded only once, no matter how many views are using it.

TOrnamentServers need to create ornaments when a new one is added to its list. To maintain the "object-oriented" nature of this unit, I didn't want to make TOrnamentServer know about all the possible types of ornaments. Therefore, TOrnamentServer has a DoMakeOrnament method that returns a new TOrnament of the appropriate subclass. This method for TPictureOrnamentServer is:

pascal TOrnament*
TPictureOrnamentServer::DoMakeOrnament
(
    short       rsrcId
)
{
    TPictureOrnament*       pictureOrnament;

    pictureOrnament = new TPictureOrnament;
    pictureOrnament->IPictureOrnament( rsrcId );
    return( pictureOrnament );
}

As an optional last step, write the InitPictureOrnamentServer function. This function creates and initializes an instance of the TPictureOrnamentServer class.

pascal void
InitPictureOrnamentServer
(
    void
)
{
    if ( gPictureOrnamentServer == NULL )
    {
        gPictureOrnamentServer = new TPictureOrnamentServer;
        gPictureOrnamentServer->IPictureOrnamentServer();
    }
}

Good indications

While it only required a couple of hours to write the original UOrnaments unit, it has proven to be a useful tool. The project I was working on when creating this unit, a robot controller, requires frequent use of indicators that can appear many, many times within a view. Full fledged views would be too big and slow to be practical. I hope ornaments prove to be as useful for you.