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: INIT getting it's file name...
Message-ID: <8876@hoptoad.uucp>
Date: 1 Nov 89 17:52:56 GMT
References: <56505@tiger.oxy.edu> <4020@helios.ee.lbl.gov> <14362@well.UUCP> <8851@hoptoad.uucp> <14385@well.UUCP>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Eclectic Software, San Francisco
Lines: 52

In article <14362@well.UUCP> svc@well.UUCP (Leonard Rosenthol) writes:
>	I don't know what all this mess is about searching the System Folder,
>etc. as that is a REAL PAIN,

In article <8851@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
>The File Manager
>makes it tremendously easy, by using indexed files with PBGetFInfo.

In article <14385@well.UUCP> svc@well.UUCP (Leonard Rosenthol) writes:
>I did not meant that
>coding a search of the System Folder is difficult, it is certainly not. However
>many people out there (myself included) have LOTS of files in the System Folder
>(many of which are prefs, unused INITS, etc.) and it takes TIME to do the
>search each and every time the user invokes your INIT.

Well, we still don't know how often the INIT is getting called, so it's
hard to say how significant this will be.  I think it should be noted
that due to the efficiency of the B*-tree structures employed,
directory operations on the Mac are generally very fast.  I think it's
silly to have more than 100 files in your system folder, and I doubt
that scanning through that many would take a humanly noticeable time.
But this is something the implementor of the INIT can easily test.

>	It is true that this does not provide for renaming on the fly, but it
>does provide for non-hardcoding names so that it could be renamed before use
>or by turning it off, renaming and turning it back on - not the greatest BUT
>much better than hardcoding!!

Not if you put yourself in the place of the user.  Let's say you rename
the file, and the INIT suddenly stops functioning.  What is the natural
conclusion, the one conclusion that most users are likely to come to?
Right -- that you aren't allowed to rename the INIT.  So they change
it back.

>	It appears to me that a combination of our two methods would be the best
>bet.  First the INIT checks for the values it stored at startup with the 
>PBGetFCBInfo and GetVol calls - if the file with that info does not exist then
>it can perform a search to find it based on the creator - HOWEVER the search
>could possibly be two-fold.  The search should start in the vRefNum returned by
>GetVol, and if that value is NOT the same as mySysEnvRec.sysVRefNum then the
>System Folder should also be searched in case the user moved it.
>	How's that for an all purpose, and cover most/all cases solution?!??!?

Sounds good to me!  Shouldn't be too much code, either.
-- 
Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com

"He goes on about the wailing and gnashing of teeth.  It comes in one
 verse after another, and it is quite manifest to the reader that there
 is a certain pleasure in contemplating the wailing and gnashing of
 teeth, or else it would not occur so often."
	-- Bertrand Russell, "Why I Am Not a Christian"