Re: Odd initial save behavior with bundle based NSDocument
Hi Mike, I was about to post code + screenshots showing I had checked all this (which I thought I had). In doing so I found out of course that the autosave mechanism was in fact saving all over the show. Given that we are managing the assets manually (they are large, possible GBs in size, hence not using a file wrapper), that was the issue. New projects would be written - assets were not moved (because no previous autosave URL or project URL was available in this case), and we'd be left with a somewhat empty project. So, I just made the write: move the assets appropriately if no original autosave location was found. Seems to work OK for new docs, saving existing, duplication. Thanks for the question: you got me looking in the right place! -- Neil On 22/03/2012, at 12:30 AM, Mike Abdullah wrote: > It sounds to me like your writeToURL… method isn't writing out the entire > document's contents. Can you show us some code? Note that for document > packages, using NSFileWrapper often makes your implementation a lot easier. > > Sent from my iPad > > On 20 Mar 2012, at 07:53 PM, Neil Clayton wrote: > >> Hi All, >> >> I'm seeing something a bit odd with NSDocument in 10.7. >> >> We're writing large files to our own package, so as a result I've overridden: >> >> - (BOOL) writeToURL:ofType:forSaveOperation:originalContentsURL:error: >> - (BOOL)readFromURL:ofType:error: >> >> + (BOOL) autosavesInPlace - is fixed to return YES. >> >> We have a single index file at the root of the bundle, plus a subfolder >> called "assets", which while initially empty will get filled with files as >> we "do stuff" with the document. Note: the addition of files to this folder >> can and does occur outside of specific calls to the document. >> >> Now, what I'm seeing is this: >> >> 1) Make a new doc >> 2) Put some additional files within the assets folder of the doc >> 3) Save the new (presently Untitled) doc to the Desktop >> 4) Result: The saved doc *no longer contains the asset file* >> >> What I understand (according to the NSDocument headers) is that >> writeSafelyToURL:ofType:forSaveOperation:error: is supposed to do "a >> bunch-o-stuff" (as outlined in the headers). And, importantly, at the end >> >> "4) Moves the just-written file to its final location, or deletes the >> old on-disk revision of the document, and deletes any temporary directories, >> depending on the same factors listed for step 1." >> >> I can see our write call made, to the unsaved doc in ~/Library/Autosave >> Information/. If I open this bundle in Finder, the contents are saved just >> fine, and there is a single asset in the assets folder. This is expected. >> >> However; it doesn't get moved (point 4 above) correctly. >> When I open the moved document on the Desktop, it's got it's index file, and >> an assets folder, but there are NO assets inside that folder. It's like the >> move operation moved everything at level 1, and didn't take into account >> subfolders. >> >> >> Any ideas? >> >> -- >> Neil Clayton >> >> >> >> >> >> ___ >> >> 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.com/mailman/options/cocoa-dev/cocoadev%40mikeabdullah.net >> >> This email sent to cocoa...@mikeabdullah.net Neil Clayton n...@cloudnine.net.nz ___ 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.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Odd initial save behavior with bundle based NSDocument
Hi All, I'm seeing something a bit odd with NSDocument in 10.7. We're writing large files to our own package, so as a result I've overridden: - (BOOL) writeToURL:ofType:forSaveOperation:originalContentsURL:error: - (BOOL)readFromURL:ofType:error: + (BOOL) autosavesInPlace - is fixed to return YES. We have a single index file at the root of the bundle, plus a subfolder called "assets", which while initially empty will get filled with files as we "do stuff" with the document. Note: the addition of files to this folder can and does occur outside of specific calls to the document. Now, what I'm seeing is this: 1) Make a new doc 2) Put some additional files within the assets folder of the doc 3) Save the new (presently Untitled) doc to the Desktop 4) Result: The saved doc *no longer contains the asset file* What I understand (according to the NSDocument headers) is that writeSafelyToURL:ofType:forSaveOperation:error: is supposed to do "a bunch-o-stuff" (as outlined in the headers). And, importantly, at the end "4) Moves the just-written file to its final location, or deletes the old on-disk revision of the document, and deletes any temporary directories, depending on the same factors listed for step 1." I can see our write call made, to the unsaved doc in ~/Library/Autosave Information/. If I open this bundle in Finder, the contents are saved just fine, and there is a single asset in the assets folder. This is expected. However; it doesn't get moved (point 4 above) correctly. When I open the moved document on the Desktop, it's got it's index file, and an assets folder, but there are NO assets inside that folder. It's like the move operation moved everything at level 1, and didn't take into account subfolders. Any ideas? -- Neil Clayton ___ 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.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Unable to right align text when drawing via [NSAttributedString drawAt:]
Ta daaa! And that was it! thank you. drawRect works just fine. Neil On 9/03/2010, at 10:02 AM, Kevin Wojniak wrote: > Never mind, ignore that. Use drawInRect instead of drawAtPoint. My guess is > that when when you draw at a point, Cocoa obviously doesn't have a boundary > to right (or center) align the text to, so it just defaults to left-aligned. ___ 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
Unable to right align text when drawing via [NSAttributedString drawAt:]
Hello All!
I seem unable to align text when drawing using drawAt:point. The NSTextView
shows it OK (so the attributes appear correct), but drawing of the text doesn't
show alignment...
My code is:
- (void) awakeFromNib {
NSNotificationCenter *nc = [NSNotificationCenter defaultCenter];
[nc addObserver:self selector:@selector(updateText:)
name:NSTextViewDidChangeTypingAttributesNotification object:nil];
[nc addObserver:self selector:@selector(updateText:)
name:NSTextDidChangeNotification object:nil];
NSString *str = @"This is a test\nAnd this text should be right
aligned\nBut for some reason, in the image, isn't";
NSMutableParagraphStyle *pStyle = [[NSMutableParagraphStyle new]
autorelease];
[pStyle setAlignment:NSRightTextAlignment];
NSDictionary *attrs = [NSDictionary
dictionaryWithObjectsAndKeys:pStyle, NSParagraphStyleAttributeName, nil];
NSAttributedString *as = [[[NSAttributedString alloc]
initWithString:str attributes:attrs] autorelease];
[[text textStorage] setAttributedString:as];
}
- (void) updateText:(NSNotification*)aNotification {
[self textChanged:self];
}
- (IBAction) textChanged:(id)sender {
NSAttributedString *string = [text attributedString];
NSSize bounds = [string size];
if(bounds.width > 0 && bounds.height > 0) {
NSImage *image = [[[NSImage alloc] initWithSize:bounds]
autorelease];
[image lockFocus];
@try {
[string drawAtPoint:NSZeroPoint];
} @finally {
[image unlockFocus];
}
[view setImage:image];
} else {
[view setImage:nil];
}
}
A sample of what I see when I run this is here:
http://dl.dropbox.com/u/421935/DrawingText/DrawingTest.png
I must be missing something really obvious. Any ideas?
Neil Clayton
n...@cloudnine.net.nz
___
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
