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"