Mark G wrote:
> 
> The folllowing fn works when I omit the directory name, but
> tells me that it can't find the directory when I do in fact
> supply the directory name.  This is puzzling.  Could someone
> please explain why the PBOPENWD function works this way?

My interpretation of Inside Mac's description is this: If you don't specify
the directory name (i.e. if you pass a pointer to an empty string in
ioNamePtr&), then PBOPENWD uses only the values in ioVRefNum% and ioWDirID& to
determine which directory you mean (in your case, you implicitly set
ioVRefNum% to zero, which indicates "the default volume").

But if ioNamePtr& points to a non-empty string, then PBOPENWD assumes that the
string names a directory that's *within* the directory indicated by ioVRefNum%
and ioWDirID&.

Example: suppose the values ioVRefNum%=0 and ioWDirID&=234 indicate a
directory whose name is "baseball".  Then if you set up the parameter block
like this:

  dirName$ = ""
  pb.ioVRefNum% = 0
  pb.ioWDirID& = 234
  pb.ioNamePtr& = @dirName$

then PBOPENWD will correctly find the "baseball" directory.  But if instead
you do this:

  dirName$ = "baseball"
  pb.ioVRefNum% = 0
  pb.ioWDirID& = 234
  pb.ioNamePtr& = @dirName$

then PBOPENWD will try to find (another) directory named "baseball" located
*inside* the (correct) "baseball" directory.  Chances are there won't be an
inner "baseball" inside the outer "baseball," so PBOPENWD will fail.

I think the ioNamePtr& parameter should not be used unless you know the
ioWDirID& of some outer directory plus the relative path name of some other
directory *within* ioWDirID&.

Also, although it's not documented in I.M., my guess is that you can point to
a *full* pathname in ioNamePtr& and in that case ioVRefNum% and ioWDirID& will
be ignored and the full pathname alone will be used to identify the directory.
 I haven't tried that, but virtually all of the "PB" File Manager routines
seem to work that way.

Hope this helps.
- Rick