Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Config File Resource Blues
Message-ID: <7953@hoptoad.uucp>
Date: 11 Jul 89 23:44:06 GMT
References: <7930@hoptoad.uucp> <2013@dogie.macc.wisc.edu> <1165@intercon.UUCP> <1168@intercon.UUCP>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Eclectic Software, San Francisco
Lines: 50

In article <1168@intercon.UUCP> amanda@intercon.uu.net (Amanda Walker) writes:
>Hmm.  You're right.  Oops.  My apologies.  I seem to have missed the original
>article.  Our machine was dropping incoming news on the floor for a while
>recently.

I sympathize.  Dropped messages are pandemic on the network, and they can
be very frustrating.

>That makes sense, although I tend to regard worrying about memory efficiency
>while writing to resource files to be on the order of tilting at windmills
>:-).  In particular, I would think that resource maps for a settings files
>wouldn't be that big (if Ross described using huge numbers of resources in
>his settings file, I take back that remark,, but I'd argue he's doing something
>the hard way...).

True, most configuration resource files can be expected to be small.
However, many others have no real limit on size except for the limits
of the Resource Manager itself.  For instance, suppose that information
on computer accounts for a terminal emulator are stored in the file.
The user may add any number of resources.  This is the kind of file I'm
more accustomed to dealing with.  You are quite right that if the file
size is known to be small, then resizing the resource map is no strong
objection.

>No.  What I was referring to was putting a default config resource into
>the application *at build time*.  This way the read_settings routine
>doesn't have to care whether or not the settings file already exists.
>The write_settings routine always creates the settings file if it doesn't
>already exist, so the application never writes to itself.

I didn't make my point clearly enough.  I understood that you meant at
build time.  Your pseudocode did a GetResource, then a RmveResource if
the GetResource succeeded, then an AddResource, when things were being
updated.  Look at what this does if there is no resource in the
configuration file so you're using the default in the application
file.  The GetResource will return the application file copy and the
RmveResource will remove it from the application file.

This can be gotten around in a number of ways.  Probably the best is to
use a Get1Resource rather than a GetResource.  Instead, one could also
copy the default resource to the configuration file when the file is
first created, or check with HomeResFile on the result of GetResource
to make sure it's from the configuration file.  For all I know your
actual code may take care of this problem, but your pseudocode didn't
address it.
-- 
Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com
Postal: 424 Tehama, SF CA 94103; Phone: (415) 495-2934

"God must be a Boogie Man." -- Joni Mitchell