Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!leah!bingvaxu!sunybcs!rutgers!att!mtuxo!mtgzz!drutx!druco!jon From: jon@druco.ATT.COM (GotowJK) Newsgroups: comp.sys.mac.programmer Subject: Re: Returning Directories with SFGetFile Summary: Whoops - read the Technotes Keywords: SFGetFile,directory,dialog filter,CurDirStore,SFSaveDisk Message-ID: <4070@druco.ATT.COM> Date: 13 Apr 89 12:52:30 GMT References: <4064@druco.ATT.COM> Reply-To: jon@druco.ATT.COM (GotowJK) Distribution: comp Organization: AT&T, Denver, CO Lines: 37 Whoops. In <4064@druco.ATT.COM> I wrote: >I'm writing a little program that needs to prompt the user to select a >directory using SFGetFile. I once saw a DA (Virus Detective) that did >just this, and have a question about how one implements a "Directory" >button. > >Currently, I'm adding a custom "Directory" button to SFGetFile which >allows the user to return the selected directory name. (ie. "Open" >descends into the directory while "Directory" returns with the selected >directory name). My current routine (quite a hack) installs a dialog >filter proc using SFPGetFile. It looks for a hit on the "Directory" >button, returning an "Open" and then a "Cancel" to the SFGetFile filter >proc when it gets one. This effectively descends into the selected > (ETC.) I just went back and read Technote 80 again (very red face :-). In the first few lines, it states that if SFReply.good is false, SFReply.fType contains the ref num of the last selected directory from the SFGetFile box. The above gyrations are not at all necessary. One simply has to look at the reply record to find out what the directory is. I should stop programming late at night - this one walked right by me the first time (practically kicked me in the face, too). Sorry to add traffic to the net. Thanks, Jon Gotow ------------------------------------------------------------------------ Jon Gotow - Physical Designer AT&T Bell Labs General Business Systems Group 200 Laurel Avenue ARPA: jon@druco.att.com Middletown, NJ 07748 UUCP: att!druco!jon Disclaimer: As always, the opinions stated here have nothing whatsoever to do with my employer.