On Mar 20, 2011, at 06:28, Brad Stone wrote: > After sleeping on it my choices are to remove the encryption feature or make > a big ugly dialog box warning the user if they encrypt a file that's open > they will lose their changes. Neither of these approaches are optimum.
On Mar 20, 2011, at 10:13, Brad Stone wrote: > Actually, the users are shown files in a NSTableView and they select a menu > to encrypt/decrypt. That's where I'll warn them. I think you can do better than a big ugly dialog. First of all, keep in mind that what you'll be encrypting will be the (currently open) document file *at the time of its last save*. A lot of users learn, perhaps the hard way, to save often, though of course some won't do that. They're not really going to "lose" anything anyway, so it's not quite as dire as your choice of words suggests. :) Second, if you're providing a list, you'll have to make sure that you know where to find the *current* (i.e. last saved) version of the file, in case the file gets saved since the list was constructed. In many cases, the file system identity of the file is preserved by the end of the save process**, although the details are going to vary by application. Presumably you'll have some kind of alias or URL bookmark to get this right. Third, you need to figure out how you're going to avoid encrypting the wrong thing, if there happens to be a save in progress when your application starts an encryption pass. Saves have multiple file-handling steps, which take human-measurable time, and things are not in a consistent state until they're done. Fourth, and this was really my point, if you put an extra column in your table view that shows when the file was last saved, preferably in a minimalist way like "10 minutes ago" or "yesterday" rather than with a numerical date/time, and have it update in real time, chances are it's going to be obvious enough to the user's natural intelligence that what's going to be saved doesn't include unsaved changes. It's possible that the scenario you were afraid of won't occur in practice, if you provide subtle-enough user interface cues. (Maybe showing when it was last saved *isn't* the answer -- I'm just suggesting the kind of thinking that might solve your problem.) ** There are three basic approaches to save, in decreasing order of safety: 1. Save to a temporary file, then use FSSwapObjects at the end. 2. Save to a temporary file, then rename files at the end. 3. Update the original file directly. A standard NSDocument uses, I would hope, #1 (or something equivalent to it). NSPersistentDocument with a SQL store uses #3, but it's safer than it sounds because it's a SQL store. I wouldn't be surprised if Word uses #2, since that's the more archaic technique, but I really don't know. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
