May 94 - Handling Preferences
Handling Preferences
Bob Hablutzel
I have something new for you this month. So far, all my articles have been
MacApp-based. This month, I am going to present a generic C++ class. Actually; if you
get the source code diskettes, you will get two versions of this generic class - one for
the standard system header files, and one for the MacApp 3.0.1 header files. The
differences are syntactic and minor; I'm just saving you the work of making the
changes yourself.
The Issue
The problem to solve this month is handling user preferences. One of the marks of a
good Macintosh program is the maintenance of a preference file in the preferences
folder. This file can contains the information that describes how the user has
customized the application for the way they work.
In general, this information can be neatly captured in resources. The data is fairly
small, and usually broken into chunks that different parts of the application access.
The code I present here handles preferences as resources.
Let's talk briefly about the zen of preferences. Preferences may or may not have
default values. The user's company name, for example, is rarely defaulted. (The user's
name can-and should-be obtained from the name entered under Sharing Setup). The
color for comments in code could, however, be defaulted; the user has the option of
overriding this default.
There needs to be a place for storing these default values. Generally, the application
resource fork is the best, most convenient place for this. This is simply done by
storing the preset preference resource in the application; when the application goes to
access the preference it will be found in the application until a new resource is created
in the preference file.
For saving changed resources, however, the application resource fork cannot be used.
Since applications might be run from a read only volume, such as file servers; any
attempt to write to the application would fail. Also, remember that in a server
environment there might be multiple users of a single copy of an application. We want
the preferences from each user to remain separate and distinct.
We are then left with two different strategies: one for reading and one for writing.
When reading, the code needs to first look in the preference file, if any, and then in the
application. Reads should not fail if the preferences file is not there. When writing,
the code needs to write the resource directly to the preferences file, creating it if
necessary. Additionally, the code needs to check to see if there is an existing preference
resource in the preference file; this resource will need to be deleted if it exists.
The class I have written is designed to be generic. In particular, it makes no
assumptions about the failure handling mechanism of the framework you are using. It
therefore does not signal errors in any coherent manner. Read errors are signaled by
returning a NULL handle; write operations fail silently.
This is probably not as bad a situation as you might think. Remember that preferences
are generally fairly lightweight data. The application can execute without reading or
writing preference information; it will simply use default information instead. (Of
course, if the application is counting on a default preference resource to be there, and
it's not, there might be problems. But this case means that the application resource
fork is not in the state the application assumes it is in, which is probably a problem in
any case).
It would be fairly trivial to enhance this code with failures, if you had the interest. If
enough people tell me they are interested in a failure handler based version of this
code, I will write it for inclusion in a future source diskette.
The Class
This class is used by declaring a stack based object of class CPreferencesHandler. The
class takes a single argument, which is the ident of a resource of type 'Prfl'. This
resource describes the resource file in case the preferences handle needs to create the
file; it includes the name of the file, the type and creator, and the script system. The
file will be created in the preferences folder, as specified by a FindFolder call. The
resource also includes a string to include in the file for the Finder to display when the
file is clicked upon.
The reason that the file name needs to be included is that the user might well change
the name of the application. We don't want to have the problem of losing the
preferences file if the user does so. So we make sure we always look for the same file.
The file type and creator are needed because the Human Interface Guidelines say that
the application should not be launched if the preferences file is double clicked upon.
Since the preferences file is not the same as the document type for the application, the
application will most likely get confused anyhow. So the recommended tactic is to
register a creator for the preferences file and never create an application that can
open this type. Then, when the Finder goes to open the file, it will fail, and post up the
string specified as part of the 'Prfl' resource. This string will let the user know that
the file could not be opened as it is a preference file.
Once the object has been declared, reading and writing preference resources is trivial.
To read, the ReadPreference method is invoked. This opens the preference file, if any,
and attempts to read the resource. If the resource or preference file could not be read,
then the method attempts to read from the application. If the resource could not be
found in either place, NULL is returned.
Writing resource is just as easy. In the case of writing, the handle is passed along with
the type and ident of the resource. The preference file is created, if necessary, and any
old copies of the resource are deleted.
A couple of final notes. This class is a little inefficient in a number of ways. First, it
insists on continually opening and closing the resource file for each read/write. Also,
it does not check to see if the file is already open before opening it; this could lead to
the file getting closed behind someone's back. I have an idea for fixing both these
problems, but that is next months column. Preferences files are special enough that
these limitations should not prevent you from using the class as it is, and I promise
that the interfaces for the class will not change when the new version comes out.
In any case, these classes reduce the headache of preferences files down to a couple of
simple calls; the class hides all the complexity (as it should). I have found these
classes to be extremely useful; I hope you will too.
**** Sidebar ***
// Declare the preference file data type
OSType creator;
OSType type;
short script;
short fileOpenCommentIdent;
Str31 fileName;
} PreferencesFileData, *PreferencesFileDataPtr,
**PreferencesFileDataHandle;
// Declare our class
class CPreferencesHandler
CPreferencesHandler(
short preferencesFileDataIdent = 128 );
~CPreferencesHandler( void );
// ReadPreference is called to get a resource from the
// preferences file, if available, or from the application,
// if available.
Handle ReadPreference(
OSType resourceType,
short resourceIdent );
// WritePreference is called to write a resource to the
// preferences file, creating it if neccessary
void WritePreference(
Handle preference,
OSType resourceType,
short resourceIdent,
const Str255& resourceName );
private:
// GetApplicationResource is called to get a resource from the
// application file
Handle GetApplicationResource(
OSType resourceType,
short resourceIdent );
// fPreferencesFileSpec contains the preferences file spec
FSSpec fPreferencesFileSpec;
// fSpecificationValid contains TRUE if the specification is
// valid - the preferences file name could be found.
Boolean fSpecificationValid;
// fPrefData contains a handle to the preferences data
PreferencesFileDataHandle fPrefData;