Rez Is Your Friend
Volume Number: 14
Issue Number: 9
Column Tag: Tools Of The Trade
Rez is Your Friend
by Marshall Clow
Edited by the MacTech Editorial Staff
What is Rez and why should I care?
What is Rez?
Every Macintosh program is made up of resources. Dialogs, Alerts, String Lists, the
list goes on and on. These resources have to be created by the someone, and are part of
the program. Every programmer is familiar with ResEdit or Resorcerer, which let
you edit resources visually. Fewer programmers know about Rez, the resource
compiler.
Rez is a compiler, like a C, Pascal or C++ compiler. It takes text files (usually with
the suffix '.r' ) as input, and produces a resource file as output. MPW also ships with
DeRez, which takes a resource file and produces a text file that can be input back into
Rez. Originally, Rez ran only under MPW, but both Symantec and Metrowerks have
shipped versions of Rez as part of their integrated development environments.
In this article, I'm not going to give a tutorial on Rez. Instead, I'm going to concentrate
on the reasons that you should be using Rez to manage your resources. A full manual
for Rez (and DeRez) can be found in Appendix C of "Building and Managing Programs in
MPW, available at
ftp://ftp.apple.com/devworld/Tool_Chest/Core_Mac_OS_Tools/MPW_etc./Documenta
tion/MPW_Reference/Bldg%26Mng_Progs_In_MPW.sit.hqx.
A Little History
When first Macintosh development environments shipped (back in 1985), they
included a tool called RMaker. (ResEdit didn't appear until late 1985 or early 1986)
RMaker (short for Resource Maker), like Rez, was a resource compiler, translating a
text file into a resource file. However, RMaker knew about only a few resource types,
and was not easily extensible. So, when Apple shipped MPW 1.0 in 1986, they
provided a completely new set of resource tools. Rez, DeRez, and RezDet. Joel West
wrote an article for this magazine about the new tools in MPW 1.0. See
http://www.mactech.com/articles/mactech/Vol.03/03.02/Rez-ervations/index.html
for a description of those tools as they appeared in MPW 1.0.
An improved version of Rez shipped with MPW 2.0 in 1988, and Rez 3.0 included
support for QuickDraw pictures.
Symantec shipped stand-alone versions of Rez and DeRez (cunningly named SA-Rez and
SA-DeRez) with Think C 6, and incorporated Rez into the IDE with the THINK Project
Manager 7.0 (68K) and the Symantec Project Manager (PPC).
Metrowerks incorporated Rez into their IDE starting with CodeWarrior 6.
Why Rez?
At this point you are probably asking yourself, "Why should I care about Rez? I do all
my resource editing in ResEdit/Resorcerer, why would anyone use Rez?". There are
several reasons:
Comments
Since Rez source files are text files, they can contain comments about why a resource
contains some information. A change history is another good thing to put here. Unless
you have a great memory, you will want to put comments in your resource files so that
when you look back a year (or two later), you can tell why this number in a table was
changed from a 23 to a 42. Since resource files are binary data, there is no place to
put comments there.
Don't underestimate the importance of comments. Would you write code without
comments? They have saved me hours (or days!) of debugging on many occasions.
This is a big feature. Since Rez supports C-style macro processing, you can give
symbolic names to your resource types and IDs, and use these definitions in a header
file for both your resources and your C/C++ code. Whenever I see a bit of code that
says something like:
h = Get1Resource ( 'Foo!', 234 );
I cringe. I just know that somewhere down the line, someone will need to change the ID
of that resource, and they may or may not find all the places that load/use that
resource. I use a header file that is shared between my resource files and my source
files.
// File Foo.h
#define kNormalFooResID
// File Foo.c
h = Get1Resource ( 'Foo!', kNormalFooResID );
// File Foo.r
resource 'Foo!' ( kNormalFooResID, purgeable ) {
If you prefer a less made-up example, here's one that uses familiar resource types:
// File Foo.h
#define kNoAppleEventsAlert 130
// File Foo.c
if (( Gestalt( gestaltAppleEventsAttr, &attrs )) != noErr )
Alert ( kNoAppleEventsAlert, nil );
else { // normal processing
// File Foo.r
resource 'ALRT' ( kNoAppleEventsAlert ) {
{ 0, 0, 200, 400 }, // bounds for the alert
kNoAppleEventsAlert, // the DITL associated with this alert
OK, visible, silent,
OK, visible, silent,
OK, visible, silent,
OK, visible, silent
},
centerMainScreen // Where to show the alert
resource 'DITL' ( kNoAppleEventsAlert ) {
// Dialog items go here
To renumber the alert, all I have to do is change one line in Foo.h and rebuild. The
resources will be renumbered automatically, even the reference to the DITL inside the
ALRT resource.
Not convinced yet? Here's another example. Suppose that you want all the buttons in
your application to have the same "look". For the sake of argument, let's say that you
want them all to have the same height. Using ResEdit or Resorcerer, this is a
nightmare, because you would have to go through each and every dialog and find each
button, and check (and possibly change) the height of each button, to conform to your
standard. Heaven help you if some UI designer or product manager decides that all the
buttons need to be two pixels higher (to aid in translation to Urdu, no doubt).
Using Rez, (and a little foresight), it's a one line change!
// File Foo.h
#define kButtonHeight 20
// File Foo.r
resource 'ALRT' ( kNoAppleEventsAlert ) {
// We've seen this before.....
resource 'DITL' ( kNoAppleEventsAlert ) {{
{260, 129, 260 + kButtonHeight, 209},
Button { enabled, "OK" };
{260, 40, 260 + kButtonHeight, 120},
Button { enabled, "Cancel" };
{8, 72, 23, 264}, StaticText { disabled, "Hi Mom!" };
};
};
When I change the kButtonHeight constant in the header file, all the buttons in the
application change to match the new regime.
Of course, you can extend this for button widths, height and widths of other items.
Extensibility
Rez is extensible, i.e, you can write resource definitions for you own resource types.
In fact, Rez comes with a set of header files that define the structure of all the common
Mac resources types; Rez does not have any "built-in" resource types. It does have a
set of built-in types that you can use as fields in your resources, such as bytes, 16
and 32 bit integers, C and Pascal-style strings, and a few others. Here's an example of
a C struct definition and a corresponding Rez definition:
// In a header file
struct FooListEntry {
short fooIndex;
short fooValue;
};
struct FooResource {
short fooVersion;
short fooMinorVersion;
long fooCount;
FooListEntry fooList [ 1 ];
// Really a list of 'fooCount'
typedef struct FooResource FooResource, *FooResourcePtr,
**FooResourceHandle;
// --------------- Rez ---------------
integer; // fooVersion
integer; // minor Version
long = $$CountOf ( fooList ); // size filled in by Rez
integer; // index
integer; // value
// Usage
resource 'Foo!" ( kDefaultFooList ) {
kCurrentFooVersion, kCurrentFooMinorVersion,
12, 23; // See bug #32
34, 45;
45, 56; // 54 was wrong! changed to 56 mtc 07/02/98
123, 987;
In a perfect world, Rez would read C/C++ structure definitions directly, and we
wouldn't need to have different definitions for the same data structure. However, a Rez
definition specifies exactly how to lay out the bits in the data structure, while C/C++
compilers are allowed considerable leeway in structure alignments and padding. Look
at Apple's header files. All those lines that start out '#pragma options align' are there
to control structure alignment so that 68K and PowerPC programs can share data
structures and data files.
Source and configuration control
There are several source control systems available today. Projector, SourceSafe,
SCCS, are CVS are just a few. Most of them handle binary files, but they all handle text
files much better. Diffing tools are designed to work on text files. Having your
resources in text files makes it much easier to track changes, additions, and deletions
of resources.
Since Rez files are text files, it is easy to generate them from other sources. A long
time ago, I worked on a project to print to plotters. We had a database (in Hypercard!)
that contained information on a variety of plotters (margins, paper sizes, commands
supported, etc.). We had many people gather this information and enter it into the
stack. This stack generated a ".r" file that we then compiled.
Today, a great deal of information is contained in databases. Sometimes you have to
include information from a database into your application. Most databases have
extensive report-writing facilities. It is usually fairly easy to make a database divulge
the data that you are interested in formatted in Rez format. This also makes it easy to
"refresh" the data in your application, by including up-to-date information as part of
the build process. The database could hold anything, from sample data for the user to
manipulate to the current structure of your web site.
Translation
One of the main reasons for the existence of resources is to decouple the user interface
from the code, thereby making changes (especially translation between languages)
easier. When I wrote printer drivers at HP we put all of our literal strings into a
single header file, along with comments about how the string was used. When the time
came for translation, we sent this single text file to the people doing the translations.
They sent us back a translated file, and we built a translated driver. After that, all that
was required of the translators was to adjust the layout of the dialogs, to take into
account the changed sizes of some of the dialog items. Using this scheme, we were able
to ship 12 different language versions of our driver software within 3 weeks of
releasing our English version.
When Not to Use Rez
There are some resource types for which Rez is not appropriate. For example, there is
no real structure for ICON (or icl8, etc.) resources. They are really just small
bitmaps. So a Rez definition of a ICON resource is just a string of hex digits. Icon files
are better kept as binary files, and edited with a resource editor. However, you can
still have your cake and eat it too; by using Rez to assemble the final resource file.
Suppose that you have an icon in a file called "Foo.rsrc", and in that file it is
'ICN#'(128). You can include it using Rez thusly:
include "Foo.rsrc" 'ICN#' ( 128 ) as 'ICN#' ( kFooIcon );
This will include the icon into your output file, while giving it the resource ID that
you want (which is defined by a symbolic constant).
Conclusion
Keeping your resources as text files and using a resource compiler has many
advantages over using a resource file editor. You can add comments to your resources,
use symbolic constants, define your own resource types, and use all the tools that exist
for maintaining and manipulating text files. The next time you find yourself reaching
for ResEdit or Resorcerer, consider a third option. Sometimes the old tricks work
best, and often Rez is the right tool.
Bibliography and References
West, Joel. "No Rez-ervations Needed!". MacTech Magazine (formerly MacTutor) 3:2
(February 1986).
______________________________
Marshall Clow is a programmer. He has worked for Palomar Software,
Hewlett-Packard, and Aladdin Systems. Among other things, he has written PICT
Detective, Aladdin's Resource Compression Toolkit, and way too many resource
processing tools. He currently works for Adobe Systems, where his title is "Bad
Influence". When he's not coding, he can be found mountain biking or checking out
micro breweries. He can be reached at mclow@mailhost2.csusm.edu