kent@lloyd.camex.uucp (Kent Borg) (06/09/89)
(I have this sneaking feeling that this has been hashed over recently and I didn't notice because I didn't know I needed to know...if so, apologies.) In the hook routine for SFPGetFile I can find out the name of the currently highlighted file by looking at reply.fName. So far, so good. My problem is that I don't know how to find out what directory it is in. No, reply.vRefNum doesn't seem to get updated until the user clicks `Open'. Sure, I *could* wait until then, but I want to find out from within the hook routine--while the dialog is up. I tried looking at myParmBlkPtr->ioVRefNum from my file filter routine, but that info seems to track the actual volume and not the HFS directory. Any ideas? Something that won't break with 7.0 Aliases, etc? If this isn't possible (nah, must be) could you folks at Apple (you are listening, aren't you?) change SFPGetFile so it *will* update reply.vRefNum on the fly? Thanks. Kent Borg kent@lloyd.uucp or ...!husc6!lloyd!kent
zben@umd5.umd.edu (Ben Cranston) (06/10/89)
In article <414@lloyd.camex.uucp> kent@lloyd.UUCP (Kent Borg) writes: > In the hook routine for SFPGetFile I can find out the name of the > currently highlighted file by looking at reply.fName. ... > I don't know how to find out what directory it is in. > reply.vRefNum doesn't seem to get updated until the user clicks `Open'. > I want to find out from within the hook routine--while the dialog is up. I think you're out of luck here. Standard File doesn't even make the working directory until the very end. While it is running it is using the Directory ID stuff (see Inside Mac, Volume IV, top of page 92). The Directory ID of the current directory is stored at -616(A6) in Standard File's stack frame, but it would be a bad mistake to rely upon this information. Seems to me it would be a bit expensive to create and destroy working directories everytime you move around, which is what Standard File would have to do to update SFReply.vRefNum on the fly. Still, the Macintosh is ABOUT doing the right thing for the user, even though it's a little expensive. If we cared that much about expenses we would still be using 40x12 upper case only ADM3 terminals (or model 29 teletypes or something). Is there still anybody at Apple with this vision, or did the unix types chase them out? N.B. The way I read the code Standard File only creates a working directory if the file is down in the hierarchy. If the file is at the very top level it returns a real VRefNum for the volume. This should work in all cases, except perhaps doing a PBGetWDInfo on it. I suppose the file system could return the same volume and directory ID 2, but what would it dummy up for ioWDProcID? -- Ben Cranston <zben@umd2.UMD.EDU> (Kingdom of Merryland UniSys 1100/92) Copyright 1989 (you may redistribute ONLY if your recipients can).
kent@lloyd.camex.uucp (Kent Borg) (06/11/89)
In article <4993@umd5.umd.edu> zben@umd5.umd.edu (Ben Cranston) writes: >In article <414@lloyd.camex.uucp> kent@lloyd.UUCP (Kent Borg) writes: > >> In the hook routine for SFPGetFile I can find out the name of the >> currently highlighted file by looking at reply.fName. ... >> I don't know how to find out what directory it is in. ... >I think you're out of luck here. Standard File doesn't even make the working >directory until the very end. While it is running it is using the Directory >ID stuff (see Inside Mac, Volume IV, top of page 92). The Directory ID of >the current directory is stored at -616(A6) in Standard File's stack frame, >but it would be a bad mistake to rely upon this information. Tim Maroney sent me mail and tech note 80 agrees (as I suspect does the Standard File chapter of IM-IV--but I don't have it in front me right now): the dirID is in the low memory global CurDirStore and the negative of the volume reference number is stored in SFSaveDisk. My fear that I was either asking a question that had just been discussed or one that has an obvious answer if I only looked in the right place, was doubly borne out. Sorry to add to the noise (red face), will look much more carefully next time. Thanks. Kent Borg kent@lloyd.uucp or ...!husc6!lloyd!kent
zben@umd5.umd.edu (Ben Cranston) (06/14/89)
In article <418@lloyd.camex.uucp> kent@lloyd.UUCP (Kent Borg) writes: > My fear that I was either asking a question that had just been > discussed or one that has an obvious answer if I only looked in the > right place, was doubly borne out. Sorry to add to the noise (red > face), will look much more carefully next time. > kent@lloyd.uucp I was fixated on the working directory question and did not read the original posting well enough. Sorry. As both Tim Maroney and Larry Rosenstein state, the Directory ID from -616(A6) is moved to CurDirStore when Standard File is examining the volume for locked and read-only and such. I usually follow up on these things by electronic mail, but I'm off on the Internet and not directly on uucp, so these *.uucp addresses are just not realiable from here. I'm sorry for the clutter. Offhand, though, I would think these technical questions are a LITTLE more relevant to a *.programmers newsgroup than legal discussions of contract clauses or tabloidal stories about stolen source code. In any case this is a fine newsgroup and I'm glad its available. "When source is outlawed, only outlaws will have source..." -- Ben Cranston <zben@umd2.UMD.EDU> (Kingdom of Merryland UniSys 1100/92) Copyright 1989 (you may redistribute ONLY if your recipients can).