Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!rochester!pt.cs.cmu.edu!zog.cs.cmu.edu!tgl
From: tgl@zog.cs.cmu.edu (Tom Lane)
Newsgroups: comp.sys.mac.hypercard
Subject: Re: Deleting Cards Unintentionally
Summary: why not the obvious solution?
Message-ID: <2815@pt.cs.cmu.edu>
Date: 28 Aug 88 02:55:04 GMT
References: <13631@agate.BERKELEY.EDU> <65844@sun.uucp> <16219@apple.Apple.COM>
Sender: netnews@pt.cs.cmu.edu
Organization: Carnegie-Mellon University, CS/RI
Lines: 30

Another means of protection, which I use as much as possible, is to set the
"Can't delete card" bit on every card for which it makes sense (like the
unique control card that E.W. lost).  Even where it doesn't make sense (most
data cards), you should nearly always set the "Can't delete background" bit
to ensure that the background won't go away.

This discussion does bring up a couple of points that Dan Allen and cohorts
ought to think about:

1.  I agree with Elliot Wilen that there should NOT be a shortcut for a
command as destructive as Delete Card, *especially* when (a) no confirmation
is requested and (b) the shortcut is not marked on the menu.
Being able to Undo it is totally inadequate when there is only one level of
undo, because there is no immediate indication that you've deleted a card
rather than just moved to the next card.
I seriously doubt that removing the shortcut would inconvenience many users,
especially since one can easily make a button or otherwise make one's own
shortcut when really necessary.

2.  How come the "can't delete" bit for backgrounds and cards is not a
script-accessible property?  I can envision a background script reading
	on newCard
	  set the undeletable of this card to true
	...

-- 
				tom lane
Internet: tgl@zog.cs.cmu.edu
UUCP: <your favorite internet/arpanet gateway>!zog.cs.cmu.edu!tgl
BITNET: tgl%zog.cs.cmu.edu@cmuccvma