ADVERTISEMENT

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
typedef struct
{
    OSType                      creator;
    OSType                      type;
    short                       script;
    short                       fileOpenCommentIdent;
    Str31                       fileName;
} PreferencesFileData, *PreferencesFileDataPtr,
    **PreferencesFileDataHandle;

//  Declare our class
class   CPreferencesHandler
{
public:
    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;
};