At 12:56 PM +0100 on 12/28/00, lcs@... wrote:


>Here WDN = WDRN = "working dir ref no"
>
>I asked:
>
>  > How best to get the WDN of the app's folder under
>  > the mini-runtime of FB2 (and equally under the
>  > tech runtime of FB^3)??
>
>Well, FN GETVOL *seems* to work with a blank
>64 byte param block.  Will it always work?
>Might it not sometimes give a volume no
>rather than a WDRN?

This is what IM says:
The PBGetVol function returns, [...] If a default directory was set 
with a previous call to PBSetVol, [...] its working directory 
reference number is returned in ioVRefNum. However, if, in a previous 
call to HSetVol (or PBHSetVol), a working directory reference number 
was passed in, PBGetVol returns a volume reference number in the 
ioVRefNum field.

Sounds iffy.

I would call GetCurrentProcess and then GetProcessInformation.  The 
returned record contains a FSSpec for the process.  The whole idea of 
working directories should be abandoned in favor of FSSpec.  I 
imagine this won't work under FBII

 From IM:Files

Working directories were developed to allow applications written for 
the now-obsolete Macintosh file system to execute correctly when 
accessing volumes using the hierarchical file system. In general, 
your application should not create working directories and, in the 
few instances a working directory reference number is returned to 
your application, it should immediately convert that number to a 
volume reference number and directory ID.

( You would use the Toolbox function GetWDInfo to convert the WD 
number to volume and dir ID.  Problem is, that there is a TBAlias 
with the same name.  I also think TBAlias should be abandoned, what's 
so hard about using search and replace?  If not abandoned then how 
about an Override like function? )

Heather