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 19, 2011, at 11:04 PM, Brad Stone wrote: > I do need it to work for any app, not just Word or XL. > > I guess a poor workaround would be since it's not possible to reliably check > if the file is open I can force the user to quit the file's default app > before allowing them to encrypt. It's just kind of heavy-handed. > > On Mar 19, 2011, at 6:20 PM, Charles Srstka wrote: > >> On Mar 19, 2011, at 1:40 PM, Conrad Shultz wrote: >> >>> On 3/19/11 11:10 AM, Kyle Sluder wrote: >>>> On Sat, Mar 19, 2011 at 9:13 AM, Conrad Shultz >>>> <con...@synthetiqsolutions.com> wrote: >>>>> Note that this will only capture files that are properly opened (i.e. >>>>> fopen()'d), so you won't catch every apparently open file. For example, >>>>> if you open a file in vi(m), it creates a hidden scratch file in the >>>>> same directory and closes the original file. You then edit the scratch >>>>> file, which is only written out to the original file on save. In this >>>>> way, the original file is protected from damage due to a crash, but lsof >>>>> will almost never show it as being open. >>>> >>>> This is also how Cocoa apps work. They only keep the file open to read >>>> its contents. >>>> >>>> I'm afraid that what Brad wants to do is not possible yet. >>> >>> Are you certain that is a general behavior? >> >> Just looking at NSDocument’s default hooks for opening/saving files will >> show you the answer to that. The ones the user is encouraged to use in the >> general case read the file into an NSData object on open, and write an >> NSData out to the file on save. >> >> Charles_______________________________________________ >> >> 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/cocoa-dev%40softraph.com >> >> This email sent to cocoa-...@softraph.com > > _______________________________________________ > > 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/cocoa-dev%40softraph.com > > This email sent to cocoa-...@softraph.com _______________________________________________ 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