jayn@oakhill.UUCP (12/05/87)
Can anyone tell me how to reconstruct the entire pathname of a file that has been selected with the SFGetFile function? Lets say the file has a full pathname hd:csource:hello.c. Calling SFGetfile only returns a string that says "hello.c". Where can I get the rest of the pathname? Thanks for any help. Jay Norwood
kurtzman@pollux.usc.edu (Stephen Kurtzman) (12/05/87)
In article <1062@oakhill.UUCP> jayn@oakhill.UUCP (Jay Norwood) writes: > >Can anyone tell me how to reconstruct the entire pathname of a file that >has been selected with the SFGetFile function? Lets say the file >has a full pathname hd:csource:hello.c. Calling SFGetfile only returns >a string that says "hello.c". Where can I get the rest of the pathname? >Thanks for any help. >Jay Norwood There is a Hypercard XCMD called "filename" that is floating around. The XCMD does exactly what you are asking about. The version I downloaded from a BBS came with the source code. I believe it was part of the HC development kit from APDA. You may be able to simply adapt that code to fulfil your needs.
tim@hoptoad.uucp (Tim Maroney) (12/09/87)
In article <1062@oakhill.UUCP> jayn@oakhill.UUCP (Jay Norwood) writes: > >Can anyone tell me how to reconstruct the entire pathname of a file that >has been selected with the SFGetFile function? Lets say the file >has a full pathname hd:csource:hello.c. Calling SFGetfile only returns >a string that says "hello.c". Where can I get the rest of the pathname? >Thanks for any help. >Jay Norwood It's pretty easy, provided all the magic numbers involved are clear to you. If not, I'm not going to explain them here, but briefly, there are volume reference numbers, directory ids, and working directory reference numbers. Standard File returns a working directory reference number, which you can convert to a (volume, directory) pair by using PBGetWDInfo, or just grabbing CurDirStore and the other Standard File global (damn, that's embarassing) if you're lazy. Once you have the (volume, directory) pair, you can call PBGetCatInfo to find out what the folder they refer to is named. Then just concatenate that with your reply.fName, and you've got a full pathname. Two HFS traps and a little trivial string twiddling, and it's party time in Mac City. Make sure you're running HFS before you do any of this junk.... -- Tim Maroney, {ihnp4,sun,well,ptsfa,lll-crg}!hoptoad!tim (uucp) hoptoad!tim@lll-crg (arpa)
jv0l+@andrew.cmu.edu (Justin Chris Vallon) (12/11/87)
In <3551@hoptoad.uucp>, Tim Maroney said: >Once you have the (volume, directory) pair, you can call PBGetCatInfo to >find out what the folder they refer to is named. Then just concatenate that >with your reply.fName, and you've got a full pathname. Two HFS traps and a >little trivial string twiddling, and it's party time in Mac City. Now, I'm sure that this will be flamed if incorrect, but doesn't PBGetCatInfo return the directory name, not the path name? In other words, let's say you have a path "HardDisk:Utils:File:ResEdit". The WDRN refers to "HardDisk:Utils:File:", VolRefNum would refer to "HardDisk", and dirId to the folder that "ResEdit" lives in. If you PBGetCatInfo on dirId, the name of the folder is "File", which is almost what you want. Basically, you would have to repeat the GetCatInfo, moving up the tree each time by grabbing the parent's dirId until the dirId becomes 2 which is the root dirId. Some pseudo-code (horrors): pathName := reply.fName convert reply.vRefNum into volRefNum and dirId while dirId <> 2 do (* The file is in a folder, so prepend it's name *) put directory-name from pbGetCatInfo call & ':' in front of path dirId gets the parent's dirId put volume-name from getVolInfo call & ':' in front of path Notice that this could pose a problem if the final path-name is longer than 255 characters (at least in Pascal). Maybe I totally struck out... is it getting warm in here? Did somebody turn up the heat? ----- Justin Vallon/Box 3077/1000 Morewood Avenue/Pittsburgh, PA 15213/(412) 268-4528 Arpa: justin.vallon@andrew.cmu.edu BitNet: justin.vallon%andrew@cmccvb UUCP: ...!{psuvax1, harvard}!andrew.cmu.edu!justin.vallon -----