mesard@bbn.com (Wayne Mesard) (04/03/89)
Last week I asked in <37794@bbn.COM>: 1) [Why don't mouse hits get generated for controls which I add to SFGetFile's dialog in the firstTime block of my dialog hook? Should I just do it the way TN47 does?] 2) [Can I hack SFGetFile so that the user can shift-click and command-click in the file list?] W.r.t (1): The consensus was it can be done, but one must load the DITL before calling SFGetFile, because by the time the dialog hook gets its hands on it, the Dialog manager has already counted the number of items in it. TN47 is the wrong approach for the reasons that I mentioned. (Compatability with future changes to SFGetFile; and the principle of rebuilding Rome, just to add a new side street, as t'were.) (2): SFGetFile does not, in fact, use the list manager, and there's no way to get it to do what I want. Several people have written, or are writing, the next-best-thing: routines which accumulate a list of all the files clicked on, all the items in a folder, etc. into other windows (cf. StuffIt) or into a user item in the SFGetFile dialog. Thanks to all who responded. -- unsigned *Wayne_Mesard(); "Get that OUT of your signature file!" MESARD@BBN.COM -DB. BBN, Cambridge, MA
tim@hoptoad.uucp (Tim Maroney) (04/07/89)
In article <38158@bbn.COM> mesard@BBN.COM (Wayne Mesard) writes: >Last week I asked in <37794@bbn.COM>: >1) [Why don't mouse hits get generated for controls which I add to >SFGetFile's dialog in the firstTime block of my dialog hook? Should I >just do it the way TN47 does?] > >W.r.t (1): The consensus was it can be done, but one must load the DITL >before calling SFGetFile, because by the time the dialog hook gets its >hands on it, the Dialog manager has already counted the number of items >in it. TN47 is the wrong approach for the reasons that I mentioned. >(Compatability with future changes to SFGetFile; and the principle of >rebuilding Rome, just to add a new side street, as t'were.) Uh, why don't you just use your own DITL by calling SFPGetFile? Adding items to a dialog at run time is a crock, in my opinion. There are a few places where you can't get around it, but where you can avoid this tricky business, you should. It was to address exactly this problem that the SFPGetFile routine with its dialog id argument was created. You want compatibility? This has been documented since volume 1. I didn't see the original message, so forgive me if there's some strange reason you can't do this.... >2) [Can I hack SFGetFile so that the user can shift-click and >command-click in the file list?] > >(2): SFGetFile does not, in fact, use the list manager, and there's no >way to get it to do what I want. Several people have written, or are >writing, the next-best-thing: routines which accumulate a list of all >the files clicked on, all the items in a folder, etc. into other windows >(cf. StuffIt) or into a user item in the SFGetFile dialog. Accumulating a list of files in a folder into a List Manager ListHandle is a trivial loop using the file index feature of PBHGetFInfo. I think that handling the folder and volume items would be slightly more difficult because they're more complex to draw and track. I wrote one of the first multiple file selection dialogs some five years ago, under MFS, using the multiple selection feature you suggested (and managing my own list -- this was before the List Manager). It's not the best way to do it, because all the files you select have to be in one volume and one folder. You'd want to be able to select files from all over the place, usually. Also, allowing multiple selection in Standard File is likely to confuse users, since it's a change in the standard interface. There are two better ways to do it. First, use a standard file dialog and just call it over and over until the user clicks "Cancel" (which you should rename to Done). This accumulates the files into a list stored in some other window. See the "Add..." item in Lightspeed C for an example. The second way is to keep the list in the standard file dialog itself, below the rest of the items, as in some of the Commando interfaces in MPW. You fake up the buttons so that a click on "Add" will place the file in the list of accumulated files. There are a few other bells and whistles you should add as well, like a "Remove" button to remove a file from the accumulated list if it was added in error. As a power user, I prefer the latter, and it's not hard to program this approach. I did this for the "Print Files...." command in TOPS Terminal and it was actually kind of fun. Unfortunately, it is probably more confusing to a naive user than the former approach. The absolute best way would be to implement both and let a user preference govern which is used at run time. There's an amusing anecdote concerning the original multiple file selection dialog I wrote at CMU. I wasn't sure of the best interface, so I talked about it on the network. People were nearly unanimous that shift-click should provide discontiguous selections for the list; that is, shift-click on a name and that name is added to the selections, but no others are. This was supposedly so that I would adhere to the user interface standard. I pointed out that according to volume 1 chapter 2, the list was a "one dimensional text array" and shift-click was supposed to mean "extend selection range", not "discontiguous select". The discontiguous selection was supposed to be done by command-clicking instead. Everyone thought this was completely ridiculous, where was I getting this stuff, they lectured me on how I didn't understand the importance of adhering to standards, obviously shift-click ought to work as they wanted it to, etc. Somewhat later the List Manager came out. Guess what: the way it interprets the keyboard modifiers is exactly what I had deduced from the user interface guidelines. Command-clicking does discontiguous select, while shift-click expands the selection range. If you're ever worried because the whole net community seems to be on your case, just remember this anecdote. It really does happen sometimes that "everyone is out of step but me". -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "Satanic is merely the name they give to the behavior of those who would disrupt the orderly way in which men want to live." -- Gabrielle, THE VAMPIRE LESTAT, Anne Rice