nick@lfcs.ed.ac.uk (Nick Rothwell) (04/24/89)
I have a couple of questions, brought up by a recent project I've been
putting together:
(i) Scrap Management. I've implemented CUT/COPY/PASTE/CLEAR (together
with UNDO and REDO for all of these... it wasn't easy...). But,
I'm only interested (for now) in cutting and pasting my own private
kinds of objects. So, I've done it myself, with a couple of Handles
for the clipboard and such like. Is there anything wrong with this?
Why should I use the scrap manager for things which aren't TEXT or
PICT, and therefore don't make sense for anybody else?
(ii) User preferences: what's the official sanctioned way of saving user
preferences in an application? A data file in the System Folder? A
resource file? The data fork of the application? I personally prefer
this last option, although it won't work on shared or protected
volumes.
Nick.
Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh.
nick@lfcs.ed.ac.uk <Atlantic Ocean>!mcvax!ukc!lfcs!nick
~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~
Fais que ton reve soit plus long que la nuit.oster@dewey.soe.berkeley.edu (David Phillip Oster) (04/26/89)
In article <1833@etive.ed.ac.uk> nick@lfcs.ed.ac.uk (Nick Rothwell) writes: >(i) Scrap Management. I've implemented CUT/COPY/PASTE/CLEAR (together > with UNDO and REDO for all of these... it wasn't easy...). But, > I'm only interested (for now) in cutting and pasting my own private > kinds of objects. So, I've done it myself, with a couple of Handles > for the clipboard and such like. Is there anything wrong with this? > Why should I use the scrap manager for things which aren't TEXT or > PICT, and therefore don't make sense for anybody else? If you externalize your scrap, and use the scrap manager, even if it is a private type, the user can save scraps on the scrapbook. That can be very convenient for the user. By rights, you should put a dual representation on the scrapbook: a TEXT, say, and your private type. That way the user can see some difference between two scraps from your program. >(ii) User preferences: what's the official sanctioned way of saving user > preferences in an application? A data file in the System Folder? A > resource file? The data fork of the application? I personally prefer > this last option, although it won't work on shared or protected > volumes. A file, either data or resoruce, that you find using poor-man's-search-path, is the recommended way to go. That way, if you're application has been marked read only, and is being shared over a net, each user can have their own preferences in their own system folder. Or, you can encourage users to double click on "Stationery" files. This solution is better, since it allows the user the effect of multiple preferences files (say two people share one mac.) --- David Phillip Oster --"Bush says he wants to be our 'education' Arpa: oster@dewey.soe.berkeley.edu --president. Well, He's our most intellectual Uucp: ucbvax!oster%dewey.soe.berkeley.edu --president in 8 years."--Swaine
nick@lfcs.ed.ac.uk (Nick Rothwell) (04/27/89)
In article <28905@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: >If you externalize your scrap, and use the scrap manager, even if it is a >private type, the user can save scraps on the scrapbook. That can be very >convenient for the user. By rights, you should put a dual representation >on the scrapbook: a TEXT, say, and your private type. That way the user >can see some difference between two scraps from your program. I also got this suggestion from Dave Platt. I love it! So, I can invent a small PICT or something which essentially "iconises" the scrap. Nice. Do other applications do things this way? (I'll have to give it a try with Performer...) >A file, either data or resoruce, that you find using poor-man's-search-path, I presume you mean a hard-wired path like "::System Folder:Config" or something... >... Or, you can encourage users >to double click on "Stationery" files. This solution is better, since it >allows the user the effect of multiple preferences files (say two people >share one mac.) Again, a nice idea... Many thanks to those who've replied. >--- David Phillip Oster Nick. Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick@lfcs.ed.ac.uk <Atlantic Ocean>!mcvax!ukc!lfcs!nick ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ Fais que ton reve soit plus long que la nuit.
oster@dewey.soe.berkeley.edu (David Phillip Oster) (04/28/89)
In article <1867@etive.ed.ac.uk> nick@lfcs.ed.ac.uk (Nick Rothwell) writes: >I also got this suggestion from Dave Platt. I love it! So, I can >invent a small PICT or something which essentially "iconises" the >scrap. Nice. Do other applications do things this way? (I'll have to >give it a try with Performer...) Deluxe Music Construction Set, among other does this: you can paste music into the scrapbook, what you see is the sheet music, but if you paste it back into DMCS, you can hear it too. > >>A file, either data or resoruce, that you find using poor-man's-search-path, >I presume you mean a hard-wired path like "::System Folder:Config" or >something... No, don't do anything that perverse. Just FSOpen(), OpenResFile(), or OpenRFPerm() the file normally. If the system can't find it in the current folder, it will look in the System Folder. Incidently, Stuffit 1.5.1 has a bug with this: if you try to extract a file that happens to have the same name as a file in your system folder, StuffIt asks you if you want to replace the old one, even though the old one is never touched. --- David Phillip Oster --"When we replace the mouse with a pen, Arpa: oster@dewey.soe.berkeley.edu --3 button mouse fans will need saxophone Uucp: {uwvax,decvax}!ucbvax!oster%dewey.soe.berkeley.edu --lessons." - Gasee
ech@pegasus.ATT.COM (Edward C Horvath) (04/28/89)
From article <1867@etive.ed.ac.uk>, by nick@lfcs.ed.ac.uk (Nick Rothwell): > In article <28905@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: >>A file, either data or resoruce, that you find using poor-man's-search-path, > I presume you mean a hard-wired path like "::System Folder:Config" or > something... No, don't use hardwired pathnames if you can avoid it. The PMSP is not a convention, it's documented in various TechNotes, but see especially TN 77 (others: 69, 101, 214). The PMSP is used when you use an ioVRefNum of 0 to an _Open trap, and searches the default directory (usually the AppRefNum, unless you've called SetVol), the BootDrive (0x210) and the Blessed folder (as reported by SysEnvirons) in that order. =Ned Horvath=
sagen@nucthy.physics.orst.edu (Milt Sagen) (04/29/89)
In article <28956@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: >Just FSOpen(), OpenResFile(), or OpenRFPerm() the file normally. If the >system can't find it in the current folder, it will look in the System >Folder. Incidently, Stuffit 1.5.1 has a bug with this: if you try to Won't OpenResFile only look in the System Folder if it exists on the current volume, which in these days of partitioned hard disks, is often not the volume that contains the SF? Milt Sagen Internet: sagen@nucthy.physics.orst.edu Department of Physics Oregon State University Corvallis, OR 97331 Tele: (503) 754-4631
svc@well.UUCP (Leonard Rosenthol) (05/01/89)
In article <28956@ucbvax.BERKELEY.EDU>, oster@dewey.soe.berkeley.edu (David Phillip Oster) writes: > In article <1867@etive.ed.ac.uk> nick@lfcs.ed.ac.uk (Nick Rothwell) writes: > > >>A file, either data or resoruce, that you find using poor-man's-search-path, > >I presume you mean a hard-wired path like "::System Folder:Config" or > >something... > > No, don't do anything that perverse. > Just FSOpen(), OpenResFile(), or OpenRFPerm() the file normally. If the > system can't find it in the current folder, it will look in the System > Folder. > If I were you, I would NOT rely on the PMSP (poor man search path) as I would assume that it will disappear in the future (it is SUCH A HACK!). Instead why not use SysEnvirons to get the blessed Folder's RefNum (from field sysVRefNum) and then do a SetVol to get to that volume (don't forget to save the previous volume and restore it when done!) This will make you code a LOT MORE compatible in the future should things like the PMSP disappear - it also makes it more intuitive as to what you are ACTUALLY doing! -- +--------------------------------------------------+ Leonard Rosenthol | GEnie : MACgician Lazerware, inc. | MacNet: MACgician UUCP: svc@well.UUCP | ALink : D0025