Thanks all for the input. I ended up keeping file wrappers for the
expensive parts of the bundle, invalidating them when an action takes
place, and that has brought the save time down to an acceptable level in
most cases.
John
--
John Brownie, john_brow...@sil.org or j.brow...@sil.org.pg
Summe
___
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:
https://lists.apple.co
On Jun 20, 2014, at 16:44 , John Brownie wrote:
> I have a complex document bundle, and I'm trying to figure out which files
> within the package have unsaved changes, and it looks like there's no support
> for that model in NSDocument.
I haven’t been following this thread very closely, so I m
Jerry Krinock wrote:
On 2014 Jun 19, at 22:15, John Brownie wrote:
Looks like I need to keep a local flag for when the document gets changed and
when it gets saved.
No, you can just use -[NSDocument isDocumentEdited].
Back when Auto Save first appeared, in OS X 10.7, I too found that it was
On 2014 Jun 20, at 10:53, Kyle Sluder wrote:
> As per the documentation, the first thing that -[NSDocument
> autosaveWithImplicitCancellability:…] does is send
> -hasUnautosavedChanges to itself and bail if that method returns NO.
I don’t know, Kyle. Indeed, I’ve done more than my share of pu
On Fri, Jun 20, 2014, at 10:33 AM, Jerry Krinock wrote:
>
> On 2014 Jun 19, at 22:15, John Brownie wrote:
>
> > Looks like I need to keep a local flag for when the document gets changed
> > and when it gets saved.
>
> No, you can just use -[NSDocument isDocumentEdited].
>
> Back when Auto Sav
On 2014 Jun 19, at 22:15, John Brownie wrote:
> Looks like I need to keep a local flag for when the document gets changed and
> when it gets saved.
No, you can just use -[NSDocument isDocumentEdited].
Back when Auto Save first appeared, in OS X 10.7, I too found that it was
pestering me too
On Fri Jun 20 2014 12:58:11 GMT+1000 (PGT) Graham Cox wrote:
On 20 Jun 2014, at 12:37 pm, John Brownie wrote:
OK, thank you for the pointers. After a lot of refactoring, I've got things
working without deadlocks, and cleaned up various things on the way.
However, the autosave is getting too
On 20 Jun 2014, at 12:37 pm, John Brownie wrote:
> OK, thank you for the pointers. After a lot of refactoring, I've got things
> working without deadlocks, and cleaned up various things on the way.
>
> However, the autosave is getting too expensive for the bundled document.
One strategy might
OK, thank you for the pointers. After a lot of refactoring, I've got
things working without deadlocks, and cleaned up various things on the way.
However, the autosave is getting too expensive for the bundled document.
I've done some testing to show this, so I need to be smarter about
saving, o
On Tue Jun 10 2014 13:14:51 GMT+1000 (PGT) Graham Cox wrote:
On 10 Jun 2014, at 11:28 am, John Brownie wrote:
I think that the problem is likely to involve the fact that documents can be
owned by both the bundle document class and the simple document class, and
trying to save the same docume
On 10 Jun 2014, at 11:28 am, John Brownie wrote:
> I think that the problem is likely to involve the fact that documents can be
> owned by both the bundle document class and the simple document class, and
> trying to save the same document may be leading to the problem.
But is it the same fi
My app can handle documents in two different forms. One is a simple
file, while the other is a bundle that can contain one or more of that
same kind of file plus some metadata about them.
The simple file is handled as an NSDocument subclass, and is written out
with dataOfType:error:. It return
13 matches
Mail list logo
