lulue@manta.NOSC.MIL (Dan Lulue ) (12/13/89)
I need to save the location of a data file from one launch to another.
The user points out the file's location via Std File, and my program
"remembers" it for the next time. I am constrained to using UNIX sytle
string pathnames. Is it preferable to save the string in a 'STR ' resource in
application's resource fork, or in the data fork? I tried the resource fork by
creating a 'STR ' resource, doing a GetString (which does a
GetResource('STR ',ID), changing the string pointed to by the
handle, calling ChangedResource, then WriteResource, etc. However,
the new string never shows up in the resource fork (ResEdit view) after
execution (the dummy string I placed there originally is still there).
The 'STR ' resource was not purgable, but I called SetResPurge
anyway, along with several other things suggested by Chernicoff to
prevent the changed resource data from disappearing before being
written.
Chernicoff also suggests that the data fork is a good place to store
this sort of data. Does opening the data fork of the running
application mean doing an FSOpen on the application? If so, how does
one get the vRefNum of the directory the application resides in?
Any tips would really be appreciated.
Thanks,
Dan Lulue
lulue@nosc.mil6600pete@hub.UUCP (12/13/89)
From article <975@manta.NOSC.MIL>, by lulue@manta.NOSC.MIL (Dan Lulue ): > I need to save the location of a data file from one launch to another. > The user points out the file's location via Std File, and my program > "remembers" it for the next time. I am constrained to using UNIX sytle > string pathnames. Is it preferable to save the string in a 'STR ' resource in > application's resource fork, or in the data fork? Neither. If you ever want your application to run on a network server, you can't do this, because the resource manager doesn't know about multiple simultaneous users. The file manager (data fork strategy) knows, but you don't want to use it, because the user wouldn't be able to count on settings lasting if the app lived on a server. (Plus, you'd have to do record locking for one little config string, and it would be a pain.) A better way to do this is to save a settings file in the System Folder. You can find out where that is with SysEnvirons. > I tried the resource fork by creating a 'STR ' resource, doing a GetString > (which does a GetResource('STR ',ID), changing the string pointed to by the > handle, calling ChangedResource , then WriteResource, etc. However, > the new string never shows up in the resource fork (ResEdit view) after > execution (the dummy string I placed there originally is still there). GetResource, LoadResource (depending on various settings), HNoPurge, make your change, ChangedResource, WriteResource, HPurge. This sequence is covered in IM I under ChangedResource. > Chernicoff also suggests that the data fork is a good place to store > this sort of data. Chernicoff's getting old. Do you have the second edition? Or am I thinking of another series of books? Somebody? > how does one get the vRefNum of the directory the application resides in? Do a GetVol on startup. You'll get a working directory refNum. ------------------------------------------------------------------------------- Pete Gontier | InterNet: 6600pete@ucsbuxa.ucsb.edu, BitNet: 6600pete@ucsbuxa Editor, Macker | Online Macintosh Programming Journal; mail for subscription Hire this kid | Mac, DOS, C, Pascal, asm, excellent communication skills