January 92 - UOrnaments: Half-price Icons
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
(
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.