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: File Manager question
Message-ID: <8334@hoptoad.uucp>
Date: 18 Aug 89 19:45:27 GMT
References: <15088@dartvax.Dartmouth.EDU>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Eclectic Software, San Francisco
Lines: 81

In article <15088@dartvax.Dartmouth.EDU> xxiaoye@eleazar.dartmouth.edu
(Xiaoxia Ye) writes:
>I am fairly new to Mac Programming.  The other day I tackled the
>dreaded IM IV File Manager section because I am writing an application
>that need to save some preference parameters.  There are a number of
>ways that I can think of solving this problem, but I can find a
>solution or a safe solution to this:
>
>1)  Saving the preferences in the data fork of the currently running
>application.

Don't do it.  You are making yourself gratuitously incompatible with
network file servers and the rumored multiuser Macintosh.  Never write
to the data or resource fork of your application file; treat it as
read-only in all cases.

>Question:  How do I get the refNum, vRefNum of the currently running
>application?  Here is a naive question: is the refNum for the resource
>fork the same for the data fork ?  I can get the refNum from
>CurResFile() from resource manager, but can I use it for FSWrite to the
>data fork of the currently running application?  What about the vRefNum?
>Can I simply pass '0' to stand for default working folder?  What happens
>when the default working folder changes ?

Might as well answer these, even though they're moot.  The refnums are
different.  If you wanted to get the refnum of the data fork of a file,
you would have to call PBOpen or PBHOpen.  The refnums for resource
forks come from PBOpenRF and PBHOpenRF; the refnums for data forks come
from PBOpen and PBHOpen.  As for volume zero, I hardly ever use it any
more, but if you want to, you can.  It's set to be the volume and
folder of the application file when the application is launched, and
provided you don't do PBSetVol's yourself, it shouldn't change.  Notice
that volume 0 is completely unrelated to Standard File's idea of the
current directory.

>2) Saving the preferences in a file in the currently blessed system
>folder.
>
>Question:  How do I get the vRefNum of the current system Folder ?

Fortunately, SysEnvirons will return it for you, as long as all you
want is a working directory reference number (which pretends to be
a volume reference number) rather than a volume number/folder number
pair.  Here's how I do it:

short GetSysWD()
{	SysEnvRec theWorld; SysEnvirons (1, &theWorld);
	return theWorld.sysVRefNum;
}

>3) Saving the preference in a file in the same folder as the application
>is in.
>
>Question:  Similar question as in 1, how can I be sure that the default
>working directory will not be changed ? is passing '0' as vRefNum always
>safe?

The system folder solution is the one everyone else uses, so you really
ought to do the same to avoid confusing the user.

It is remotely possible that when your application is launched, volume
0 will not be the application's folder.  The reason is that the _Launch
trap doesn't do this, the Finder does.  If your application was
launched from non-Finder software, it may have its own
oh-so-very-clever ideas about where volume 0 should be.  Presumably,
the person doing this strange launching is a power user and can cope
with the consequences, but even so....  You can always do a
PBGetFCBInfo on the application resource file refnum to determine
exactly where the file resides if you like.

>Well, I have only read the High level routines in the File Manager
>section of IM IV, should I read the low level routines too ?

Yes, afraid so.  You can skip "Data Organization on Volumes", though.

Hope this helps....
-- 
Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com

"Conversion, fastidious Goddess, loves blood better than brick, and feasts
 most subtly on the human will." - Virginia Woolf, "Mrs. Dalloway"