🚀 go-pugleaf

In article <6923@dartvax.UUCP> earleh@dartvax.UUCP (Earle R. Horton) writes:
>
>I have noticed that when you launch an application by double-clicking
>one of its documents, then do anything that uses Standard File, you
>usually get the folder the document is in, and not the folder the
>application is in.  This indicates to me that either:

Standard File maintains its own idea of the first folder to show when the
dialog is displayed.  This is documented (for HFS) in Inside Mac volume 4.
There are 2 global variables that contain the (true) volume refnum and
dirID of the folder that Std File will show first.

I did an experiment with Finder 5.5 and System 4.1, and found that that
when you open a document the Finder sets these variables itself to
establish the folder that Std File will use initially.

What I did was to double click on a MacWrite document the root of an HFS
volume, with MacWrite in a folder on the same volume.  I used Macsbug's SS
command to break whenever location $398 (one of the Std File variables)
changed.  The variable changed twice during the launch.  I think that the
first time it was set to the folder containing MacWrite and the second time
to the folder containing the document.

I also checked to see if a call to PBHSetVol changed the Std File variables,
and it did not.

>I wrote an application which calls SFGetFile to find an application,
>then launches it.  Named it "Finder" and put it in the system folder,
>booted from the disk.  The folder shown first by SFGetFile is the root
>folder, and not the system folder.  OK so far.  However, when I launch
>an application on another volume (disk) and later quit back to my phony
>Finder, I get the folder containing the application that I launched, and
>not the one my bogus Finder is in.  In this case, ExitToShell appears
>not to change the default volume or directory when launching the "Finder".

When you boot, the Std File variables are not set.  The first time you bring
up Std File, it notices this and defaults to the root of a volume (probably
the current volume).  When you launched the application you used Std File,
which set the variables.  When you brought up Std File again, it used the
same variables and showed the same directory.

You can't tell what the current volume is by looking at the folder that Std
File shows you.  The 2 things are completely different.  ExitToShell does
set the current folder to the one containing the Finder.  (Look at
locations $40F6EC-$40F6F2 of the Mac Plus ROM; this is a call to SetVol
using BootDrive as the parameter.)

>Now, for the most interesting part, the undocumented feature of Launch!
>I claim that you can launch an application by:
>...[using full pathnames]
>
Absolutely true.  Full or partial pathnames are valid in the file system
calls.  The Launch code makes standard file system calls, so full pathnames
are valid there as well.  The Launch code does not change the current
volume, this is done by the Finder.

>I don't recommend launching applications using pathnames, or even using
>any undocumented features, but it does appear to me that one cannot
>always depend on GetVol returning the same folder or WDRefNum that your
>application is in.  It also appears that ExitToShell does not always
>set the default volume to the one the Finder is in, either.

I wouldn't recommend this either.  You should always launch applications by
setting the current volume, because some applications depend on this.  Any
shell-type application that does not set the current volume before a launch
is wrong.

>In any case, the root question remains unsolved.  Does anyone have code
>which will return, guaranteed, the WDRefNum of the folder which the 
>current application is in?

I still argue that you should use the current volume in effect when the
application is launched.  Although there is nothing inherent in the
Macintosh that makes this so, there is a very strong convention that makes
this so.  (The Finder and MPW Shell both do this, and some applications
depend on this fact.)  

If you do not want to use this technique, I think you could call
PBGetFCBInfo (see Inside Mac volume 4) and pass it the application's refnum
(available from a global variable).  

I haven't tried this, but I think it should work based on what is written
in Inside Mac.  This call is NOT in the 64K ROMs, however, and the
documentation says that the format of the file control blocks may change in
the future.

-- 
Larry Rosenstein

Object Specialist
Apple Computer

AppleLink: Rosenstein1
UUCP:  {sun, voder, nsc, mtxinu, dual}!apple!lsr
CSNET: lsr@Apple.com