At 7:58 AM +0100 on 1/7/01, lcs@... wrote:

>Hi Heather,
>
>I am sure a lot of us would greatly
>appreciate you funneling through to us
>more tidbits you pick up on
>
>comp.sys.mac.programmer.codewarrior
>
>There is just too much volume there
>for most of us to try to follow.
>But it has to be the main clearing house
>programmer tips re toolbox style programming.

I should follow up that I had an additional e-mail from meeroh about 
this.  He said that while Apple recommends using the process manager 
to set the application's directory, Apple will not likely abandon the 
other method.  Because you can manually set a default directory, 
using vRefNum = 0 and parID = 0 might not always point to your 
application's directory.  That is the main reason that using the 
process manager is recommended, it always returns a FSSpec to your 
application.

** Feature request: I'd like to see the C style array and record 
filling format.  When referring to the FSSpec we do it like this:

DIM fileSpec as FSSpec: fileSpec.vRefNum = 0: fileSpec.parID = 0: 
fileSpec.name$ = "a file name"

If we used the C style it could look like this, assuming the same 
variable is declared:

fileSpec = {0, 0, "a file name"}

It certainly looks simple.  It's also used for array data.


>PS.  I would be interested in verified reports
>of instances where the recipe I first came up with
>is invalid AT LAUNCH TIME:
>
>  >> 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?
>  >
>  > DIM PBlk;64
>  > CLS:
>  > WD%=FOLDER("",0): PRINT WD%
>  > FN GETVOL(@PBlk): WD%=PBlk.ioVRefNum%: PRINT WD%
>  > INPUT JK$
>
>Recall that Bob Purves clarified this pointing out (in effect)
>that it is not necessary for the whole block to be blank,
>just PBlk.ioNamePtr&.

According to Inside Mac, it doesn't look like it should matter is any 
of the block is blank or zero.  It does mention that if ioNamePtr is 
_nil then you won't get the default volume name.

I think it is always a good practice to zero out any record blocks 
and then fill in the appropriate data when passing it to a ToolBox 
function.  I've had a few crashes when I have forgotten to do this.

P.S. About that paramBlock record type, I really prefer using the 
true record structure as I have mentioned before.  So I decided to 
try making a proper paramBlockRec.  I found out is wasn't very easy. 
It took me a few days to figure out a proper way to make a union of 
records that don't all overlap evenly.  I found a number of these 
record types and I have created a few new Tlbx include files.  I have 
a Tlbx Files.Incl file that includes all the high and low level file 
manager Toolbox functions.  Using it would require changing a number 
of core runtime files.  This would be a real problem.