smoke@well.sf.ca.us (Nicholas Jackiw) (10/06/90)
Can anyone give me a hand with some Standard File magic? I'd like to implement an Open All button in the SFGetFile dialog. As usual, this should be dimmed if the currently viewed folder does not contain any files of the appropriate fType. The obvious way to go about this is to have the dialog hook disable the button everytime a new directory appears, and then have the file-filter re-enable it (if the filter is called, obviously there's a file of fType sitting in the directory). Unfortunately, I can't seem to find a reliable method for determining when the directory has changed. Things that I've tried: o Monitoring CurDirStore This changes erratically during directory browsing, but not reliably. o Monitoring SFSaveDisk This doesn't seem to change at all (except perhaps once at the very end of the dialog). o Monitoring theReply.vRefNum This only gets instantiated at the end of the dialog, and is zero before then. o Watching which items the user hits As of IM-IV, the hook will see changes in directory when the user clicks or opens a folder as item#103, and can detect clicks on the Drive button as item#6. However, one can also navigate between directories with cmd-up and cmd-down, and with the pop-up menu of "open" directories. While you can tell when one of these events occur, you can't (based on the item number) tell whether it caused a change in the active directory (and therefore, reason to dim the Open All control). --- I'm a bit befuddled at what should be a straightforward task. In that 7.0 revises Standard File somewhat, I'd like to find a scheme with good chances of surviving the future. Any hints would be appreciated.
tim@efi.com (Tim Maroney) (10/11/90)
In article <21010@well.sf.ca.us> smoke@well.sf.ca.us (Nicholas Jackiw) writes: >Can anyone give me a hand with some Standard File magic? >I'd like to implement an Open All button in the SFGetFile >dialog. As usual, this should be dimmed if the currently >viewed folder does not contain any files of the appropriate >fType. > >Unfortunately, I can't seem to find a reliable method >for determining when the directory has changed. Things >that I've tried: > >o Monitoring CurDirStore > >This changes erratically during directory browsing, but not >reliably. Not according to my experience and to Tech Note #80, which explicitly states that CurDirStore "contains the dirID of the directory that SF is displaying" and that "This information can be particularly useful at hook time". CurDirStore tracks directory changes during Standard File. >o Monitoring SFSaveDisk > >This doesn't seem to change at all (except perhaps once at the >very end of the dialog). Again, this contradicts both my experience and Tech Note #80.
smoke@well.sf.ca.us (Nicholas Jackiw) (10/12/90)
In article <1990Oct10.180515.9025@efi.com> tim@efi.com (Tim Maroney) writes: >In article <21010@well.sf.ca.us> smoke@well.sf.ca.us (Nicholas Jackiw) writes: >>Unfortunately, I can't seem to find a reliable method >>for determining when the [SFGetFile] directory has changed. Things >>that I've tried: >> >>o Monitoring CurDirStore >> >>This changes erratically during directory browsing, but not >>reliably. > >Not according to my experience and to Tech Note #80, which explicitly >states that CurDirStore "contains the dirID of the directory that SF >is displaying" and that "This information can be particularly useful >at hook time". CurDirStore tracks directory changes during Standard >File. > >>o Monitoring SFSaveDisk >> >Again, this contradicts both my experience and Tech Note #80. Thanks, Tim--you're right, of course. (Finding TN#80 a few days back put me on to the real problem.) The reason my hook was detecting changes in these values "erratically" was that update events were pending. In that the Toolbox Event manager was continually re-posting these updates instead of sending nullevents, the first event that my hook saw after a directory change was the next user-caused event, which could be a file select, a button click, or yet another directory change. Processing pending updates before invoking SFGetFile fixed the problem. Now, however, I've had to switch to SFPGetFile, so that I actually see events (instead of dialogHook pseudo-events), because screen savers, etc., may post updates even after GetFile is invoked. -- --- * --- Nicholas Jackiw Smoke@well.sf.ca.us | Jackiw@cs.swarthmore.edu Key Curriculum Press, Inc. Applelink: D3970 | (415) 548-2304 --- * ---