Re: Disabling menu items

[Kevin Perry]

This should be handled automatically by NSDocumentController’s implementation 
of -validateUserInterfaceItem: / -validateMenuItem:. Any chance you’re 
overriding either of those methods and returning YES for menu items you don’t 
own (instead of calling super)?

> On Oct 6, 2017, at 4:13 PM, Shane Stanley  wrote:
> 
> I fear I'm missing something simple. When I enter the versions browser, I 
> want to disable the items on the Open Recent submenu. But I'm not seeing 
> anywhere obvious to do it; that menu looks like it's all handled opaquely. 
> Any clues?
> 
> 
> -- 
> Shane Stanley 
> , 
> 
> 
> ___
> 
> 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/kperry%40apple.com
> 
> This email sent to kpe...@apple.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Document drafts

[Kevin Perry]

Drafts are documents that have been autosaved in a user-visible location (i.e. 
the app’s iCloud container) and therefore aren’t typical “Untitled” documents 
from the programmer’s perspective as their fileURL property is not nil. 
However, they still behave like “Untitled” documents in that they will prompt 
the user when they close it about whether and where the document should be 
saved.

Contrast this with traditional (non-autosavesInPlace) Untitled document which 
may autosaved in a non-user-visible location (~/Library/Autosave Information) 
for which fileURL is still nil, and autosavedContentsFileURL is used instead.

-KP

> On Mar 12, 2017, at 1:56 PM, Daryle Walker  wrote:
> 
> Some of the API for NSDocument is oriented around draft documents. What is a 
> draft and how does it differ from a non-draft? How do I create/open a 
> document in draft mode? I didn't see anything about it in the Document guide; 
> were drafts supposed to be a New World Order like auto-saves or versions, but 
> got abandoned?
> 
> Sent from my iPhone
> ___
> 
> 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/kperry%40apple.com
> 
> This email sent to kpe...@apple.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Intercept Save when closing NSDocument

[Kevin Perry]

NSSavePanelDelegate is probably the approach you want to take, with 
-[NSDocument prepareSavePanel:] being the most convenient means of inserting 
your delegate.

> On Feb 10, 2017, at 9:41 AM, Quincey Morris 
>  wrote:
> 
> On Feb 10, 2017, at 08:12 , Trygve Inda  wrote:
>> 
>> I would like to disable the Save button
>> for a demo version of our app.
> 
> Have you looked at the NSSavePanelDelegate methods? One approach would be to 
> use panel:validateURL:error: to prevent the save proceeding. Another would be 
> to use (say) panelSelectionDidChange: to explicitly disable the Save button 
> (which has a documented view tag) if that works the the XPC environment of 
> the Save dialog.
> 
> ___
> 
> 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/kperry%40apple.com
> 
> This email sent to kpe...@apple.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Does - replaceItemAtURL: withItemAtURL: backupItemName: options: resultingItemURL: error: handle cross-volume moves?

[Kevin Perry]

 On Mar 30, 2015, at 5:17 PM, Daryle Walker dary...@mac.com wrote:
 
 On Mar 30, 2015, at 7:59 PM, Kevin Perry kpe...@apple.com 
 mailto:kpe...@apple.com wrote:
 
 -replaceItemAtURL:… relies on the atomicity of the POSIX rename() function 
 in order to safely do its operation. Since rename() doesn’t work across 
 volumes (returning EXDEV), the two URLs must be on the same volume.
 
 If you’re using a temporary directory with replaceItemAtURL:…, you want to 
 use -[NSFileManager 
 URLForDirectory:inDomain:appropriateForURL:create:error:] with 
 NSItemReplacementDirectory, passing it the to-be-replaced item URL. This 
 will get you an appropriate temporary directory on the target volume to 
 ensure -replaceItemAtURL:… won’t fail due to rename's EXDEV.
 
 On Mar 30, 2015, at 4:44 PM, Daryle Walker dary...@mac.com 
 mailto:dary...@mac.com wrote:
 
 NSFileManager’s “- moveItemAtURL: toURL: error:” method does a copy if the 
 source and destination file-URLs are on different volumes. Does “- 
 replaceItemAtURL: withItemAtURL: backupItemName: options: resultingItemURL: 
 error:” do similar? The docs for the latter don’t mention it. I’m worried 
 since those docs do mention temporary directories, that we have to do 
 different-volume detection (possibly harder than in the pre-X days) and 
 copying manually. I don’t want to do that, since Apple already includes 
 that logic in the former method.
 
 So I have to: (1) call URLForDirectory… to make sure there’s an appropriate 
 temporary directory, (2) call moveItemAtURL… to relocate the downloaded file 
 from the volume NSURLSession used to the one made in the first step, and (3) 
 call replaceItemAtURL… for the final move, right? Is there a way to easily 
 determine if two file objects are in the same volume, to skip the second step 
 if unneeded? (Or is there a way to tell NSURLSession which volume to put its 
 temporary files in advance?…)

I’m not personally familiar with NSURLSession, but don’t see any API to specify 
a volume/directory for the download destination.

You can check if two URLs are on the same volume by comparing values for 
NSURLVolumeIdentifierKey. If they are on the same volume, you can probably skip 
both (1) and (2). The API doesn’t require a specific temporary directory to 
work.

 
 — 
 Daryle Walker
 Mac, Internet, and Video Game Junkie
 darylew AT mac DOT 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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Does - replaceItemAtURL: withItemAtURL: backupItemName: options: resultingItemURL: error: handle cross-volume moves?

[Kevin Perry]

Hi Daryle,

-replaceItemAtURL:… relies on the atomicity of the POSIX rename() function in 
order to safely do its operation. Since rename() doesn’t work across volumes 
(returning EXDEV), the two URLs must be on the same volume.

If you’re using a temporary directory with replaceItemAtURL:…, you want to use 
-[NSFileManager URLForDirectory:inDomain:appropriateForURL:create:error:] with 
NSItemReplacementDirectory, passing it the to-be-replaced item URL. This will 
get you an appropriate temporary directory on the target volume to ensure 
-replaceItemAtURL:… won’t fail due to rename's EXDEV.

-KP

 On Mar 30, 2015, at 4:44 PM, Daryle Walker dary...@mac.com wrote:
 
 NSFileManager’s “- moveItemAtURL: toURL: error:” method does a copy if the 
 source and destination file-URLs are on different volumes. Does “- 
 replaceItemAtURL: withItemAtURL: backupItemName: options: resultingItemURL: 
 error:” do similar? The docs for the latter don’t mention it. I’m worried 
 since those docs do mention temporary directories, that we have to do 
 different-volume detection (possibly harder than in the pre-X days) and 
 copying manually. I don’t want to do that, since Apple already includes that 
 logic in the former method.
 
 — 
 Daryle Walker
 Mac, Internet, and Video Game Junkie
 darylew AT mac DOT 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:
 https://lists.apple.com/mailman/options/cocoa-dev/kperry%40apple.com
 
 This email sent to kpe...@apple.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSUserDirectory returns nil

[Kevin Perry]

NSUserDirectory refers to the “Users” directory, which exists only in the 
“System” domain (“/Users). The “User” domain is the home directory (“~”). The 
combination of NSUserDirectory and NSUserDomainMask results in a nonsensical 
and nonexistent path (“~/Users”) so it returns nil/empty instead.

-KP

 On Sep 25, 2014, at 4:53 PM, trid...@ihug.co.nz wrote:
 
 
 
 Why does [[NSFileManager defaultManager]
 URLForDirectory:NSUserDirectory inDomain:NSUserDomainMask
 appropriateForURL:nil create:NO error:nil] 
 
 return nil?
 
 
 [[NSFileManager defaultManager] URLsForDirectory:NSUserDirectory
 inDomains:NSUserDomainMask] returns an empty array. 
 
 I am aware of
 NSHomeDir(). 
 
 
 ___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: makeDocumentForURL:nil withContentsOfURL:fileURL causing deletion

[Kevin Perry]

Using -makeDocumentForURL:nil withContentsOfURL:non-nil was originally designed 
around the idea of reopening a document that was autosaved into 
~/Library/Autosave Information after crash recovery or via the post-Lion 
Restore feature. When such documents are closed without saving, it is desired 
that the file gets deleted.

As such, this is not originally meant for copying the contents of an 
arbitrary document into a new untitled document in the way that you intend.

One way you may be able to work around this is to call [document 
setAutosavedContentsFileURL:nil] after creating the document in this way. This 
will disassociate the document from the original file you loaded the data from. 
You can then force NSDocument to create its own autosaved backing file in 
~/Library/Autosave Information with 
-autosaveWithImplicitCancellability:completionHandler:. However, note that this 
should probably be done before the document is made visible, because otherwise 
there will be a period of time when the window will not have the file required 
to make the window restorable.

-KP

On Feb 8, 2014, at 11:43 AM, Trygve Inda cocoa...@xericdesign.com wrote:

 I am reading a document in the format of the old version of my app and
 converting it to a new format. The old version is not a document at all but
 is a fixed data file in /Application Support/MyApp/
 
 MyDocument *untitledDoc = [[NSDocumentController sharedDocumentController]
 makeDocumentForURL:nil withContentsOfURL:fileURL
 ofType:kApplicationDocumentType error:error];
 
 if (untitledDoc)
 {
  [untitledDoc makeWindowControllers];
  [untitledDoc showWindows];
  [untitledDoc setFileURL:nil];
  [[NSDocumentController sharedDocumentController] addDocument:(NSDocument
 *)untitledDoc];
 }
 
 
 
 This works fine and I am able to migrate the data into a real NSDocument
 subclass.
 
 However, if I close the window (thus closing the document) and choose to not
 save, the file package at fileURL is deleted.
 
 Yikes!
 
 How can I completely disassociate the fileURL from the new document that I
 created. I want to treat fileURL as a template or stationary that is only
 read from, and never written to.
 
 [untitledDoc setFileURL:nil] does not seem to work to disassociate the
 document from the source file.
 
 Thanks,
 
 Trygve
 
 
 
 ___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSDocument and KVO compliance

[Kevin Perry]

If you wanted to try this, you should also override 
-updateChangeCountWithToken:forSaveOperation:, which is used to decrement 
change counts after saving.

I expect this would get you 99% of the way, but as Seth said, don't expect it 
to be bulletproof.

On Oct 18, 2013, at 11:49 AM, Seth Willits sli...@araelium.com wrote:

 On Oct 18, 2013, at 11:41 AM, jonat...@mugginsoft.com wrote:
 
 Twice recently I have found myself tinkering with NSDocument et al to 
 support observing of certain values.
 For example, NSDocument -isDocumentEdited is not seemingly KVO compliant.
 -isDocumentEdited status is driven by -updateChangeCount: so 
 
 ...
 
 Is this the best way to go about addressing these sorts of issues with 
 regard to missing KVO compliance?
 
 Well, the best thing to do is file a radar and wait a couple years for them 
 to get around to adding it. :( 
 
 That said, it would probably mostly work, but it's not always guaranteed to 
 be bulletproof because those keys could also be influenced by private 
 methods. 
 
 
 --
 Seth Willits
 
 
 
 
 ___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Correct usage of NSTextView and NSFindBar

[Kevin Perry]

On Sep 20, 2013, at 10:15 PM, Martin Hewitson martin.hewit...@aei.mpg.de 
wrote:

 Actually, I got this wrong. I swap out the textstorage in the textview by 
 calling setTextView on the textContainer which I get from the textStorage 
 that belongs to the file instance being edited. This is probably why I'm 
 bypassing the 'notification' chain. Perhaps I'm going about this 'one editor 
 for many files' problem the wrong way because looking back at (very) old code 
 I get the textContainer by doing
 
 - (NSTextContainer*)textContainer
 {
   // An ugly quick hack to return the 'main' text container for this 
 document
   return [[self.textStorage layoutManagers][0] textContainers][0];
 }
 
 Is there a better way to do all this?

That seems a little backwards to me.

NSLayoutManager is really the center of the Cocoa text architecture. It manages 
the list of NSTextViews, the list of NSTextContainers (those two objects are 
associated 1-to-1), and the NSTextStorage that will be rendered and laid out 
between all of the NSTextViews. It sounds like you're assuming there's a 1-to-1 
association between NSTextStorage and NSTextContainer objects, which I don't 
think is true. The NSTextContainer's job is to define the region in which the 
text should be rendered—it doesn't really have anything to do with the string 
itself. Thus, instead of doing this to swap out your NSTextStorage:

[textView setTextContainer: the code you have above];

… it would make more sense to me to do:

[textView.layoutManager replaceTextStorage: newTextStorage];

Take a look at 
https://developer.apple.com/library/mac/documentation/TextFonts/Conceptual/CocoaTextArchitecture/TextSystemArchitecture/ArchitectureOverview.html#//apple_ref/doc/uid/TP40009459-CH7-SW1
 for more in-depth information.

-KP

 Many thanks,
 
 Martin
 
 
 On Sep 21, 2013, at 06:52 AM, Martin Hewitson martin.hewit...@aei.mpg.de 
 wrote:
 
 Ah, that's very useful information. I actually maintain multiple 
 NSTextStorage instances, one for each file that's being managed, and swap 
 those in and out by doing setTextView on the storage instance. So is this 
 somehow bypassing the chain of notifications that tells NSTextFinder that 
 the string changed? Any way around that?
 
 Many thanks,
 
 Martin
 
 
 
 
 On Sep 20, 2013, at 07:37 PM, Kevin Perry kpe...@apple.com wrote:
 
 
 On Sep 20, 2013, at 10:00 AM, Martin Hewitson martin.hewit...@aei.mpg.de 
 wrote:
 
 Dear list,
 
 I have an editor app which presents a list of files that can be edited. 
 Selecting a file displays the text contents in an NSTextView subclass. On 
 10.7 and later the app supports using the FindBar. Searching the currently 
 displayed text works fine the first time the find bar is used. But if 
 another file is selected (so that the text in the textview changes) then 
 the find bar shows nonsensical results, as if subsequent uses are still 
 looking at the contents of the file that where displayed when the find bar 
 was first invoked. 
 
 Is there something I can/should do to 'reset' the find bar when the file 
 being edited changes? I couldn't find anything in the documentation, and I 
 couldn't figure out how to get the NSTextFinder instance that the textview 
 is using, and even if I could, I don't see anything in the documentation 
 to 'reset' its state, or set the string it should search. 
 
 How are you replacing the NSTextView contents when switching files? The 
 'reset' call for NSTextFinder when the client's content changes is 
 -noteClientStringWillChange. NSTextView is supposed to invoke this during 
 -shouldChangeTextInRanges:replacementStrings:. It's also invoked during 
 -[NSLayoutManager setTextStorage:], so when you switch your NSTextView 
 contents, you could load the new file's contents into a new NSTextStorage 
 instance, then invoke [[textStorage layoutManager] 
 replaceTextStorage:newTextStorage].
 
 -KP
 
 Am I going about this all the wrong way? I thought this is one of those 
 'it just works' cases
 
 Many thanks,
 
 Martin
 
 
 
 
 
 
 
 Martin Hewitson
 Albert-Einstein-Institut
 Max-Planck-Institut fuer 
Gravitationsphysik und Universitaet Hannover
 Callinstr. 38, 30167 Hannover, Germany
 Tel: +49-511-762-17121, Fax: +49-511-762-5861
 E-Mail: martin.hewit...@aei.mpg.de
 WWW: http://www.aei.mpg.de/~hewitson
 
 
 
 
 
 


___

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: Correct usage of NSTextView and NSFindBar

[Kevin Perry]

On Sep 20, 2013, at 10:00 AM, Martin Hewitson martin.hewit...@aei.mpg.de 
wrote:

 Dear list,
 
 I have an editor app which presents a list of files that can be edited. 
 Selecting a file displays the text contents in an NSTextView subclass. On 
 10.7 and later the app supports using the FindBar. Searching the currently 
 displayed text works fine the first time the find bar is used. But if another 
 file is selected (so that the text in the textview changes) then the find bar 
 shows nonsensical results, as if subsequent uses are still looking at the 
 contents of the file that where displayed when the find bar was first 
 invoked. 
 
 Is there something I can/should do to 'reset' the find bar when the file 
 being edited changes? I couldn't find anything in the documentation, and I 
 couldn't figure out how to get the NSTextFinder instance that the textview is 
 using, and even if I could, I don't see anything in the documentation to 
 'reset' its state, or set the string it should search. 

How are you replacing the NSTextView contents when switching files? The 'reset' 
call for NSTextFinder when the client's content changes is 
-noteClientStringWillChange. NSTextView is supposed to invoke this during 
-shouldChangeTextInRanges:replacementStrings:. It's also invoked during 
-[NSLayoutManager setTextStorage:], so when you switch your NSTextView 
contents, you could load the new file's contents into a new NSTextStorage 
instance, then invoke [[textStorage layoutManager] 
replaceTextStorage:newTextStorage].

-KP

 Am I going about this all the wrong way? I thought this is one of those 'it 
 just works' cases
 
 Many thanks,
 
 Martin
 
 
 
 
 
 
 ___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Unwanted presentedItemDidMoveToURL: for old file after using setFileURL: to specify a new file

[Kevin Perry]

On Sep 18, 2013, at 6:53 AM, Brian Clark ba-cl...@comcast.net wrote:

 A follow-up as a result of more testing.
 
 It's not actually necessary to do the read via 
 -revertToContentsOfURL:ofType:error: in a File Access block to solve the 
 problem I had, though I'm sure it's best to do so (and that's what I now do).
 
 Similarly moving the file to the Trash or deleting it should probably also be 
 done in a File Access block, and that's what I now do to.
 
 But there's an exception to this rule. In my app, if the displayed file is 
 marked as to be trashed, it's moved to the Trash when the window is closed in 
 the document's -close method (before calling [super close] ). But this 
 results in a hang if it's done inside a [self 
 performSynchronousFileAccessUsingBlock:^{ ... }]; block. So in this case a 
 File Access block apparently can't be used.

FYI: You can get help discovering the cause of hangs involving 
performSynchronousFileAccessUsingBlock (and 
performActivityWithSynchronousWaiting:usingBlock:) by doing 'po 
_NSDocumentSerializationInfo()' in the debugger.

 
 On Sep 16, 2013, at 12:24 PM, Kevin Perry kpe...@apple.com wrote:
 
 But, I suspect the problem here is that you're not using File Coordination 
 when reading in the contents of the new file. By not doing that, you're not 
 giving File Coordination the hint that it needs to check back with your 
 NSFilePresenter (the NSDocument) for its presentedItemURL. When you read in 
 the contents of the new file you should:
 
 1) Start a File Access with -performSynchronousFileAccessUsingBlock: or 
 -performAsynchronousFileAccessUsingBlock
 2) Create an NSFileCoordinator instance with the NSDocument as the 
 NSFilePresenter passed in the initializer.
 3) Using that NSFileCoordinator, take a coordinated read of the target file
 4) Inside the coordinated read: read the contents of the new file 
 (-revertToContentsOfURL:ofType:error: is probably the most correct here, as 
 it will update -fileURL, -fileModificationDate, -fileType, change counts, 
 and other internal state as necessary)
 
 ___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Unwanted presentedItemDidMoveToURL: for old file after using setFileURL: to specify a new file

[Kevin Perry]

Re-using a single NSDocument instance to represent several different files is 
certainly atypical…

But, I suspect the problem here is that you're not using File Coordination when 
reading in the contents of the new file. By not doing that, you're not giving 
File Coordination the hint that it needs to check back with your 
NSFilePresenter (the NSDocument) for its presentedItemURL. When you read in the 
contents of the new file you should:

1) Start a File Access with -performSynchronousFileAccessUsingBlock: or 
-performAsynchronousFileAccessUsingBlock
2) Create an NSFileCoordinator instance with the NSDocument as the 
NSFilePresenter passed in the initializer.
3) Using that NSFileCoordinator, take a coordinated read of the target file
4) Inside the coordinated read: read the contents of the new file 
(-revertToContentsOfURL:ofType:error: is probably the most correct here, as it 
will update -fileURL, -fileModificationDate, -fileType, change counts, and 
other internal state as necessary)

After the coordinated read, NSFileCoordinator should re-invoke 
-presentedItemURL (which returns [self fileURL] by default), notice the URL has 
changed, and disassociate the NSFilePresenter state from the previous URL. This 
should prevent you from getting any unwanted NSFilePresenter messages.

-KP

On Sep 16, 2013, at 10:04 AM, Brian Clark ba-cl...@comcast.net wrote:

 
 On Sep 16, 2013, at 4:38 AM, Mike Abdullah mabdul...@karelia.com wrote:
 
 
 On 14 Sep 2013, at 21:14, Brian Clark ba-cl...@comcast.net wrote:
 
 I'm hoping someone can suggest the correct way to deal with the following 
 problem.
 
 For an image viewing app i display a file in the usual way in an 
 NSDocument. setFileURL: is properly called by NSDocument's 
 _initWithContentsOfURL:ofType:error:.
 
 I now want to display the next file in the folder, and move the old file to 
 the Trash. To do this I do the necessary file reading tasks and call 
 setFileURL: with the new file URL. I then move the old file to the trash 
 (using NSFileManager 's trashItemAtURL:resultingItemURL:error: but using 
 different methods gives the same result.)
 
 What are the necessary file reading tasks? Rather than call -setFileURL: 
 yourself, have you tried calling -revertToContentsOfURL:ofType:error: 
 instead? The top of the class documentation briefly notes that it should 
 always be used for re-reading documents.
 
 The necessary tasks are readFromURL:ofType:error: and the other chores 
 associated with setting up the document state for the different image file.
 
 Using -revertToContentsOfURL:ofType:error: instead does not work. After doing 
 this NSDocument still seems to treat the old URL as the file's document, and 
 I still get presentedItemDidMoveToURL: for the old file URL when it is moved 
 to the Trash AFTER I-ve called revertToContentsOfURL:ofType:error:. While 
 revertToContentsOfURL:ofType:error: may work correctly for the cases for 
 which I guess it was intended (as described by the NSDocument Class 
 Reference), it doesn't seem to work for this case, for reasons unknown.
 
 The best work-around I've found is to add a file reference URL to my 
 NSDocument subclass, and set it in an override of setFileURL:. Then in an 
 override of presentedItemDidMoveToURL: I test if the saved file reference URL 
 is the same as the new URL, and do nothing if they're not the same file. That 
 seems to work, but it's a bit of a hack, and I'd really like to understand if 
 NSDocument is simply broken in this regard, or why setFileURL: does not work 
 and what is the correct and reliable way to change the URL for an open 
 document.
 
 
 ___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Find bar in a text view

[Kevin Perry]

Sounds like a bug that you should report via Bug Reporter.

But as a workaround, you should be able to call -[NSTextView 
setIncrementalSearchingEnabled:NO] when the subview gets collapsed (then 
obviously set it back to YES when the text view is uncollapsed, though you will 
lose search results in doing so).

-KP

On Aug 15, 2013, at 4:59 AM, Shane Stanley sstan...@myriad-com.com.au wrote:

 I have text views in a split view, and I use find bars with them. I'd like to 
 implement incremental searching. When I turn it on in IB  it works, except 
 that if I collapse a subview showing the grey overlay, the overlay remains on 
 screen. As a workaround, the documentation says I can turn the overlay off I 
 should set the incrementalSearchingShouldDimContentView property to NO.
 
 The problem is that the find bar is all pre-implemented by NSTextView, and I 
 can't see how to address the NSTextFinder instance. Any suggestions, or do I 
 need to implement my own NSTextFinder instance?
 
 -- 
 Shane Stanley sstan...@myriad-com.com.au
 'AppleScriptObjC Explored' www.macosxautomation.com/applescript/apps/
 
 
 ___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Temporarily disabling autosave

[Kevin Perry]

On Apr 25, 2013, at 10:05 AM, Quincey Morris 
quinceymor...@rivergatesoftware.com wrote:

 I can't begin to count the number of times I've opened documents, edited 
 them in some way, not intending to save those changes. Maybe I just needed 
 to, say, find an image in a particular layer of some image editing app, so I 
 hid some layers. That sort of thing. But doing something as simple as 
 quitting means those changes will automatically change my actual document 
 file without even asking if I want to discard them. That's just dangerous.
 
 You have this exactly backwards. Autosaving-in-place never changes the 
 *saved* document file. It writes the autosaved document elsewhere. When you 
 quit with an open, dirty document, there are two copies until you relaunch. 
 At that point, your document is *still* dirty, and you can *still* close the 
 document window explicitly, and you get a dialog asking if you want to save 
 or discard changes (back to the point of the original save, which was before 
 you quit and relaunched).

Actually no—autosaving-in-place means exactly that changes are always saved to 
the main document file, hence in place. There is only ever a single file per 
document, even when quitting.

However, in Mountain Lion, we added preferences that allow you to (1) force 
documents to close on Quit, and (2) ask if the user wants to keep changes that 
they haven't explicitly saved (Cmd-S). In the above scenario, when these 
preferences are enabled, you will be given the option to discard all the 
experimental / temporary changes (made possible by Versions).

-KP


___

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: Autosave directory settable?

[Kevin Perry]

That might work, though I would probably recommend overriding at 
-saveToURL:ofType:forSaveOperation:completionHandler: instead, and only modify 
the path if saveOperation == NSAutosaveElsewhereOperation. If you override at 
that level, setAutosavedContentsFileURL: will be invoked for you when the save 
is complete.

-KP

On Apr 16, 2013, at 12:54 PM, Steve Mills smi...@makemusic.com wrote:

 Is it possible for the app to set the directory where autosaved documents 
 will be stored instead of the folder the OS creates deep within 
 /private/var/folders? Our app has long done its own autosaving and offered a 
 pref so the user could change the dir if they wanted. I'm now looking into 
 the possibility of switching to Cocoa's autosave instead, and would like all 
 our autosave prefs to remain as they are and still be usable.
 
 Would it be gross to override 
 writeToURL:ofType:forSaveOperation:originalContentsURL:error: and if it's an 
 autosave operation, rejigger the url to use own dir, and finally call 
 setAutosavedContentsFileURL with the url we saved to instead?
 
 --
 Steve Mills
 office: 952-818-3871
 home: 952-401-6255
 cell: 612-803-6157
 
 
 
 ___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSOpenPanel not showing iCloud

[Kevin Perry]

At the moment, the only open panel that gets the iCloud treatment is the one 
created by -[NSDocumentController openDocument:] or -[NSDocumentController 
beginOpenPanelWithCompletionHandler:].

-KP

On Apr 3, 2013, at 8:29 PM, Kurt Sutter k...@quansoft.com wrote:

 Dear all
 
 We are trying to make our application iCloud savvy. We have sandboxed it, and 
 we have enabled iCloud  in the Xcode target settings. The application uses 
 NSDocument-derived documents. We are using the latest public release of Mac 
 OS 10.8
 
 The save dialog boxes show iCloud as expected, and they allow us to save or 
 documents on iCloud. However, the  open dialog boxes don't. We basically 
 invoke the open dialog boxes as follows:
 
 panel = [NSOpenPanel openPanel];
 result = [panel runModal];
 
 The dialog box created in this way is an old-style open dialog box that does 
 not provide any access to iCloud.
 
 We are a bit at the loss and any advice is appreciated.
 
 Best regards and thanks in advance
 
 Kurt ___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Setting the position of new windows

[Kevin Perry]

I think you want to use -setShouldCascadeWindows:NO.

On Mar 13, 2013, at 2:20 PM, Steve Mills smi...@makemusic.com wrote:

 I've spent most of the day researching and coding this, but still don't have 
 it perfect. I need to position our new document windows so they aren't 
 covered by palettes that might be visible. I've done this in my window 
 controller's windowDidLoad method, as was suggested somewhere. I'm able to 
 calculate the new frame and set it with setFrame. This works on the first 
 window. But if I create a 2nd window, it is going through what looks like the 
 default cascading code, mostly ignoring the setFrame I just did (the size is 
 right, but it moves it around).
 
 Am I going about this in the wrong place, or do I have to do a whole bunch 
 more stuff to make this work, like subclassing NSWindow and overriding 
 cascadeTopLeftFromPoint or some such thing?
 
 --
 Steve Mills
 office: 952-818-3871
 home: 952-401-6255
 cell: 612-803-6157
 
 
 
 ___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Getting file type from Save dlog

[Kevin Perry]

On Jan 30, 2013, at 12:32 PM, Steve Mills smi...@makemusic.com wrote:

 On Jan 25, 2013, at 16:42:01, Kevin Perry kpe...@apple.com wrote:
 
 If you’re using your own accessory view instead of the built-in one 
 (shouldRunSavePanelWithAccessoryView), you’re responsible for changing the 
 value of fileTypeFromLastRunSavePanel. One way to do this is to make your 
 NSDocument instance the target of the popup button’s action and change an 
 internal ivar inside that action method.
 
 I finally got this all figured out. This is a mess. It's goofy that Apple 
 decided to send the localized type name strings here

I’m not following you here. What is sending localized type names where?

 instead of the actual types supplied, which would be extensions or UTIs. 
 Those would make *so* much more sense.
 
 I ended up overriding writableTypesForSaveOperation. It took me a long time 
 to figure out why it was *always* showing 3 types when I was passing it 2. 
 Then I figured out that those 3 types are in the Info.plist with a 
 NSDocumentClass that's the same as the class that's showing the Save dlog, 
 and a CFBundleTypeRole of Editor. NSDocument is trying to be too smart here 
 and use those types, even though I specifically told the NSSavePanel to 
 setAllowedFileTypes to just my 2 types. Boo to this mess for wasting my time.

The way NSSavePanel is designed, it is completely agnostic of the accessory 
view inserted into it, even one owned by NSDocument. It has no idea how to 
change the contents of the accessory view based on what you pass to 
-setAllowedFileTypes:—there may not even be a document type popup there at all.

If you want to customize what types NSDocument shows in its default accessory 
view, then overriding -writableTypesForSaveOperation: is exactly the right 
thing to do. Sorry for the trouble you had in discovering that—would you like 
to file a documentation bug with a suggested improvement?

-KP

 --
 Steve Mills
 office: 952-818-3871
 home: 952-401-6255
 cell: 612-803-6157
 
 
 
 ___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Getting file type from Save dlog

[Kevin Perry]

On Jan 30, 2013, at 1:27 PM, Steve Mills smi...@makemusic.com wrote:

 On Jan 30, 2013, at 15:15:32, Kevin Perry kpe...@apple.com
 wrote:
 
 On Jan 30, 2013, at 12:32 PM, Steve Mills smi...@makemusic.com wrote:
 
 I finally got this all figured out. This is a mess. It's goofy that Apple 
 decided to send the localized type name strings here
 
 I’m not following you here. What is sending localized type names where?
 
 NSDocument methods:
 
 -(BOOL) writeToURL:(NSURL*)absoluteURL ofType:(NSString*)typeName 
 error:(NSError**)outError
 
 passes the type in typeName.
 
 -(NSArray*) writableTypesForSaveOperation:(NSSaveOperationType)saveOperation
 
 expects an array of type name strings.
 
 -(NSString*) fileTypeFromLastRunSavePanel
 
 returns the type name string. Etc.

I admit I’m a little confused by your claims. All of NSDocument should 
definitely be able to use UTIs in every modern API that refers to types.

For example, here’s the result of the default NSDocument implementation of 
-writeableTypesForSaveOperation:, for TextEdit:

$0 = 0x000106a19150 __NSArrayM 0x106a19150(
public.rtf,
com.apple.rtfd,
public.html,
com.apple.webarchive,
org.oasis-open.opendocument.text,
org.openxmlformats.wordprocessingml.document,
com.microsoft.word.wordml,
com.microsoft.word.doc,
public.text,
public.plain-text
)

(TextEdit does override this method, but it itself uses [[self class] 
writableTypes], which also returns an array of UTIs.)

Do you have a mix of old-style type names and UTIs in your Info.plist?

 
 The way NSSavePanel is designed, it is completely agnostic of the accessory 
 view inserted into it, even one owned by NSDocument. It has no idea how to 
 change the contents of the accessory view based on what you pass to 
 -setAllowedFileTypes:—there may not even be a document type popup there at 
 all.
 
 Right, which means NSDocument should've had its various methods that deal 
 with its accessory panel use something more viable like extensions and/or 
 UTIs, which is exactly what NSSavePanel uses to deal with file types.
 
 If you want to customize what types NSDocument shows in its default 
 accessory view, then overriding -writableTypesForSaveOperation: is exactly 
 the right thing to do. Sorry for the trouble you had in discovering 
 that—would you like to file a documentation bug with a suggested improvement?
 
 I just might do that. Although NSDocument has already gone through big 
 changes in the way it handles saving documents, I wonder how likely they'd be 
 to change it again.
 
 --
 Steve Mills
 office: 952-818-3871
 home: 952-401-6255
 cell: 612-803-6157
 
 
 
 
 ___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Getting file type from Save dlog

[Kevin Perry]

If you’re using your own accessory view instead of the built-in one 
(shouldRunSavePanelWithAccessoryView), you’re responsible for changing the 
value of fileTypeFromLastRunSavePanel. One way to do this is to make your 
NSDocument instance the target of the popup button’s action and change an 
internal ivar inside that action method.

-KP

On Jan 25, 2013, at 2:29 PM, Steve Mills smi...@makemusic.com wrote:

 I'm not understanding how, if the user changes the type of file being saved 
 in the Save dlog, how that type gets back to the document being saved. I've 
 added an accessory panel from which the user can choose the file type being 
 saved. Each type changes the extension of the file name in the name field. 
 But when it gets back to my writeToURL: method, the typeName param is always 
 the primary file type and never what the user might have changed it to. I've 
 tried inspecting fileTypeFromLastRunSavePanel: and fileType:, but they're 
 always the same as typeName.
 
 How is the type chosen in the dlog (it's a valid extension and UTI) supposed 
 to get passed back to the document?
 
 --
 Steve Mills
 office: 952-818-3871
 home: 952-401-6255
 cell: 612-803-6157
 
 
 
 ___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSMutableData and Pinned Memory buffers..

[Kevin Perry]

NSMutableData currently ignores (and always has, to my knowledge) the no-copy 
hint and always copies the bytes into an internal buffer in case something 
tries to change the length of the NSMutableData.

It would not be too difficult to make a subclass of NSMutableData that doesn't 
copy and throws an exception when something tries to change the length. That 
would violate the Liskov substitution principle though, so at the very least, 
you want to prevent any code that doesn't understand the fixed-length 
restriction from getting ahold of one of these objects.

[kevin perry];

On Dec 13, 2012, at 2:28 PM, Robert Monaghan b...@gluetools.com wrote:

 Hi Everyone,
 
 I have just run head long into an issue with NSMutableData and existing 
 buffers.
 I have the following code:
 
 
   UInt8 *sourcebytes = [clImgEngine srcBuffer];
   [self setData:[NSMutableData 
 dataWithBytesNoCopy:sourcebytes length:[clImgEngine inRangeByteCount] 
 freeWhenDone:NO]];
   UInt8 *resultBytes = [[self data] mutableBytes];
 
 The source is a pinned memory buffer from OpenCL. What I want to do, is to 
 pass this buffer inside a NSMutableData wrapper and have another object for 
 some work.
 Seems simple enough, except that NSMutableData changes the memory buffer in 
 the background.
 
 sourcebytes starts with an address such as: 0x00012361b000
 and resultBytes returns 0x000136fe2000
 
 Naturally, my work object doesn't see any data from sourcebytes, as 
 NSMutableData has moved the buffer.
 I thought that freeWhenDone:NO prevented ownership of the buffer..
 
 Can anyone suggest a way to prevent this from happening? I need the buffer to 
 stay pinned.
 
 Thanks in advance!
 
 bob.
 
 ___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSMutableData and Pinned Memory buffers..

[Kevin Perry]

On Dec 13, 2012, at 4:24 PM, Greg Parker gpar...@apple.com wrote:

 On Dec 13, 2012, at 4:13 PM, Robert Monaghan b...@gluetools.com wrote:
 I went ahead and created a really crude subclass of NSMutableData. It seems 
 to work for my situation.
 Attached is the code, for posterity. (I am sure I won't be the only one 
 working around this.)
 
 Any suggestions to make this a bit more Proper are welcome.
 
 If that's all you need then you should wrap the buffer in an immutable 
 NSData. NSData won't mind if you poke directly at the contents of the buffer.

Except that he's probably expecting to be able to invoke -mutableBytes and 
modify the buffer's contents without changing the length. Immutable NSData 
objects don't respond to -mutableBytes.
___

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: NSDocument -close called multiple times?

[Kevin Perry]

Oh dear. Forget you heard me mention anything about unpublished API. The lack 
of an _ threw me off...

Yes, you'll probably want to keep your own flag.

-KP

On Sep 20, 2012, at 11:41 PM, Markus Spoettl ms_li...@shiftoption.com wrote:

 Just to clarify: -isClosed is not something that is available on NSDocument 
 or NSWindowController, did you mean to say that I'll have to keep a flag 
 myself?
 
 Regards
 Markus
 
 On 9/20/12 6:53 PM, Kevin Perry wrote:
 This is an known and unfortunate result of the current architecture of 
 NSWindow, NSWindowController, and NSDocument.
 
 There isn't any documentation I'm aware of that explicitly states that 
 -close can be invoked re-entrantly, but it can be deduced from the existing 
 documentation:
 
 On -[NSDocument close]:
 
  The default implementation of this method  … sends each of the 
 document's window controllers a -close message
 
 On -[NSWindowController close]:
 
  If the controller belongs to a document and it is either the last 
 controller for the document or -shouldCloseDocument is YES, then this will 
 also -close the document.
 
 
 The best way around this at the moment is to first verify [self isClosed] == 
 NO before calling super and doing your own work.
 
 
 [kevin perry];
 
 On Sep 19, 2012, at 1:06 PM, Markus Spoettl ms_li...@shiftoption.com wrote:
 
 Why does AppKit call into NSDocument's -close multiple times by indirect 
 recursion? Can this be on purpose?
 
 It happens when I have this:
 
 1) A document with unsaved with changes
 2) Terminate the app via CMD-Q
 3) Answer Don't Save in the save-changes-sheet
 
 This doesn't smell right. I override -close and call super right away, 
 doing some cleanup work afterwards. Under some bizarre situations which I 
 have not been able to recreate it gets called up to 4 times.
 
 I'm pasting the call stack (line 366 is the call to super, line 375 is my 
 breakpoint).
 
 Regards
 Markus
 
 #0  0x000134d8 in -[MyDocument close] at 
 /Users/markus/Projects/MyApp/src/MyDocument.m:375
 #1  0x7fff8bed7d25 in -[NSWindowController _windowDidClose] ()
 #2  0x7fff8a30ddf0 in -[QLSeamlessDocumentCloser 
 closeWindow:contentFrame:withBlock:] ()
 #3  0x7fff8baa8602 in -[NSWindow _close] ()
 #4  0x7fff8bbe1c74 in -[NSDocument close] ()
 #5  0x000133c9 in -[MyDocument close] at 
 /Users/markus/Projects/MyApp/src/MyDocument.m:366
 #6  0x7fff8bbf342e in __-[NSDocumentController 
 closeAllDocumentsWithDelegate:didCloseAllSelector:contextInfo:]_block_invoke_3
  ()
 #7  0x7fff8bbf54c5 in -[NSDocumentController 
 _something:didSomething:soContinue:] ()
 #8  0x7fff8bbd62a8 in __-[NSDocument 
 canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo:]_block_invoke_2
  ()
 #9  0x7fff8bbd5ec1 in __-[NSDocument 
 canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo:]_block_invoke_11
  ()
 #10 0x7fff8bbe8e08 in -[NSDocument 
 _something:wasPresentedWithResult:soContinue:] ()
 #11 0x7fff8bad8a4d in -[NSAlert didEndAlert:returnCode:contextInfo:] ()
 #12 0x7fff8bae53df in -[NSApplication endSheet:returnCode:] ()
 #13 0x7fff8bad8913 in -[NSAlert buttonPressed:] ()
 #14 0x7fff8053770d in -[NSObject performSelector:withObject:] ()
 #15 0x7fff8b934f7e in -[NSApplication sendAction:to:from:] ()
 #16 0x7fff8b934eb2 in -[NSControl sendAction:to:] ()
 #17 0x7fff8b934ddd in -[NSCell _sendActionFrom:] ()
 #18 0x7fff8b9342a0 in -[NSCell trackMouse:inRect:ofView:untilMouseUp:] 
 ()
 #19 0x7fff8b9b3fc4 in -[NSButtonCell 
 trackMouse:inRect:ofView:untilMouseUp:] ()
 #20 0x7fff8b932eaa in -[NSControl mouseDown:] ()
 #21 0x7fff8b8fe348 in -[NSWindow sendEvent:] ()
 #22 0x7fff8b897a55 in -[NSApplication sendEvent:] ()
 #23 0x7fff8bae427e in -[NSApplication _shouldTerminate] ()
 #24 0x7fff8b838115 in -[NSApplication terminate:] ()
 #25 0x00010001a4a3 in -[AppDelegate terminate:] at 
 /Users/markus/Projects/rubiTrack/src/AppDelegate.m:219
 #26 0x7fff8053770d in -[NSObject performSelector:withObject:] ()
 #27 0x7fff8b934f7e in -[NSApplication sendAction:to:from:] ()
 #28 0x7fff8ba21bfb in -[NSMenuItem _corePerformAction] ()
 #29 0x7fff8ba21932 in -[NSCarbonMenuImpl 
 performActionWithHighlightingForItemAtIndex:] ()
 #30 0x7fff8b99f524 in -[NSMenu performKeyEquivalent:] ()
 #31 0x7fff8b99e175 in -[NSApplication _handleKeyEquivalent:] ()
 #32 0x7fff8b897536 in -[NSApplication sendEvent:] ()
 #33 0x7fff8b82e0c6 in -[NSApplication run] ()
 #34 0x7fff8baaa244 in NSApplicationMain ()
 #35 0x0001b552 in main at /Users/markus/Projects/MyApp/src/main.m:22
 #36 0x000121c4 in start ()
 
 --
 __
 Markus Spoettl
 ___
 
 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

Re: NSDocument -close called multiple times?

[Kevin Perry]

No. -[NSDocument close] is non-cancellable and non-reversible.

On Sep 21, 2012, at 9:55 AM, Markus Spoettl ms_li...@shiftoption.com wrote:

 OK, so one further question: Is there any chance that if -close is called the 
 document won't actually be closed and stays open?
 
 Regards
 Markus
 
 On 9/21/12 6:49 PM, Kevin Perry wrote:
 Oh dear. Forget you heard me mention anything about unpublished API. The 
 lack of an _ threw me off...
 
 Yes, you'll probably want to keep your own flag.
 
 -KP
 
 On Sep 20, 2012, at 11:41 PM, Markus Spoettl ms_li...@shiftoption.com 
 wrote:
 
 Just to clarify: -isClosed is not something that is available on NSDocument 
 or NSWindowController, did you mean to say that I'll have to keep a flag 
 myself?
 
 Regards
 Markus
 
 On 9/20/12 6:53 PM, Kevin Perry wrote:
 This is an known and unfortunate result of the current architecture of 
 NSWindow, NSWindowController, and NSDocument.
 
 There isn't any documentation I'm aware of that explicitly states that 
 -close can be invoked re-entrantly, but it can be deduced from the 
 existing documentation:
 
 On -[NSDocument close]:
 
The default implementation of this method  … sends each of the 
 document's window controllers a -close message
 
 On -[NSWindowController close]:
 
If the controller belongs to a document and it is either the last 
 controller for the document or -shouldCloseDocument is YES, then this will 
 also -close the document.
 
 
 The best way around this at the moment is to first verify [self isClosed] 
 == NO before calling super and doing your own work.
 
 
 [kevin perry];
 
 On Sep 19, 2012, at 1:06 PM, Markus Spoettl ms_li...@shiftoption.com 
 wrote:
 
 Why does AppKit call into NSDocument's -close multiple times by indirect 
 recursion? Can this be on purpose?
 
 It happens when I have this:
 
 1) A document with unsaved with changes
 2) Terminate the app via CMD-Q
 3) Answer Don't Save in the save-changes-sheet
 
 This doesn't smell right. I override -close and call super right away, 
 doing some cleanup work afterwards. Under some bizarre situations which I 
 have not been able to recreate it gets called up to 4 times.
 
 I'm pasting the call stack (line 366 is the call to super, line 375 is my 
 breakpoint).
 
 Regards
 Markus
 
 #00x000134d8 in -[MyDocument close] at 
 /Users/markus/Projects/MyApp/src/MyDocument.m:375
 #10x7fff8bed7d25 in -[NSWindowController _windowDidClose] ()
 #20x7fff8a30ddf0 in -[QLSeamlessDocumentCloser 
 closeWindow:contentFrame:withBlock:] ()
 #30x7fff8baa8602 in -[NSWindow _close] ()
 #40x7fff8bbe1c74 in -[NSDocument close] ()
 #50x000133c9 in -[MyDocument close] at 
 /Users/markus/Projects/MyApp/src/MyDocument.m:366
 #60x7fff8bbf342e in __-[NSDocumentController 
 closeAllDocumentsWithDelegate:didCloseAllSelector:contextInfo:]_block_invoke_3
  ()
 #70x7fff8bbf54c5 in -[NSDocumentController 
 _something:didSomething:soContinue:] ()
 #80x7fff8bbd62a8 in __-[NSDocument 
 canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo:]_block_invoke_2
  ()
 #90x7fff8bbd5ec1 in __-[NSDocument 
 canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo:]_block_invoke_11
  ()
 #10   0x7fff8bbe8e08 in -[NSDocument 
 _something:wasPresentedWithResult:soContinue:] ()
 #11   0x7fff8bad8a4d in -[NSAlert 
 didEndAlert:returnCode:contextInfo:] ()
 #12   0x7fff8bae53df in -[NSApplication endSheet:returnCode:] ()
 #13   0x7fff8bad8913 in -[NSAlert buttonPressed:] ()
 #14   0x7fff8053770d in -[NSObject performSelector:withObject:] ()
 #15   0x7fff8b934f7e in -[NSApplication sendAction:to:from:] ()
 #16   0x7fff8b934eb2 in -[NSControl sendAction:to:] ()
 #17   0x7fff8b934ddd in -[NSCell _sendActionFrom:] ()
 #18   0x7fff8b9342a0 in -[NSCell 
 trackMouse:inRect:ofView:untilMouseUp:] ()
 #19   0x7fff8b9b3fc4 in -[NSButtonCell 
 trackMouse:inRect:ofView:untilMouseUp:] ()
 #20   0x7fff8b932eaa in -[NSControl mouseDown:] ()
 #21   0x7fff8b8fe348 in -[NSWindow sendEvent:] ()
 #22   0x7fff8b897a55 in -[NSApplication sendEvent:] ()
 #23   0x7fff8bae427e in -[NSApplication _shouldTerminate] ()
 #24   0x7fff8b838115 in -[NSApplication terminate:] ()
 #25   0x00010001a4a3 in -[AppDelegate terminate:] at 
 /Users/markus/Projects/rubiTrack/src/AppDelegate.m:219
 #26   0x7fff8053770d in -[NSObject performSelector:withObject:] ()
 #27   0x7fff8b934f7e in -[NSApplication sendAction:to:from:] ()
 #28   0x7fff8ba21bfb in -[NSMenuItem _corePerformAction] ()
 #29   0x7fff8ba21932 in -[NSCarbonMenuImpl 
 performActionWithHighlightingForItemAtIndex:] ()
 #30   0x7fff8b99f524 in -[NSMenu performKeyEquivalent:] ()
 #31   0x7fff8b99e175 in -[NSApplication _handleKeyEquivalent:] ()
 #32   0x7fff8b897536

Re: NSDocument -close called multiple times?

[Kevin Perry]

This is an known and unfortunate result of the current architecture of 
NSWindow, NSWindowController, and NSDocument.

There isn't any documentation I'm aware of that explicitly states that -close 
can be invoked re-entrantly, but it can be deduced from the existing 
documentation:

On -[NSDocument close]:

The default implementation of this method  … sends each of the 
document's window controllers a -close message

On -[NSWindowController close]:

If the controller belongs to a document and it is either the last 
controller for the document or -shouldCloseDocument is YES, then this will also 
-close the document.


The best way around this at the moment is to first verify [self isClosed] == NO 
before calling super and doing your own work.


[kevin perry];

On Sep 19, 2012, at 1:06 PM, Markus Spoettl ms_li...@shiftoption.com wrote:

 Why does AppKit call into NSDocument's -close multiple times by indirect 
 recursion? Can this be on purpose?
 
 It happens when I have this:
 
 1) A document with unsaved with changes
 2) Terminate the app via CMD-Q
 3) Answer Don't Save in the save-changes-sheet
 
 This doesn't smell right. I override -close and call super right away, doing 
 some cleanup work afterwards. Under some bizarre situations which I have not 
 been able to recreate it gets called up to 4 times.
 
 I'm pasting the call stack (line 366 is the call to super, line 375 is my 
 breakpoint).
 
 Regards
 Markus
 
 #00x000134d8 in -[MyDocument close] at 
 /Users/markus/Projects/MyApp/src/MyDocument.m:375
 #10x7fff8bed7d25 in -[NSWindowController _windowDidClose] ()
 #20x7fff8a30ddf0 in -[QLSeamlessDocumentCloser 
 closeWindow:contentFrame:withBlock:] ()
 #30x7fff8baa8602 in -[NSWindow _close] ()
 #40x7fff8bbe1c74 in -[NSDocument close] ()
 #50x000133c9 in -[MyDocument close] at 
 /Users/markus/Projects/MyApp/src/MyDocument.m:366
 #60x7fff8bbf342e in __-[NSDocumentController 
 closeAllDocumentsWithDelegate:didCloseAllSelector:contextInfo:]_block_invoke_3
  ()
 #70x7fff8bbf54c5 in -[NSDocumentController 
 _something:didSomething:soContinue:] ()
 #80x7fff8bbd62a8 in __-[NSDocument 
 canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo:]_block_invoke_2 
 ()
 #90x7fff8bbd5ec1 in __-[NSDocument 
 canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo:]_block_invoke_11
  ()
 #10   0x7fff8bbe8e08 in -[NSDocument 
 _something:wasPresentedWithResult:soContinue:] ()
 #11   0x7fff8bad8a4d in -[NSAlert didEndAlert:returnCode:contextInfo:] ()
 #12   0x7fff8bae53df in -[NSApplication endSheet:returnCode:] ()
 #13   0x7fff8bad8913 in -[NSAlert buttonPressed:] ()
 #14   0x7fff8053770d in -[NSObject performSelector:withObject:] ()
 #15   0x7fff8b934f7e in -[NSApplication sendAction:to:from:] ()
 #16   0x7fff8b934eb2 in -[NSControl sendAction:to:] ()
 #17   0x7fff8b934ddd in -[NSCell _sendActionFrom:] ()
 #18   0x7fff8b9342a0 in -[NSCell trackMouse:inRect:ofView:untilMouseUp:] 
 ()
 #19   0x7fff8b9b3fc4 in -[NSButtonCell 
 trackMouse:inRect:ofView:untilMouseUp:] ()
 #20   0x7fff8b932eaa in -[NSControl mouseDown:] ()
 #21   0x7fff8b8fe348 in -[NSWindow sendEvent:] ()
 #22   0x7fff8b897a55 in -[NSApplication sendEvent:] ()
 #23   0x7fff8bae427e in -[NSApplication _shouldTerminate] ()
 #24   0x7fff8b838115 in -[NSApplication terminate:] ()
 #25   0x00010001a4a3 in -[AppDelegate terminate:] at 
 /Users/markus/Projects/rubiTrack/src/AppDelegate.m:219
 #26   0x7fff8053770d in -[NSObject performSelector:withObject:] ()
 #27   0x7fff8b934f7e in -[NSApplication sendAction:to:from:] ()
 #28   0x7fff8ba21bfb in -[NSMenuItem _corePerformAction] ()
 #29   0x7fff8ba21932 in -[NSCarbonMenuImpl 
 performActionWithHighlightingForItemAtIndex:] ()
 #30   0x7fff8b99f524 in -[NSMenu performKeyEquivalent:] ()
 #31   0x7fff8b99e175 in -[NSApplication _handleKeyEquivalent:] ()
 #32   0x7fff8b897536 in -[NSApplication sendEvent:] ()
 #33   0x7fff8b82e0c6 in -[NSApplication run] ()
 #34   0x7fff8baaa244 in NSApplicationMain ()
 #35   0x0001b552 in main at /Users/markus/Projects/MyApp/src/main.m:22
 #36   0x000121c4 in start ()
 
 -- 
 __
 Markus Spoettl
 ___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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

Re: NSSplitView crash upon restore from 10.8 Versions Browser

[Kevin Perry]

Looks like the crash is happening while attempting to invoke 
-respondsToSelector:.

Odds are that this is a message being sent to [self delegate], which looks like 
a deallocated object.

Is it possible that the split view is outliving its delegate? Typically, when a 
delegate gets deallocated (or when you release it for the last time), you are 
responsible for calling setDelegate:nil on anything that you had previously set 
it as a delegate for.

-KP

On Aug 20, 2012, at 12:57 PM, Jerry Krinock je...@ieee.org wrote:

 SUMMARY
 
 While testing an app in 10.8 today, it crashed three times out of six upon 
 restoring from the Versions Browser.  But the problem has now gone away.  I 
 don't have enough information to file a bug report or try any more 
 workarounds, so I'm throwing my observations out there in case someone else 
 has seen or will see this problem.  Maybe we can put our observations 
 together and get further.
 
 DETAILS
 
 Crash report is at end of this message.  You see all of the stack is in 
 Apple's code.
 
 Not knowing what else to do, I subclassed NSSplitView, to log the parameters 
 and invoke super.  After doing this, I couldn't make it crash any more :|  
 The logged parameters were always reasonable.  Assuming that this is going to 
 bite back later, I left it subclassed with the following rather do-nothing 
 implementation…
 
 - (void)resizeSubviewsWithOldSize:(NSSize)oldBoundsSize {
NSRect screenFrame = [[[self window] screen] frame] ;
 
if (oldBoundsSize.width  screenFrame.size.width) {
NSLog(@Warning 502-9481 clipped split view width to %f,
  screenFrame.size.width) ;
}
if (oldBoundsSize.height  screenFrame.size.height) {
NSLog(@Warning 502-9482 clipped split view height to %f,
  screenFrame.size.height) ;
}
 
[super resizeSubviewsWithOldSize:oldBoundsSize] ;
 }
 
 Maybe it will crash again someday and tell me something.
 
 Other factors which may be involved…
 
 • Just last week, I cleaned up and started compiling this app as 64-bit, 
 built in Xcode 4 with NSSplitView and Mac OS X 10.8 SDK.  The version now in 
 the field is 32-bit only, built in Xcode 3 with RBSplitView and Mac OS X 10.6 
 SDK.
 • In Mac OS X 10.8, in the Versions browser, when clicking on the view of the 
 old version, the view magnifies and gets bigger.  I don't remember this 
 happening in 10.7.  Possibly this resizing is triggering the crash.
 • Others have seen this method crash, although in different ways…
   http://dev.sequelpro.com/log/viewreports/1392/37095
   http://dev.sequelpro.com/log/view/1392
 
 Thanks for reading,
 
 Jerry Krinock
 
 Here is some of the crash report…
 
 Code Type:   X86-64 (Native)
 Parent Process:  launchd [125]
 User ID: 501
 
 Date/Time:   2012-08-20 05:36:00.652 -0700
 OS Version:  Mac OS X 10.8 (12A256)
 Report Version:  10
 
 Interval Since Last Report:  12640 sec
 Crashes Since Last Report:   1
 Per-App Crashes Since Last Report:   1
 
 Crashed Thread:  0  Dispatch queue: com.apple.main-thread
 
 Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
 Exception Codes: EXC_I386_GPFLT
 
 Application Specific Information:
 objc_msgSend() selector name: respondsToSelector:
 
 
 Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
 0   libobjc.A.dylib   0x7fff8c0b0590 objc_msgSend_vtable5 
 + 16
 1   com.apple.AppKit  0x7fff90a316d5 -[NSSplitView 
 resizeSubviewsWithOldSize:] + 370
 2   com.apple.AppKit  0x7fff908103c8 -[NSView 
 setFrameSize:] + 1101
 3   com.apple.AppKit  0x7fff9080fc0e -[NSView setFrame:] 
 + 299
 4   com.apple.AppKit  0x7fff90864e92 -[NSView 
 resizeWithOldSuperviewSize:] + 1502
 5   com.apple.AppKit  0x7fff90863fd7 -[NSView 
 resizeSubviewsWithOldSize:] + 318
 6   com.apple.AppKit  0x7fff908103c8 -[NSView 
 setFrameSize:] + 1101
 7   com.apple.AppKit  0x7fff9080fc0e -[NSView setFrame:] 
 + 299
 8   com.apple.AppKit  0x7fff90a10f6d -[NSTabView 
 _resizeSelectedTabViewItem] + 119
 9   com.apple.AppKit  0x7fff90a10ee4 -[NSTabView 
 setFrameSize:] + 218
 10  com.apple.AppKit  0x7fff9080fc0e -[NSView setFrame:] 
 + 299
 11  com.apple.AppKit  0x7fff90864e92 -[NSView 
 resizeWithOldSuperviewSize:] + 1502
 12  com.apple.AppKit  0x7fff90863fd7 -[NSView 
 resizeSubviewsWithOldSize:] + 318
 13  com.apple.AppKit  0x7fff908103c8 -[NSView 
 setFrameSize:] + 1101
 14  com.apple.AppKit  0x7fff9080fc0e -[NSView setFrame:] 
 + 299
 15  com.apple.AppKit  0x7fff90864e92 -[NSView 
 resizeWithOldSuperviewSize:] + 1502
 16  com.apple.AppKit  0x7fff90863fd7 -[NSView 
 resizeSubviewsWithOldSize:] + 318
 17  com.apple.AppKit  

Re: +underPageBackgroundColor

[Kevin Perry]

A stab in the dark: Have you tried running with OBJC_PRINT_REPLACED_METHODS 
set? There's a small chance that you have code in your app or a library that 
you're linking that replaces via category a method implementation internal to 
AppKit that +underPageBackgroundColor relies on.

Also, it might be interesting to turn on MallocStackLoggingNoCompact and 
finding out the backtrace of the creation of that NSColor object.

-KP

On Aug 5, 2012, at 11:06 PM, Graham Cox graham@bigpond.com wrote:

 I've tried just drawing this colour to a plain view, and I get no texture, 
 just a pale chino sort of colour. Looking at what I get from this method in 
 the debugger:
 
 (NSColor *) $1 = 0x00010983f850 NSCustomColorSpace sRGB IEC61966-2.1 
 colorspace 0.980392 0.941176 0.901961 1
 
 
 This seems to be the colour I'm seeing. I would not really expect it to be in 
 the sRGB colorspace, but the real giveaway is this - if I ask this colour for 
 its -patternImage, it throws an exception, just as the documentation says it 
 will IF IT HAS NO PATTERN IMAGE. Something's gone wrong delivering this 
 colour to my app from the internals of Cocoa. But what?
 
 
 2012-08-06 16:02:17.068 Artboard[22765:303] *** -patternImage not valid for 
 the NSColor NSCustomColorSpace sRGB IEC61966-2.1 colorspace 0.980392 0.941176 
 0.901961 1; need to first convert colorspace.
 2012-08-06 16:02:17.071 Artboard[22765:303] (
   0   CoreFoundation  0x7fff882e9716 
 __exceptionPreprocess + 198
   1   libobjc.A.dylib 0x7fff8bfb5470 
 objc_exception_throw + 43
   2   CoreFoundation  0x7fff882e94ec 
 +[NSException raise:format:] + 204
   3   AppKit  0x7fff81b09948 -[NSColor 
 patternImage] + 66
 
 
 My code:
 
   NSColor* bkg = [NSColor underPageBackgroundColor];
   NSImage* patImg = [bkg patternImage];
 
 
 
 --Graham
 
 
 
 
 
 
 
 On 04/08/2012, at 6:51 PM, Marcus Karlsson m...@acc.umu.se wrote:
 
 
 I'm getting the pattern when I use it with -setBackgroundColor: on a
 scrollview. What do you get if you try it on an empty scrollview,
 perhaps in a new project just in case there's something else that
 prevents it from drawing?
 
 Marcus
 
 
 
 ___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Problem enumerating a directory

[Kevin Perry]

You should probably try -[NSFileManager 
enumeratorAtURL:includingPropertiesForKeys:options:errorHandler:]. The 
errorHandler block will give you more detail about any errors that occur in the 
middle of the enumeration (and give you the ability to ignore them).

-KP

On Jul 27, 2012, at 9:44 AM, Mark Allan markjal...@blueyonder.co.uk wrote:

 Hi all,
 
 Apologies for asking a question which has been asked many times before, but I 
 can't seem to find an answer to this particular one.
 
 I'm trying to list a directory recursively to build up a snapshot of the 
 contents and store them in a core data DB, but keep running into issues with 
 the directory list.  The core data part is working fine as far as I can tell!
 
 I've tried writing a recursive method to call scandir() until the whole tree 
 has been visited, but I'm coming unstuck converting NSStrings to const char* 
 to char*.  Unless I supply the path directly as a hard-coded C-string 
 /Users/mark, it works for a while, but then sometimes it forgets to add 
 /Users/mark and starts scanning directories at the root of my HD!  Hard 
 coding the C string works perfectly but obviously isn't an option.
 
 -(void) scan: (char *)theDir{
struct dirent **namelist;
int n;
   size_t thisDirLength = strlen(theDir);
   
n = scandir(theDir, namelist, 0, NULL);
if (n  0){
perror(scandir);
   }
else {
while(n--) {
   theCounter++;
   if (theCounter = 1000) {
   theCounter = 0;
   [[self managedObjectContext] save:NULL];
   [[self managedObjectContext] reset];
   [thePool drain];
   thePool = [[NSAutoreleasePool alloc] init];
   }
   if ((strcmp(namelist[n]-d_name,.) != 0)  
 (strcmp(namelist[n]-d_name,..) != 0)) {
   char* fullPath = malloc(thisDirLength + 
 strlen(namelist[n]-d_name) + 2);
   strcpy(fullPath, theDir);
   strcat(fullPath, /);
   strcat(fullPath, namelist[n]-d_name);
   
   [self addEntityWithPath:[NSString 
 stringWithCString:fullPath encoding:NSUTF8StringEncoding]];
   
   if (namelist[n]-d_type == DT_DIR) {
   [self scan:fullPath];
   }
   free(fullPath);
   }
free(namelist[n]);
}
free(namelist);
}
 }
 
 
 I then gave up on that approach and opted for the easier but slower cocoa 
 solution (NSDirectoryEnumerator) but for some reason it gives up with neither 
 an error nor a warning about half way through the tree.  Could it be that 
 modifications to the file system during the enumeration are causing it to 
 fail?
 
 
 -(void) startSnapshotForPath:(NSString *) thePath {
   int theCounter = 0;
   NSDirectoryEnumerator *dirEnumerator = [[NSFileManager defaultManager] 
 enumeratorAtPath: thePath];
   thePool = [[NSAutoreleasePool alloc] init];
   
   for (NSString *theSubPath in dirEnumerator) {
   [self addEntityWithPath:[thePath 
 stringByAppendingPathComponent:theSubPath]];
   theCounter++;
   if (theCounter = 1000) {
   theCounter = 0;
   [[self managedObjectContext] save:NULL];
   [[self managedObjectContext] reset];
   [thePool drain];
   thePool = [[NSAutoreleasePool alloc] init];
   }
   }
   
   [[self managedObjectContext] save:NULL];
   [[self managedObjectContext] reset];
   [thePool drain];
 }
 
 I've also tried Uli Kusterer's UKDirectoryEnumerator but that doesn't appear 
 to be recursive!  I suspect (although I haven't tried) that requesting the 
 type of the path (i.e. file/directory) and creating a new 
 UKDirectoryEnumerator for each subdirectory would be massively expensive.
 
 Does anyone have any suggestions for where I can go from here please?  How 
 can I find out why NSDirectoryEnumerator is failing half-way through the 
 process, and how can I stop it doing so? Failing that, does anyone have a 
 better suggestion for how I can build the snapshot please?
 
 Many thanks
 Mark
 ___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.com


___

Re: NSDocument -canCloseDocumentWithDelegate::: not called when terminating

[Kevin Perry]

I can't really recommend an approach that essentially lies about the dirty 
state of a document. If you have something to write into the document bundle, 
then the document is dirty and it should be declared so with the available 
NSDocument APIs. If the existing APIs don't meet your needs for whatever 
reason, file an enhancement request.

Also, NSDocument and NSFileWrapper (assuming you're using it) might not take it 
very kindly if you modify the package outside of the normal -save… and -write… 
APIs, especially if/when you adopt Autosave and iCloud.

To answer your question more directly—there is no public callback that is 
invoked in every case on Quit when the document returns NO from 
-isDocumentEdited or -hasUnautosavedChanges. In fact, sometimes nothing gets 
invoked at all because when -isDocumentEdited returns NO, NSDocument enables 
sudden termination, which allows -[NSApplication terminate:] to take shortcuts 
and Shutdown/Restart/Logout to kill the app.

-KP

On Jul 23, 2012, at 8:12 AM, Markus Spoettl ms_li...@shiftoption.com wrote:

 Hello,
 
  when I close my document window without terminating the application, 
 -canCloseDocumentWithDelegate::: is called, independent of whether the 
 document is dirty.
 
 When I quit the application, -canCloseDocumentWithDelegate::: is only called 
 if the document reports it is dirty. If it is not dirty, AppKit takes a 
 shortcut calls into -close directly. NSDocumentController doesn't seem to be 
 involved either.
 
 Why do I need this?
 
 My document is stored in a package that contains a preferences file. When the 
 document is saved, the preferences file is saved as part of the package. So, 
 if it is dirty at the time of closing it's going to be saved. If the document 
 isn't dirty, I'd like to update the preference file only.
 
 A good place would have been -canCloseDocumentWithDelegate::: because I can 
 check whether the document is dirty and save the preferences file if 
 necessary. That doesn't work if it's not getting called of course. -close is 
 called after the document is saved, so the dirty flag there isn't helpful.
 
 Are there better options to do a last-minute save? I do not want to change 
 the design, meaning I don't want preferences to contribute to the change 
 count state or even worse be undoable. Plus I do want the preferences to be 
 stored in the package, not someplace else (restoration state for example).
 
 Thanks for any pointers!
 
 Regards
 Markus
 -- 
 __
 Markus Spoettl
 ___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSDocument -canCloseDocumentWithDelegate::: not called when terminating

[Kevin Perry]

On Jul 23, 2012, at 10:51 AM, Markus Spoettl ms_li...@shiftoption.com wrote:

 On 7/23/12 6:22 PM, Kyle Sluder wrote:
 I don't have my crazy autosave flowchart handy, but I *think* you should be
 able to simply override -hasUnautosavedChanges to return YES if either super
 returns YES or if your preferences file needs to be saved.
 -autosaveWithImplicitCancellability:: is documented to check
 -hasUnautosavedChanges, so I would assume that it is called unconditionally
 at all places where AppKit wants to ensure the document is written to disk if
 necessary.
 
 Of course, this assumes you are returning YES from +autosavesInPlace.
 

-autosaveWithImplicitCancellability: does check -hasUnautosavedChanges, but the 
quit procedure doesn't—it actually checks -isDocumentEdited. And when 
autosavesInPlace returns NO, overriding -isDocumentEdited to return YES will 
still result in the dirty dot in the close button, unless you go to great 
lengths to prevent the state from bubbling up to -[NSWindow setDocumentEdited:].

 If there would be a way to tell NSDocument to forgo asking whether to save a 
 document if -isDocumentEdited returned YES, and instead just save it, that 
 would be a solution. All I want is a silent save, when only preferences need 
 to be saved (since I'm using file wrappers it would be quick too because I'm 
 only replacing the wrapper for my preferences).
 
 I don't see how I could do that. Is there a way?

You're talking about the Do you want to save changes to this document dialog 
when clicking the close button or quitting? The only way to bypass that is to 
override canCloseDocumentWithDelegate:… check for your special 
-isDocumentEdited==YES, but don't show a panel case, and invoke the 
shouldCloseSelector (after writing the preferences file) without calling super.


But really, if you and other developers feel there is a need for functionality 
to mark a document as needing saving, but without ever informing the user about 
it or giving them a chance to cancel it, then file an enhancement request for 
such an API.

-KP


___

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: notification upon restoring a version

[Kevin Perry]

When the user enters or exits Versions, there are notifications sent out called 
NSWindowWillEnterVersionBrowserNotification, 
NSWindowDidEnterVersionBrowserNotification, etc. (see NSWindow.h)

You will know when a user chooses Restore, because the NSDocument instance will 
be sent -revertToContentsOfURL:ofType:error: (once the version's contents are 
written in place over the existing file).

[kevin perry];

On Jun 25, 2012, at 1:44 PM, qvacua qva...@gmail.com wrote:

 Hi,
 
 are there notifications or delegate methods of NSDocument (or
 NSDocumentController) which are called when the user invokes Versions
 and/or restores a version of a document?
 
 Thanks in advance and best,
 Tae
 ___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSDocument autosave doesn't show as edited

[Kevin Perry]

Does Revert to Last Saved become available after saving and editing? Which 
NSDocument methods are you overriding?

It is indeed -updateChangeCount: that controls the 'Edited' state. You might 
try overriding with a call to super and setting a breakpoint or adding a log to 
make sure it's being called as expected (with NSChangeDone). That should be 
getting called by the undo mechanism, but it would be good to verify.

The only other idea I have is that maybe you need to invoke -[NSTextView 
breakUndoCoalescing] before saving, like TextEdit does.

-KP

On May 23, 2012, at 8:18 AM, Martin Hewitson martin.hewit...@aei.mpg.de wrote:

 Dear list,
 
 I have an NSDocument app that implements autosave and versions on Lion. The 
 NSDocument subclass is essentially a text editor. If I create a new document 
 and type something in the text view then the 'Edited' tag appears. I then 
 save the document to disk. After this, typing in the text view no longer 
 triggers the 'Edited' state and hence no versions are autosaved. However, 
 using Save a Version works fine, and I can view the versions in the 
 versions browser.
 
 Does anyone have a clue what I'm missing? As I understand it, if I'm using 
 the default NSDocument undo mechanism (which I believe I am - at least 
 undo/redo works on the editor) then I don't need to manually call 
 -updateChangeCount:.
 
 What else could I be doing wrong?
 
 Many thanks for any suggestions,
 
 Martin___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSDocument autosave doesn't show as edited

[Kevin Perry]

On May 23, 2012, at 9:43 AM, Martin Hewitson martin.hewit...@aei.mpg.de wrote:
 It is indeed -updateChangeCount: that controls the 'Edited' state. You might 
 try overriding with a call to super and setting a breakpoint or adding a log 
 to make sure it's being called as expected (with NSChangeDone). That should 
 be getting called by the undo mechanism, but it would be good to verify.
 
 It's being called only once when the document is loaded. It gets called with 
 NSChangeCleared, which I guess is what you would expect. I've no idea why it 
 isn't called after edits.
 
 If I return NO from autosavesInPlace, I see the same behaviour. The dirty dot 
 in the red button does not appear after an edit. If I listen for text did 
 change notifications from the text view and call -updateChangeCount in there, 
 then everything works normally.

Perhaps the NSTextView's NSUndoManager isn't the same as the NSDocument's?

This is supposed to work automatically, but maybe you've done something to 
prevent this. If its delegate doesn't specify one, the NSTextView searches the 
responder chain for something that responds to -undoManager. Usually that's the 
NSWindow. If its delegate doesn't specify one, the window will get its undo 
manager from [[[self windowController] document] undoManager].

Compare the pointers of [textView undoManager] and [document undoManager]. I 
suspect they're different.
___

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: NSDocument app: combine multiple file contents to open one window instead of multiple windows

[Kevin Perry]

Unless I'm mistaken, I don't think Gilles is trying to create a multi-document 
window interface like Xcode or Preview. It sounds like he wants a single 
window with a single view (or set of related views) that simply displays the 
contents of multiple files in aggregate.

If that understanding is correct, then NSDocument is not the right model here. 
NSDocument is very specifically about representing a single file or file 
package on disk and encapsulating the algorithms for both writing to and 
reading from the contents of said file or file package on disk. It is not built 
to represent the contents of multiple independent files.

Attempting to shoehorn NSDocument into this use case will buy you very little 
and give you many problems. You're much likely better off using NSOpenPanel, 
NSWindowController, NSFileManager, and NSData directly to open and display 
contents of user-selected files.

On the other hand, if your app creates a visualization that you want to be able 
to save, modify, reopen, etc., then NSDocument is likely what you want, as long 
as you realize the difference between opening documents and importing files 
into a document. The documents your app would deal in would be a custom file 
type that your app defines and creates. Files or file packages of this type 
would contain all the data necessary to reconstruct the visualization when 
reopening the document including references to or copies of imported files. 
The files that are imported into the document would not have NSDocument 
instances of their own (unless you were creating something like Xcode's 
document-within-a-document model). You're still likely going to need to use 
NSOpenPanel, NSFileManager, and NSData yourself to handle importing these files.

-KP

On Apr 6, 2012, at 9:13 AM, Kyle Sluder k...@ksluder.com wrote:

 On Apr 6, 2012, at 8:29 AM, Gilles Celli gilles.ce...@ecgs.lu wrote:
 
 Versions ? Well here in my case for now I don't need it for my application 
 since it's kind a viewer / visualizer of the data, I'm not editing or 
 changing anything
 to the file…it's a like a PDF viewer but here for data / graphs.
 
 Fair enough. But you do need to deal with other apps using Versions and file 
 coordination against the files you have open. If you don't follow 
 NSDocument's standard windowing paradigm, it can't perform its normal 
 behavior (like throwing up a sheet alerting to the user that a file has 
 changed).
 
 Or hell, maybe it can. You might be able to use -windowForSheet to point 
 NSDocument at the shared window.
 
 
 
 Maybe you got me wrong but it's simply to append the file's contents that 
 the user selected in the Open Panel and put these selected file contents
 (=NSString *fileContent1 + *fileContent 2 etc.) to one big appended NSString 
 *multiContent, then of course call makeWindowControllers
 to open the NSDocument Window.
 
 I think you will not want any of your documents to own your window; the 
 window should be owned by the app and -makeWindowControllers would do 
 nothing. You can monitor your NSDocumentController to determine whether to 
 open or close your shared window.
 
 
 The advantage of using NSDocument are multiple, and mainly printing to PDF 
 works great etc. so it should be possible (since it's possible on Windows XP 
 ;-)
 
 Of course you can do pretty much anything on OS X that you can do on Windows. 
 But OS X's frameworks are designed to discourage bad decisions. The bias 
 inherent in the frameworks produces a consistency across apps that users 
 appreciate.
 
 Just because something is easy on some other platform does not mean it should 
 be easy on OS X.
 
 That said, it sounds like you have a decent use case that won't fight the 
 framework too badly.
 
 --Kyle Sluder
 
 ___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSTextFinder: endless loops asking for string at index that doesn't exist.

[Kevin Perry]

Eric,

It's possible that NSTextFinder has a bug, in which case you should file a 
Radar with a sample app that reproduces the problem. Having that information, 
it may be possible to identify a workaround.

However, first tell me—are you setting the endsWithSearchBoundary parameter to 
YES for the last substring?

-KP

On Mar 28, 2012, at 1:58 PM, Eric Slosser eric.slos...@v-fx.com wrote:

 I'm using the NSTextFinder API with the stringAtIndex:len:effectiveRange: 
 style of exposing the text.
 
 I have a test case which has 4 strings in it, foo1 .. foo4.  I show the 
 findbar, type 'foo', and click the 'find next' control.
 
 Here are the calls that my client receives and the results being passed back.
 
 firstSelectedRange = {0, 0} (char)
 stringLength:16
 
 firstSelectedRange = {0, 0} (char)
 stringAtIndex:0  len:4 effRange:{0, 4} 'foo1'
 stringAtIndex:4  len:4 effRange:{4, 4} 'foo2'
 stringAtIndex:8  len:4 effRange:{8, 4} 'foo3'
 stringAtIndex:12  len:4 effRange:{12, 4} 'foo4'
 setFirstSelectedRange = {0, 3}
 KESIImageView+Finding scrollRangeToVisible: = {0,3}
 
 So far, so good.  But when I check the replace checkbox, then click the 
 replace control, I see the following:
 
 --- replace foo with BA
 stringLength:16
 firstSelectedRange = {0, 3} (char)
 replaceCharactersInRange: {0, 3} withString:'BA'
 setFirstSelectedRange = {0, 2}
 
 firstSelectedRange = {0, 2} (char)
 stringAtIndex:2  len:3 effRange:{0, 3} 'BA1'
 stringAtIndex:3  len:4 effRange:{3, 4} 'foo2'
 stringAtIndex:7  len:4 effRange:{7, 4} 'foo3'
 stringAtIndex:11  len:4 effRange:{11, 4} 'foo4'
 stringAtIndex:15  len:0 effRange:{15, 0} '(null)'
 stringAtIndex:15  len:0 effRange:{15, 0} '(null)'
 stringAtIndex:15  len:0 effRange:{15, 0} '(null)'
 … endless loop
 
 NSTextFinder keeps asking about the string that starts at index 15, but 
 because of the replacement, the only flattened string is only 15 chars long.  
 My 'stringLength' is only called before the replace, not after.  
 
 Incremental searching is not enabled, so it's not that I'm forgetting to call 
 -(void)noteClientStringWithChange.
 
 Am I doing something wrong?  How can I get NSTF to understand that the client 
 doesn't have anything at index 15?
 
 
 
 
 ___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSSplitView-like cursor grabbing

[Kevin Perry]

It overrides -[NSView hitTest:] to return self for clicks inside the draggable 
region.

-KP

On Mar 26, 2012, at 10:30 AM, Markus Spoettl ms_li...@shiftoption.com wrote:

 Hello all,
 
  does anyone know how to grab the cursor like NSSplitView does? It somehow 
 manages to know that the cursor is near a divider when it actually is within 
 a sub-view, it also captures clicks in those cases, even though they should 
 strictly be sent to the sub-view the cursor is over.
 
 How does it do that?
 
 Regards
 Markus
 -- 
 __
 Markus Spoettl
 ___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: can't get NSTextFinder to show the find panel

[Kevin Perry]

The public NSTextFinder API doesn't provide a way for you to access the 
old-style find panel.

-KP

On Mar 23, 2012, at 6:18 AM, Eric Slosser eric.slos...@v-fx.com wrote:

 I'm trying to use the NSTextFinder object on Lion, from an app whose base SDK 
 is Tiger.
 
 I've created an instance of NSTextFinder, called its -setClient: method, my 
 client implements all methods of the NSTextFinderClient (using -string).  My 
 client does _not_ do the NSTextFinderBarContainer protocol, I want to use the 
 panel.
 
 I expect that calling [m_textFinder 
 performAction:NSTextFinderActionShowFindInterface] would make the find panel 
 appear, but it doesn't.
 
 It's not the app or how it's built, because in another window, I have an 
 NSTextView, and it is able to show the panel.  I've traced its calls and see 
 it's using NSTextFinder.
 
 What am I doing wrong?
 
 TIA!
 ___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSUndoManager w/ Document based app

[Kevin Perry]

Hi,

If your document class returns YES for +autosavesInPlace (which it hopefully 
is!), then the dirty dot is no longer used.

The dot used to suggest that what was in memory differed from what's currently 
on disk. With Lion's Autosave feature, the intent is to make it appear to the 
user that what's on disk and what's in memory are the same at all times. Hence, 
the dirty dot was removed, and the Edited text was added to the title bar 
(for non-Untitled documents) to instead more explicitly denote that the 
document's contents have been edited since last opened or saved.

-KP

On Jan 25, 2012, at 1:23 PM, Luc Van Bogaert wrote:

 Hi,
 
 I'm currently experimenting for the first time with NSUndoManager in a 
 document-based app. I think I understand the most important basics, and have 
 even  succeeded in implementing some working code, where objects can be added 
 or removed from an array property in some model object, which is a subclass 
 of NSDocument, all with working undo/redo capability.
 
 One thing I don't quite understand is why my document windows won't display 
 the 'dot' in the close button when the model array property changes, even 
 though my documents seem to keep track of the edited state correctly when I 
 close the windows, because closing a dirty document window brings up a save 
 dialog as expected, and a unedited one does not.
 
 As I understand, this should automatically be taking care of by the undo 
 manager, and I'm not supposed to send a updateChangeCount: message.
 
 Thanks for any advice.
 
 -- 
 Luc Van Bogaert
 
 ___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSDocument Serialization (-performSynchronousFileAccessUsingBlock: and friends)

[Kevin Perry]

On Sep 29, 2011, at 4:41 PM, Kyle Sluder wrote:

 [...snip...]
 
 A general issue I have with asynchronous saving: what if the save
 operation fails? The user has now made additional changes, but their
 Save a Version operation did not create a version for them. So now
 they can't roll back to the timepoint they thought they created.

That is true. Perhaps this is something that could be improved in the future. I 
suppose one way to fix this would be to retain the 'snapshot' used for async 
saving and retry again later?

 Of course I have another question.
 
 On Thu, Sep 29, 2011 at 12:33 PM, Kevin Perry kpe...@apple.com wrote:
 NSDocument's NSFilePresenter methods use 
 performAsynchronousFileAccessUsingBlock: internally, so if something else 
 current has file access, the NSFileCoordinator requests are indeed blocked 
 (or enqueued).
 
 What about NSFilePresenter methods that require presenting a sheet? Do
 they instead wrap their calls to -performAsynchronousFileAccess: in a
 call to -performActivityWithSynchronousWaiting:NO?

Yes.

-KP___

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

Re: NSDocument Serialization (-performSynchronousFileAccessUsingBlock: and friends)

[Kevin Perry]

On Sep 30, 2011, at 8:47 AM, Kevin Perry wrote:

 On Sep 29, 2011, at 4:41 PM, Kyle Sluder wrote:
 
 [...snip...]
 
 A general issue I have with asynchronous saving: what if the save
 operation fails? The user has now made additional changes, but their
 Save a Version operation did not create a version for them. So now
 they can't roll back to the timepoint they thought they created.
 
 That is true. Perhaps this is something that could be improved in the future. 
 I suppose one way to fix this would be to retain the 'snapshot' used for 
 async saving and retry again later?

Alternatively, an application may choose to opt out of asynchronous saving for 
NSSaveOperations only.

-KP___

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

Re: NSDocument Serialization (-performSynchronousFileAccessUsingBlock: and friends)

[Kevin Perry]

The header documentation for -performSynchronousFileAccessUsingBlock: (which 
also applies to performAsynchronousFileAccessUsingBlock:) says:

this method's primary use is to wait for asynchronous saving, but in 
contrast with that method it is only for use to wait for the part of an 
asynchronous saving operation that actually touches the document's file or 
values in memory that are in some way relative to the document's file.

and:

In general you should use this method or 
-performAsynchronousFileAccessUsingBlock: around code that gets or sets values 
in memory that only make sense in the context of the document file's current 
state.

In other words, these methods are used to prevent multiple operations from 
operating simultaneously on the document's file and the file-related ivars. In 
order to accomplish this, asynchronous saving must be implemented like so 
(simplified, obviously):

performAsynchronousFileAccessUsingBlock:^(fileAccessCompletionHandler) {
dispatch_async(^{
write();
continueAsynchronousWorkOnMainThreadUsingBlock:^{
handle error, or update file ivars (fileURL, 
fileModificationDate, fileType, change count, etc.)
fileAccessCompletionHandler();
}
})
}
waitForUserInteractionUnblocking()

If it were to call the fileAccessCompletionHandler any earlier then it might be 
possible, for example, for -fileModificationDate to be invoked on the main 
thread after -writeSafelyToURL: has written the file, but before the value has 
been properly updated.


To address the example in your previous email, you want to do the latter 
option, where you protect both -fileURL and the actual operation on the result 
in a single call to -perform(A)synchronousFileAccessUsingBlock:. That is the 
only way to ensure that something else within the process (or something in 
another process using File Coordination) doesn't move the file out from under 
you before you get to invoke -moveItemAtURL:toURL:error: or try to write to the 
old URL before your move is complete, etc.

I don't see the nested uses of performSynchronousFileAccessUsingBlock: you 
mentioned in that code, but that's not a problem anyway, since file access is 
recursive, as long as it happens synchronously within the outer-most file 
access block (a fact that admittedly may not be documented well anywhere).

-KP

On Sep 28, 2011, at 11:23 PM, Kyle Sluder wrote:

 On Wed, Sep 28, 2011 at 10:55 PM, Kyle Sluder kyle.slu...@gmail.com wrote:
 I'd really appreciate if the documentation spelled out exactly how
 NSDocument uses these methods.
 
 To give an example of a specific NSDocument usage that I'd like to
 know about: how does asynchronous saving use
 -performAsynchronousFileAccessUsingBlock:? I'm envisioning something
 like this:
 
 - (void)saveToURL:(NSURL *)url ofType:(NSString *)type
 forSaveOperation:(NSSaveOperation)op completionHandler:(void
 (^)(NSError *errorOrNil))completionHandler {
  id saveToken = [self changeCountTokenForSaveOperation:op];
 
  if ([self canAsynchronouslyWriteToURL:url ofType:type forSaveOperation:op]) {
[self performAsynchronousFileAccessUsingBlock:(void
 (^fileAccessCompletionHandler)(void)) {
  dispatch_async(backgroundQueue, ^{
NSError *error;
BOOL success;
success = [self writeSafelyToURL:url ofType:type
 forSaveOperation:op error:error];
 
fileAccessCompletionHandler();
 
if (success)
  [self continueAsynchronousWorkOnMainThreadUsingBlock:^{
[self setFileURL:url];
[self setFileModificationDate:[NSDate date]];
[self setFileType:type];
[self setAutosavedContentsFileURL:url];
[self updateChangeCountWithToken:token forSaveOperation:op];
completionHandler(nil);
  }];
else
  [self continueAsynchronousWorkOnMainThreadUsingBlock:^{
completionHandler(error);
  }];
});
 
WaitForUnblockUserInteraction();
  }];
}
 }
 
 Am I on the right track here?
 
 --Kyle Sluder
 ___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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 

Re: NSDocument Serialization (-performSynchronousFileAccessUsingBlock: and friends)

[Kevin Perry]

On Sep 29, 2011, at 12:00 PM, Kyle Sluder wrote:

 On Thu, Sep 29, 2011 at 9:20 AM, Kevin Perry kpe...@apple.com wrote:
 If it were to call the fileAccessCompletionHandler any earlier then it might
 be possible, for example, for -fileModificationDate to be invoked on the
 main thread after -writeSafelyToURL: has written the file, but before the
 value has been properly updated.
 
 Thank you, this is enlightening. Your sketch omitted the take a
 snapshot of the document wrapper part; I assume that comes prior to
 the call to -performAsynchronousFileAccess…, but still within the same
 enveloping call to -performActivityWithSynchronousWaiting:….

For Versions, you mean? That also happens within 
-performAsynchronousFileAccess:, because we don't want anything else touching 
the file while we're preserving the version.

 However, I am still concerned about blocking other apps. According to
 the documentation, -performAsynchronousFileAccessUsingBlock: does not
 block the main thread. But it surely has to block _something_ until
 the fileAccessCompletionHandler is called.

Yeah, it blocks further invocations of 
-perform(A)synchronousFileAccessUsingBlock:, where block means enqueue for 
async access, and block the thread for sync access.

 We've guaranteed that we've
 escaped the -performAsynchronousFileAccess stack frame by calling
 dispatch_async(). Is it just blocking other NSFileCoordinator requests
 until the fileAccessCompletionHandler is called?

NSDocument's NSFilePresenter methods use 
performAsynchronousFileAccessUsingBlock: internally, so if something else 
current has file access, the NSFileCoordinator requests are indeed blocked (or 
enqueued).

 In that case, why is
 the fileAccessCompletionHandler important for synchronizing with our
 own main thread access, and how can it possibly protect our calls to
 -fileURL from within the block passed to dispatch_async?

With async file access, you have sole access to the file until you call 
fileAccessCompletionHandler, even if you move out of the original block's 
execution with dispatch_async, etc. For example, if you have these two methods:

doSync:
performSyncFileAccess:{
[self setFileURL:]
}

doAsync:
performAsyncFileAccess:^{
dispatch_async(^{
[self fileURL]
fileAccessCompletionHandler()
})
}

and you call them like this:

[self doAsync]
[self doSync]

The [self fileURL] call in doAsync is safe, because doSync's 
performSyncFileAccess: won't run doAsync's fileAccessCompletionHandler() is 
called.

Similarly, if you have this additional method:

doAsync2:
performAsyncFileAccess:^{
[self setFileURL:]
}

and call them like this:

[self doAsync]
[self doAsync2]

This is also safe because doAsync2's block won't be invoked until doAsync's 
fileAccessCompletionHandler() is called.


 Does
 -performAsynchronousFileAccess does not block the main thread really
 mean if I can't execute the block now, I will execute it later, and
 in doing so the thread on which this method was called (which might be
 the main thread) will be blocked until the block has finished
 executing _and_ the fileAccessCompletionHandler has been called?

No, because blocking the thread until fileAccessCompletionHandler is called 
would defeat the purpose of asynchronous saving. The thread is unblocked 
immediately after the block finishes executing. The main thread will only be 
blocked if performSynchronousFileAccess: is called later and the async file 
access hasn't yet completed.

 In my original example, I was using -performSynchronousFileAccess
 around my call to -moveItemAtURL:toURL:error: and the subsequent call
 to -presentError:, rather than -performAsynchronousFileAccess. If
 -presentError: throws up an app-modal alert, then I've blocked any
 other pending NSFileCoordinator clients who want to access my file,
 correct? This can include other file presenters in my own app, who
 might perhaps want to read the document in the background?

There should be no need to include error presentation with the file access. 
Sorry I missed that in the original example. The usual pattern is:

performAsyncFileAccess:^{
NSError *error;
doSomethingWithFile(error);

fileAccessCompletionHandler();
handleError(error);
}

or:

__block NSError *error;
performSyncFileAccess:^{
doSomethingWithFile(error);
}
handleError(error);

 Or do I need to switch to -performAsynchronousFileAccess to make sure
 I don't cause other apps to beachball? If so, would it look roughly
 like this?
 
 /**
 * Again, not meant to be a good example of using NSFileManager.
 **/
 
 - (BOOL)isInHomeDirectory {
 NSURL *fileURL = [self fileURL];
 return [[fileURL absoluteString] hasPrefix:NSHomeDirectory()];
 }
 
 - (IBAction)doThing:(id)sender {
  [self performActivityWithSynchronousWaiting:YES usingBlock:^{
[self

Re: Duplicating an edited document in 10.7.1

[Kevin Perry]

There's a bug in NSDocument in that it doesn't protect itself against nil 
return values from -fileNameExtensionForType:saveOperation:. To work around, 
make sure you return a non-nil value from that method.

-KP

On Sep 20, 2011, at 2:49 AM, Gerriet M. Denkmann wrote:

 In my toy editor I open an existing document, modify it and click Duplicate.
 
 A Sheet comes down and tells me that the duplicate will contain my latest 
 modifications.
 I click the default Duplicate button and get:
 
 2011-09-20 16:29:43.164 TextEditor[4062:707] *** -[NSPathStore2 
 stringByAppendingPathExtension:]: nil argument
 2011-09-20 16:29:43.213 TextEditor[4062:707] (
   0   CoreFoundation  0x7fff8742a986 
 __exceptionPreprocess + 198
   1   libobjc.A.dylib 0x7fff80f84d5e 
 objc_exception_throw + 43
   2   CoreFoundation  0x7fff8742a7ba 
 +[NSException raise:format:arguments:] + 106
   3   CoreFoundation  0x7fff8742a744 
 +[NSException raise:format:] + 116
   4   Foundation  0x7fff89d8a172 
 -[NSPathStore2 stringByAppendingPathExtension:] + 112
   5   AppKit  0x7fff845808c3 -[NSDocument 
 _preserveCurrentVersionForReason:error:] + 579
   6   AppKit  0x7fff84586bc3 
 __-[NSDocument 
 duplicateDocumentWithDelegate:didDuplicateSelector:contextInfo:]_block_invoke_3
  + 119
   7   AppKit  0x7fff845819a9 -[NSDocument 
 _something:wasPresentedWithResult:soContinue:] + 21
   8   AppKit  0x7fff84472bee -[NSAlert 
 didEndAlert:returnCode:contextInfo:] + 93
   9   AppKit  0x7fff8447f356 
 -[NSApplication endSheet:returnCode:] + 275
   10  AppKit  0x7fff84472ab4 -[NSAlert 
 buttonPressed:] + 265
   11  CoreFoundation  0x7fff8741a11d -[NSObject 
 performSelector:withObject:] + 61
   12  AppKit  0x7fff842ce852 
 -[NSApplication sendAction:to:from:] + 139
   13  AppKit  0x7fff842ce784 -[NSControl 
 sendAction:to:] + 88
   14  AppKit  0x7fff842ce6af -[NSCell 
 _sendActionFrom:] + 137
   15  AppKit  0x7fff844d758a 
 -[NSButtonCell performClick:] + 594
   16  AppKit  0x7fff84337afd -[NSButton 
 performKeyEquivalent:] + 368
   17  AppKit  0x7fff84337722 -[NSView 
 _performKeyEquivalent:conditionally:] + 45
   18  AppKit  0x7fff8433796d -[NSControl 
 _performKeyEquivalent:conditionally:] + 119
   19  AppKit  0x7fff84337850 -[NSView 
 performKeyEquivalent:] + 155
   20  AppKit  0x7fff84473d06 
 -[_NSAlertContentView performKeyEquivalent:] + 92
   21  AppKit  0x7fff84337722 -[NSView 
 _performKeyEquivalent:conditionally:] + 45
   22  AppKit  0x7fff84337850 -[NSView 
 performKeyEquivalent:] + 155
   23  AppKit  0x7fff84337722 -[NSView 
 _performKeyEquivalent:conditionally:] + 45
   24  AppKit  0x7fff84337695 -[NSWindow 
 performKeyEquivalent:] + 58
   25  AppKit  0x7fff8485caeb -[NSWindow 
 keyDown:] + 74
   26  AppKit  0x7fff84297ad2 -[NSWindow 
 sendEvent:] + 7404
   27  AppKit  0x7fff8422ff19 
 -[NSApplication sendEvent:] + 5665
   28  AppKit  0x7fff841c642b 
 -[NSApplication run] + 548
   29  AppKit  0x7fff852a 
 NSApplicationMain + 867
   30  TextEditor  0x00011bc0 main + 32
   31  TextEditor  0x00011b94 start + 52
   32  ??? 0x0001 0x0 + 1
 )
 
 TextEdit can duplicate a modified document without any problems.
 
 So obviously my program does something not quite right.
 But as there is hardly any of my own code in this backtrace, how can I debug 
 this?
 
 
 Kind regards,
 
 Gerriet.
 
 
 ___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or 

Re: Odd error logged when coming back from 'Browse All Versions'

[Kevin Perry]

Hi Graham,

Right now, Versions doesn't bring back the inspectors automatically, but it may 
do so in the future. For now, bringing them back manually is the right thing.

As for the logging, it's a known OS bug, but is basically harmless.

Thanks.

On Aug 23, 2011, at 8:08 PM, Graham Cox wrote:

 My app has floating palettes.
 
 When I go to 'Browse All Versions...', these palettes get moved beyond the 
 edges of the screen. When I come back from browsing the versions, the 
 palettes are not there until I force then to show again using the 
 controller's -showWindow: method - they come back in the right place however. 
 In addition, I get this logged:
 
 Aug 24 12:59:44 Grahams-iMac Artboard[6712] Error: kCGErrorFailure: 
 CGSDisplayID: App trying to enumerate [0 to CGSGetNumberOfDisplays()] instead 
 of using CGSGetDisplayList().  Compensating...
 Aug 24 12:59:44 Grahams-iMac Artboard[6712] Error: kCGErrorFailure: Set a 
 breakpoint @ CGErrorBreakpoint() to catch errors as they are logged.
 
 
 So I tried to set a breakpoint on CGErrorBreakPoint() as suggested, and it's 
 never triggered. I can't find any reference to any of the mentioned functions 
 CGSDisplayID, CGSGetNumberOfDisplays or CGSGetDisplayList, and I'm not using 
 these directly anywhere.
 
 Any ideas?
 
 
 --Graham___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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

Re: printDocument: hangs on Lion?

[Kevin Perry]

Hi Graham,

First of all, -printShowingPrintPanel: is deprecated. I believe if you were to 
stop overriding that method and use -printOperationWithSettings:error: and 
-runModalPrintOperation:delegate:didRunSelector:contextInfo: instead the 
problem would go away.

Otherwise, you've found the crux of your problem with your backtrace. There are 
two nested invocations of -performActivityWithSynchronousWaiting:usingBlock:, 
which without the use of -continueActivityUsingBlock:, behave like 
non-recursive locks, leading to deadlock when you call them re-entrantly. 
Simply wrap your invocation of -runModalPrintOperation: in the block argument 
of -continueActivityUsingBlock: and it should work correctly.

-KP

On Aug 22, 2011, at 8:00 PM, Graham Cox wrote:

 I set a breakpoint on -[NSDocument 
 performActivityWithSynchronousWaiting:usingBlock:]
 
 
 It is hit exactly twice in my test case, both in the same call stack, which 
 is:
 
 #00x7fff881b2464 in -[NSDocument 
 performActivityWithSynchronousWaiting:usingBlock:] ()
 #10x7fff881a2518 in -[NSDocument 
 runModalPrintOperation:delegate:didRunSelector:contextInfo:] ()
 #20x00010009e454 in -[GCOrteliusDocument 
 runModalPrintOperation:delegate:didRunSelector:contextInfo:] at 
 /Users/grahamcox/Projects/Artboard/Artboard/Source/Code/GCOrteliusDocument.m:1464
 #30x0001002f59fc in -[DKDrawingDocument printShowingPrintPanel:] at 
 /Users/grahamcox/Projects/DrawKit/DrawKit/../Source/Code/DKDrawingDocument.m:923
 #40x7fff881a1a52 in __-[NSDocument 
 printDocumentWithSettings:showPrintPanel:delegate:didPrintSelector:contextInfo:]_block_invoke_2
  ()
 #50x7fff881a95e0 in -[NSDocument _commitEditingThenContinue:] ()
 #60x7fff881a52ab in -[NSDocument 
 _commitEditingWithDelegate:didSomethingSelector:contextInfo:thenContinue:] ()
 #70x7fff881a18bf in __-[NSDocument 
 printDocumentWithSettings:showPrintPanel:delegate:didPrintSelector:contextInfo:]_block_invoke_1
  ()
 #80x7fff881b2670 in -[NSDocument 
 performActivityWithSynchronousWaiting:usingBlock:] ()
 #90x7fff881a17d1 in -[NSDocument 
 printDocumentWithSettings:showPrintPanel:delegate:didPrintSelector:contextInfo:]
  ()
 #10   0x7fff881a1763 in -[NSDocument printDocument:] ()
 #11   0x7fff90c4d11d in -[NSObject performSelector:withObject:] ()
 
 
 The first time it is hit is at line #8, the second time at line number #0. It 
 is not hit at any time prior to this - all I'm doing is launching my app and 
 choosing Print….
 
 I tried removing my override of runModalPrintOperation…, which had no effect. 
 That leaves the only override -printShowingPrintPanel, but of course that has 
 to be overridden or else Print does nothing. That method creates a view and 
 associates it with my data model so it can render its contents. Previously 
 that has never given me any trouble, though I'll investigate further.
 
 That method is:
 
 - (void)  printShowingPrintPanel:(BOOL) flag
 {
   DKDrawingView*  pdv = [[self makePrintDrawingView] retain];
   DKViewController*   vc = [pdv makeViewController];
   
   [[self drawing] addController:vc];
   
   NSPrintInfo* printInfo = [self printInfo];
   
   [pdv setPrintInfo:printInfo];
   [pdv setPrintCropMarkKind:[[self mainView] printCropMarkKind]];
   
   NSPrintOperation* printOp = [NSPrintOperation 
 printOperationWithView:pdv printInfo:printInfo];
   
   [printOp setShowsPrintPanel:flag];
   [self runModalPrintOperation:printOp delegate:self 
 didRunSelector:@selector(documentDidRunModalPrintOperation:success:contextInfo:)
  contextInfo:NULL];
   
   [pdv release]; //removes the controller from the drawing when view 
 dealloced
 }
 
 While this calls out to other methods, it's all pretty simple - makes a view, 
 associates it with the existing data model owned by the document, and creates 
 a print operation with that view, which is then passed along to the modal 
 print op. All very standard I believe. I will attempt to cut this down to a 
 simpler case just to try and eliminate it. But at no point does it invoke 
 performActivityWithSynchronousWaiting:usingBlock:
 
 Seems to me if Kevin Perry's comment is taken at face value, the first 
 invocation at line #8 is not completing, and so the second invocation is 
 blocking. If some prior code had not completed, line 8 would block, not line 
 0. But NO code of mine is run prior to line #8, so I've hit another wall.
 
 
 --Graham
 
 
 
 
 
 
 
 
 On 23/08/2011, at 12:05 PM, Graham Cox wrote:
 
 On 23/08/2011, at 11:43 AM, Jerry Krinock wrote:
 
 Here is a list of NSDocument methods whose default implementations invoke 
 this method because they might present sheets, either to ask the user what 
 to do as they begin their work or because they may fail and present errors 
 to user:
 -revertDocumentToSaved:
 -saveDocumentWithDelegate:didSaveSelector:contextInfo:
 

Re: [SOLVED] Re: printDocument: hangs on Lion?

[Kevin Perry]

Whoops, found this too late. See my other reply about the actual cause of the 
deadlock though.

Deprecation warnings are unfortunately only generated when calling a method, 
not when they are overridden.

-KP

On Aug 22, 2011, at 8:24 PM, Graham Cox wrote:

 
 On 23/08/2011, at 1:00 PM, Graham Cox wrote:
 
 - (void)  printShowingPrintPanel:(BOOL) flag
 
 
 Ok, I found the problem.
 
 This method has been deprecated since 10.4. I've replaced it with 
 -printOperationWithSettings:error: and all is well. Though deprecated, there 
 seems to still be a compatibility code path that supports this within 
 NSDocument, but that compatibility code path is not in itself compatible with 
 the new document saving malarkey. So, it's Apple's bug, but perhaps not one 
 they would care about at this stage.
 
 What's a bit strange is that no deprecation warning came up for this method 
 even though I'm targeting 10.6 using the 10.7 SDK.
 
 
 --Graham

___

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

Re: printDocument: hangs on Lion?

[Kevin Perry]

Graham,

This can happen if there is a previous call to 
-performActivityWithSynchronousWaiting:usingBlock: and the block never calls 
the completion handler. If you use that method anywhere, please make sure the 
completion handler always gets called. If you don't use the method directly, 
other methods in NSDocument may call it and failure to invoke their completion 
handlers properly may also result in these kinds of hangs.

After checking these things, if you believe your code is not at fault, please 
file a bug ASAP.

-KP

On Aug 22, 2011, at 6:26 AM, Graham Cox wrote:

 Further info, if I take out +autosavesInPlace (was overridden to return YES), 
 it works fine.
 
 This suggests there's more to supporting this new-fangled document model to 
 allow printing to work. Any documentation spells this out?
 
 Working in Xcode 4, the documentation viewer is so incredibly poor compared 
 to Xcode 3 I can't find anything, or rather I can't wait the ten minutes per 
 page it takes to download anything (aside: is there a way to d/l all the 
 documentation and view it locally? We don't all have gigabit fibre to the 
 node).
 
 --G.
 
 
 On 22/08/2011, at 10:59 PM, Graham Cox wrote:
 
 When my NSDocument subclass has its printDocument: method called, Lion hangs 
 indefinitely. Snow Leopard works fine.
 
 The top of my stack looks like this:
 
 #0   0x7fff905676b6 in semaphore_wait_trap ()
 #1   0x7fff85ddb08e in _dispatch_semaphore_wait_slow ()
 #2   0x7fff881b2616 in -[NSDocument 
 performActivityWithSynchronousWaiting:usingBlock:] ()
 #3   0x7fff881a2518 in -[NSDocument 
 runModalPrintOperation:delegate:didRunSelector:contextInfo:] ()
 #4   0x00010009e544 in -[GCOrteliusDocument 
 runModalPrintOperation:delegate:didRunSelector:contextInfo:] at 
 /Users/grahamcox/Projects/Artboard/Artboard/Source/Code/GCOrteliusDocument.m:1476
 #5   0x0001002f5b9f in -[DKDrawingDocument printShowingPrintPanel:] at 
 /Users/grahamcox/Projects/DrawKit/DrawKit/../Source/Code/DKDrawingDocument.m:923
 #6   0x7fff881a1a52 in __-[NSDocument 
 printDocumentWithSettings:showPrintPanel:delegate:didPrintSelector:contextInfo:]_block_invoke_2
  ()
 #7   0x7fff881a95e0 in -[NSDocument _commitEditingThenContinue:] ()
 #8   0x7fff881a52ab in -[NSDocument 
 _commitEditingWithDelegate:didSomethingSelector:contextInfo:thenContinue:] ()
 #9   0x7fff881a18bf in __-[NSDocument 
 printDocumentWithSettings:showPrintPanel:delegate:didPrintSelector:contextInfo:]_block_invoke_1
  ()
 #10  0x7fff881b2670 in -[NSDocument 
 performActivityWithSynchronousWaiting:usingBlock:] ()
 #11  0x7fff881a17d1 in -[NSDocument 
 printDocumentWithSettings:showPrintPanel:delegate:didPrintSelector:contextInfo:]
  ()
 #12  0x7fff881a1763 in -[NSDocument printDocument:] ()
 
 
 So it's waiting on some lock, but it never gets it. This is on the main 
 thread, therefore my app just grinds to a halt and has to be force quit.
 
 I'm at a loss as to what to do - it doesn't seem to be my bug.
 
 --Graham
 
 
 
 
 ___
 
 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/graham.cox%40bigpond.com
 
 This email sent to graham@bigpond.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/kperry%40apple.com
 
 This email sent to kpe...@apple.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

Re: Telling Auto Save, No, I'm busy now

[Kevin Perry]

Ah, I did not foresee this.

I really can't generally recommend calling -saveToURL:::error: instead of 
saveToURL:::completionHandler: because the latter does some important things 
that the former doesn't. Unfortunately, I think the problem you're seeing with 
the hang is insurmountable without additional API. Here's what normally happens:

1) -autosaveWithImplicitCancellability:completionHandler: uses 
-performAsynchronousFileAccessUsingBlock:
2) Within that block, it calls -saveToURL:::completionHandler:
3) -saveToURL:::completionHandler: of necessity also uses 
-performAsynchronousFileAccessUsingBlock:. When invoked in the above block, 
NSDocument recognizes this as a continuation of the initial 
-performAsynchronousFileAccessUsingBlock: call and simply invokes the block 
right away.

However, in your case, you are delaying step (3) until outside the initial 
block, so NSDocument cannot automatically recognize this as a continuation of 
the same file access. In order to resolve this, you would need API on 
NSDocument to tell it that you're continuing the same file access from before 
when you reinvoke -saveToURL:::completionHandler:.


Actually, you may be able to work around this problem by overriding 
-autosaveWithImplicitCancellability:completionHandler: instead (also?) and 
doing the same approach of delaying NSDocument's code until once you've 
completed the background work.

-KP

On Aug 6, 2011, at 7:23 AM, Jerry Krinock wrote:
 ** One little surprise.  After dequeueing the save operation, I kind of 
 thought that I could invoke the new synchronous saving method 
 saveToURL:::completionHandler:.  However, this does not save and apparently 
 does not run the completion handler properly because I still get the 
 hanging/blocking in -[NSDocument performAsynchronousFileAccessUsingBlock:].  
 But if I invoke the old async -saveToURL:::error: method and invoke the 
 completion handler block manually, it works fine.  Here…
 
 /*!
 @briefReal saving method, invoked when a save operation is
 dequeued to do the actual work.
 */
 - (void)reallySaveToURL:(NSURL *)url
 ofType:(NSString *)typeName
   forSaveOperation:(NSSaveOperationType)saveOperation
  completionHandler:(void (^)(NSError *errorOrNil))completionHandler {
[self prepareForSaveOperation:saveOperation] ;
 
 #if 0
 #warning Using fancy new async saveToURL.  Doesn't work.
[super saveToURL:url
  ofType:typeName
forSaveOperation:saveOperation
   completionHandler:completionHandler] ;
// Still hangs even if the following is commented out.
Block_release(completionHandler) ;
 #else
 #warning Invoking completionHandler manually.  This works.
NSError* error = nil ;
BOOL ok = [super saveToURL:url
ofType:typeName
  forSaveOperation:saveOperation
 error:error] ;
completionHandler(error) ;
Block_release(completionHandler) ;
if (error  ok) {
NSLog(@Internal Error 923-0284 %@, error) ;
}
 #endif
 }
 
 
 /*!
 @briefOverride of new asynchronous saving method invoked by Cocoa
 when running in Mac OS X 10.7 or later.
 
 @details  
 
 * Case  saveOperation  maenQueue  Cancellable?  Action
 *   -  -    
 *   1  not AIP X   XAdd to queue
 *   2AIP   not busyXAdd to (empty) queue
 *   3AIP busyYesCancel the Save
 *   4AIP busy NoAdd to (busy) queue
 
 AIP = Auto Save In Place
 X = don't care
 */
 - (void)saveToURL:(NSURL *)url
   ofType:(NSString *)typeName
 forSaveOperation:(NSSaveOperationType)saveOperation
 completionHandler:(void (^)(NSError *errorOrNil))completionHandler {
if (saveOperation == NSAutosaveInPlaceOperation) {
// Case 2, 3 or 4
if ([[[SSYOperationQueue maenQueue] operations] count] != 0) {
// Case 3 or 4  (busy)
  if ([self autosavingIsImplicitlyCancellable]) {
// Case 3.  Cancel the Save
completionHandler([NSError errorWithDomain:NSCocoaErrorDomain
  code:NSUserCancelledError
  userInfo:nil]) ;
/*DB?Line*/ NSLog(@133955: Cancelling Save) ;
return ;
}
else {
// Case 4.  Add to (busy) queue
}
}
else {
// Case 2.  Add to (empty) queue
}
}
else {
// Case 1.  Add to queue
}
 
// Note that we arrive here either in Case 1, 2 or 4.
// In Case 2, and maybe Case 1, instead of adding the save
// operation to our queue, we could invoke -reallySaveToURL
// synchronously.  However we don't do that because the usual
// notification sent when work is done, which we need for
// 

Re: Telling Auto Save, No, I'm busy now

[Kevin Perry]

What Ken said.

Also, it might be more convenient to use NSBlockOperation or 
-addOperationWithBlock so the function parameters (including the completion 
handler) are all captured correctly for you automatically. It's a lot more 
convenient than stashing things in an NSDictionary.

Finally, I misspoke about the application blocking when you defer calling the 
completion handler. User interaction blocking for async saving doesn't get 
invoked until much later. As a result, yes the user can continue editing the 
document, which I suppose is OK since the pending autosave will pick up those 
changes as well. However, since -autosaveWithImplicitCancellability:… uses 
-performAsynchronousFileAccessUsingBlock:, any further attempts to gain access 
to the file will block the main thread, so you'll need to use 
-continueAsynchronousWorkOnMainQueueUsingBlock: to avoid a potential deadlock 
when reinvoking the -saveToURL: method on the main queue.

Also, what I said about other applications blocking trying to get sole access 
to the file via file coordination is still true.

-KP

On Aug 4, 2011, at 7:53 AM, Ken Thomases wrote:

 On Aug 4, 2011, at 8:54 AM, Jerry Krinock wrote:
 
 I'm getting a crash if I begin some operations and then hit the 'close' 
 button on the window while the operations are in progress…
 
 I take the four parameters I receive in 
 saveToURL:ofType:forSaveOperation:completionHandler: and put them into a 
 dictionary in an NSOperation, and throw this operation onto the end my 
 operation queue.  (This project was written back in 10.5 so it does not use 
 GCD.)  
 
 Did you copy the block, or did you just add it to the dictionary as a value 
 (which just retains it)?  You need to copy it and then later release it.
 
 
 When this final operation runs, I send this dictionary to a selector on the 
 main thread.  But the completion handler seems to contain a bomb at this 
 point – it usually crashes upon receiving any message, not always in the 
 same place.  Often, it crashes when I send it to super's 
 saveToURL:ofType:forSaveOperation:completionHandler:, which apparently tries 
 to copy it, like this…
 
 #0   0x97c68987 in _Block_copy_internal
 #1   0x97c68bd8 in _Block_object_assign
 #2   0x97123a41 in __copy_helper_block_138
 #3   0x97c67f86 in _Block_call_copy_helper
 #4   0x97c689d3 in _Block_copy_internal
 #5   0x97c68bd8 in _Block_object_assign
 #6   0x9713f43b in __copy_helper_block_40
 #7   0x97c67f86 in _Block_call_copy_helper
 #8   0x97c689d3 in _Block_copy_internal
 #9   0x9bb22eae in _dispatch_Block_copy
 #10  0x9bb251ea in dispatch_async
 #11  0x9713ac9c in -[NSDocument performAsynchronousFileAccessUsingBlock:]
 #12  0x97123688 in -[NSDocument 
 saveToURL:ofType:forSaveOperation:completionHandler:]
 
 This suggests that you didn't copy it.  Thus, the above is the first time it 
 has been copied, which attempts to relocated it off of its original stack 
 frame and into the heap.  However, that stack frame is long gone and no 
 longer valid.
 
 
 Retaining the completionHandler a half dozen times, with no corresponding 
 releases, before placing into the dictionary, does not help.  So apparently 
 it's not memory management.
 
 Blocks have special memory management requirements and retaining is not 
 sufficient if the block is to survive its original stack frame.
 
 Regards,
 Ken
 
 ___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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

Re: Telling Auto Save, No, I'm busy now

[Kevin Perry]

AppKit-initiated autosaves generally happen for two main reasons: the autosave 
timer, and file coordination. These are both initiated with 
-autosaveWithImplicitCancellability:completionHandler:. The implicitly 
cancelable flag indicates whether it's appropriate for an NSDocument subclass 
to cancel an autosave (with an NSUserCancelled NSError, as you've discovered). 
Timer-initiated autosaves are cancelable (up to a certain limit), and you can 
detect this by calling -autosavingIsImplicitlyCancellable. Canceling an 
autosave when -autosavingIsImplicitlyCancellable returns NO will cause problems 
with file coordination.

If you absolutely cannot save when a non-cancellable autosave starts, it is OK 
to defer the autosave until you're ready, as long as you make sure to call the 
original completionHandler when you're done. There are consequences to this 
though. Not only will your application be blocked until the completionHandler 
is called, but you will cause other applications using File Coordination on 
your document's file to wait longer as well.

-KP

On Jul 30, 2011, at 6:41 PM, Jerry Krinock wrote:

 
 On 2011 Jul 30, at 15:39, wadesli...@mac.com wrote:
 
 You're lying to the save machinery by saying that you have saved, when you 
 have not.  So NSFileCoordinator will then think your file is up to date, and 
 let others read (or write) it.  It could lead to all sorts of nasty 
 behaviors…
 
 Thank you, Wade.  Yes, that's a good point.
 
 What you should be doing is deferring the save - just hang on to 
 'completionHandler', queue up the save for the next available opportunity, 
 and invoke the handler after the save really happens.
 
 OK, but I thought of an easier solution.  Replace this line of code 
 
completionHandler(nil) ;
 
 which told the system that I had saved with no error, with this:
 
completionHandler([NSError errorWithDomain:NSCocoaErrorDomain
  code:NSUserCancelledError
  userInfo:nil]) ;
 
 Now I'm not lying to Mother any more.  And because this particular error 
 domain/code is documented to not be displayed (see -Document-Based 
 Applications Overview ▸ Error Handling in the Document Architecture), the 
 user doesn't get any crap.
 
 Indeed, the behavior is a little different now.  Instead of waiting 10-15 
 seconds after my operations are completed, now the Auto Save happens 
 immediately after my operations are completed.  This implies that the system 
 now knows that it has unsaved data, and so it kicks in more aggressively.
 
 I like it better now.  But it still seems that Apple should document the 
 correct way to handle this situation.
 
 you're in the middle of applying a user action, one that has been expressly 
 approved and is merely taking some time
 
 Yes, that is the situation.
 
 ___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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

Re: Space-efficient saving for Versions?

[Kevin Perry]

The Versions store will do this automatically. It can detect when blocks of a 
file have been duplicated and avoid storing those blocks on disk.

On Jul 28, 2011, at 12:37 AM, Daniel Vollmer wrote:

 Salutations,
 
 in my custom document package I'm always including a large-ish chunk of data 
 that does not get modified as I change the document itself. Currently, I'm 
 keeping this around as NSData-object and write it out when being asked by 
 NSDocument to return my fileWrapper as one sub-file of the directory package.
 Can I do anything to make it more obvious to the Versions / 
 autosave-mechanism that this file in the package is always the same? Or will 
 it compare the files anyway and notice it's identical to the one used in the 
 previous revision?
 
 Thanks,
   Daniel.___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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

Re: How to implement Autosaving, Browsing Versions, Reverting to Last Saved in Lion?

[Kevin Perry]

There is nothing that you are obviously doing wrong here. Please file a Radar 
with your test app attached.

-KP

On Jul 24, 2011, at 7:46 PM, Zorg wrote:

 I'm having a difficult time figuring out how to implement these features 
 correctly in Lion. I've created a very simple NSDocument based test app: 
 http://pastebin.com/w396Xxi4
 
 A document in this test app has a window and a text field, the user enters 
 text in the text field, that text is the state of the document. The app 
 saves and loads that text.
 
 I'm saving the data using dataOfType: error: and loading the data using 
 readFromData: ofType: error:. The user interface (the text field in 
 particular) is being updated after being loaded in 
 windowControllerDidLoadNib: unless the data is being reverted, in which 
 instead the user interface is being updated in readFromData: ofType: error: 
 (to test if a document is being reverted, I check if an outlet such as the 
 textField != nil)
 
 Now, the saving of the document works fine. Browsing and choosing a different 
 saved version of the document also works fine. What doesn't work correctly is 
 reverting to another version. For example, if I create a new document, save 
 the document, make a change (entering something new in the text field and 
 hitting enter), choose revert to last saved version from the window titlebar, 
 and save again, I occasionally get an error message This document's file has 
 been changed by another application since you opened or saved it. or I get 
 The location of the document - cannot be determined. (I say 
 occasionally because I cannot get it to error the first attempt I do this 
 while a document is still open, but usually always get an error on my second, 
 and further attempts). I can also reproduce this error when trying to save 
 after choosing a different version in the versions browser, however, I think 
 I can only reproduce the error in this case when my document is in an edited 
 state before trying to choose another version (If I save before trying to 
 choose a different version and then save after, I don't get get an error).
 
 Here's a couple images of the errors:
 http://dl.dropbox.com/u/10108199/error1.png
 http://dl.dropbox.com/u/10108199/error2.png
 
 Also, is there a better approach to loading a reverted document than what I'm 
 doing (instead of testing if an outlet of a document is nil)? Any help would 
 be appreciated.
 
 Thanks,
 -Zorg:-.___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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

Re: NSDocument: Read-only types and autosavesInPlace

[Kevin Perry]

On Jul 22, 2011, at 9:16 AM, Daniel Vollmer wrote:

 Hello,
 
 I'm trying to add autosavesInPlace support to my NSDocument-based 
 Application. It supports a read-only type that is internally converted (as 
 suggested in 
 https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Documents/Tasks/FAQ.html#//apple_ref/doc/uid/2954-1081265-BAJFDEGD)
  to my writable type.
 
 The viewer- and editor-roles are set correctly in the application's plist, 
 +writableTypes also returns only what I can write. For reference, I can read 
 .txt and read/write .wowplot.
 
 Now, this seems to interact badly with autosavesInPlace: YES. The following 
 happens:
 1) I open a document of the read-only type (.txt)
 2) I convert this as suggested above to my writable type, using setFileType 
 and setFileURL
 3) I modify the document
 4) I attempt to close the document
 5) Now the autosave-Machinery jumps into action and I get the following error:
 [ERROR] genstore_storage.c:GSAddPathAsGeneration:980  copyfile 
 /Volumes/Seerose/Users/maven/Desktop/110720 225338.wowplot to 
 /Volumes/Seerose/Users/maven/Library/Autosave 
 Information/2521980F-37BC-4E21-AF6A-001BE638AEFC.genstore.noindex/.genstore_staging/OUyU4Xi/staged
  failed with error 2 (No such file or directory)
 
 The errors make sense, as the file under that name never existed.
 
 Now I'm stuck in-between a rock in a hard place:
 If I change the type, autosavesInPlace tries to duplicate a non-existent file 
 (because I modified the fileURL); if I don't change the type, NSDocument will 
 ask me to write a file of a type I cannot support.
 
 Any ideas?


There's a tidbit in the AppKit release notes regarding this (Look for File 
Type Fixing in -[NSDocument 
saveToURL:ofType:forSaveOperation:completionHandler:]).

While it doesn't say it right out, it suggests that you should give 
responsibility for changing to file URL to NSDocument. All you need to do is 
change the file type and NSDocument will take care of the file URL and avoid 
this error. (Note: you won't get this behavior if you're overriding the old 
-saveToURL:ofType:forSaveOperation:error: method.)

The documentation you linked to has not been updated to reflect this. Please 
file a radar against the documentation to get this updated.

-KP___

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

Re: problem with dataWithContentsOfFile on Lion

[Kevin Perry]

Please check the NSData.h header and Foundation release notes for Lion.

Because mapping files on non-local drives (which may be disconnected or removed 
at any moment, resulting in a crash if you attempt to access parts of the file 
that haven't been faulted in) is unsafe, NSData on Lion has changed the meaning 
of NSDataReadingMapped to be a hint (see NSDataReadingMappedIfSafe). It will 
only map the file if it detects that doing so is safe.

If you are willing to accept the risk of mapping unsafe files, simply pass 
NSDataReadingMappedAlways instead of NSDataReadingMapped.

-KP

On Jul 21, 2011, at 11:01 AM, Wilker wrote:

 Hi guys,
 
 I updated to Lion yesterday, but I'm having an issue now with [NSData
 dataWithContentsOfFile]
 
 This code is to generate a hash based on 64kb of start and 64kb of end from
 a file:
 
   + (NSString *)generateHashFromPath:(NSString *)path
 
 {
 
const NSUInteger CHUNK_SIZE = 65536;
 
 
 
NSError *error = nil;
 
NSData *fileData = [NSData dataWithContentsOfFile:path options:
 NSDataReadingMapped | NSDataReadingUncached error:error];
 
 
 
if (error) {
 
return nil;
 
}
 
 
 
const uint8_t* buffer = [fileData bytes];
 
 
 
NSUInteger byteLength = [fileData length];
 
NSUInteger byteOffset = 0;
 
 
 
if (byteLength  CHUNK_SIZE) {
 
byteOffset = byteLength - CHUNK_SIZE;
 
byteLength = CHUNK_SIZE;
 
}
 
 
 
CC_MD5_CTX md5;
 
CC_MD5_Init(md5);
 
 
 
CC_MD5_Update(md5, buffer, (CC_LONG) byteLength);
 
CC_MD5_Update(md5, buffer + byteOffset, (CC_LONG) byteLength);
 
 
 
unsigned char digest[CC_MD5_DIGEST_LENGTH];
 
 
 
CC_MD5_Final(digest, md5);
 
 
 
NSMutableString *hexDigest = [NSMutableString stringWithCapacity:
 CC_MD5_DIGEST_LENGTH * 2];
 
 
 
for (int i = 0; i  CC_MD5_DIGEST_LENGTH; i++) {
 
[hexDigest appendFormat:@%02x, digest[i]];
 
}
 
 
 
return [hexDigest lowercaseString];
 
 }
 
 Before Lion, it really works well and fast, even on Wifi external drive
 (through Airport Extreme), but now it get's really slow... I did some
 checks, and now its reading the entire file... instead of just read 128kb
 (start and end). Anyone have an ideia on why its happening now? And how to
 make it works as before on Snow Leopard?
 ---
 Wilker Lúcio
 http://about.me/wilkerlucio/bio
 Kajabi Consultant
 +55 81 82556600
 ___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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

Re: Why do I have to initialize NSError ?

[Kevin Perry]

This is a bug in the framework. NSError-returning methods should not need to 
check the value of the dereferenced pointer before setting it.

Please file a bug for this.

-KP

On Mar 8, 2011, at 7:22 AM, Gerriet M. Denkmann wrote:

 I thought that NSError is just an output parameter, which is set only in case 
 of errors.
 
 But in my completion handler block (see below) NSError MUST be initialized to 
 nil, or it will NOT be set.
 
 The same code works as expected when NOT inside a block.
 
 
 #define   REMOVE_BUG  //  if this is NOT defined, we get:
 
 [...] __-[Alias_TestAppDelegate openAliasFile:]_block_invoke_1 outError1 
 0x10057f3b0 (NOT initialized)
 [...] __-[Alias_TestAppDelegate openAliasFile:]_block_invoke_1 outError2 
 0x10057f3b0 (after error return)
 [...] -[NSOpenPanel recoveryAttempter]: unrecognized selector sent to 
 instance 0x10057f3b0
 
 
 Here is the code:
 
 - (IBAction)openAliasFile: sender;
 {
   (void)sender;
   
   NSOpenPanel *openPanel = [ NSOpenPanel openPanel ];
   [ openPanel setAllowsMultipleSelection: NO ];
   [ openPanel setCanChooseDirectories: NO ];
   [ openPanel setResolvesAliases: NO ];
   [ openPanel setMessage: @Select Alias File ];  
 
   [ openPanel beginSheetModalForWindow:   self.window
   completionHandler:  
 ^(NSInteger result)
   {
   if (result == NSOKButton) 
   {
   NSURL *bookmarkFileURL = [ 
 openPanel URL ];
   
   [ [ self window ] 
 setTitleWithRepresentedFilename: [ bookmarkFileURL path ] ];
   
   [ openPanel orderOut:self]; // close panel 
 before we might present an error
 
   //  if bookmarkFileURL is 
 NOT an alias file, bookmarkData will be nil, but outError
   //  is NOT set. Works 
 correctly if we initialise  outError to nil.
   
   #ifdef REMOVE_BUG
   NSError *outError = nil;
   #else
   NSError *outError;
   NSLog(@%s outError1 %p (NOT 
 initialized),__FUNCTION__, outError);
   #endif
   
   NSData *bookmarkData =  [ NSURL 
 bookmarkDataWithContentsOfURL:  bookmarkFileURL 
   
 error:
   outError 
   
 ];
   if ( bookmarkData == nil )  
 //  error
   {
   NSLog(@%s outError2 %p 
 (after error return),__FUNCTION__, outError);
 
   [ self  presentError:   
 outError 
   
 modalForWindow: [ self window ] 
   
 delegate:   nil 
   
 didPresentSelector: NULL  
   
 contextInfo:NULL 
   ];
   
   return;
   };  
 
 
   //  do something with valid 
 bookmarkData
   
   }
   else//  cancelled
   {
   self.dataString = @-- 
 Cancelled --;
   };
   }
   ];
 }
 
 
 Kind regards,
 
 Gerriet.
 
 P.S. Tested on 10.6.6
 
 ___
 
 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
 
 

Re: NSView setAlphaValue question (Update still not working)

[Kevin Perry]

The reason why this isn't working in Leopard is simple: -setAlphaValue: for 
non-layer-backed views was not implemented until Snow Leopard.

The documentation for -setAlphaValue: states:

 Sending this message to a view that is not managing a Core Animation layer 
 causes an exception.


I don't know if it ever actually caused an exception, but this at least 
explains that it was originally only implemented for layer-backed views. 
Obviously the documentation needs to be updated to reflect the change in Snow 
Leopard.

KP

On Dec 17, 2010, at 3:19 AM, Rick C. wrote:

 I appreciate the help Seth.  I'm sure there must be something I'm doing 
 wrong.  Here is a sample project that shows what I'm talking about.  The fade 
 buttons in the project work as expected in Snow but in Leopard no fade 
 effect.  Ok thanks again!
 
 http://dl.dropbox.com/u/11903800/TestFadeApp.zip
 
 rc
 
 
 
 On Dec 17, 2010, at 3:32 PM, Seth Willits wrote:
 
 On Dec 16, 2010, at 8:45 PM, Rick C. wrote:
 
 Ok I thought that was easy enough but something is still not right.  When I 
 code my view to be redrawn at varying alpha and then have my controller 
 send the message when it's time to be redrawn it does not work in Leopard 
 (Snow Leopard again no problem).  Now the view is reporting the alpha being 
 changed and the fact that it works in Snow should mean I coded it 
 correctly, but again no changes evident in Leopard.  If I use setWantsLayer 
 then it works but I'm back to the broken issues again (still funny why no 
 problem on PPC Leopard just Intel).  But as for the fading doesn't work on 
 PPC or Intel doing it this way.  I must be missing something?  What does 
 work is setHidden and I could give up and just have the fade effect on 
 Snow, but it sure would be nice to keep it the same on both.  Any thoughts 
 of what maybe I'm doing wrong?  Thanks again,
 
 
 I really can't tell from what you've said what would be wrong. There's 
 certainly no reason it shouldn't work on Leopard. Make a movie and/or sample 
 project/code.
 
 
 
 --
 Seth Willits
 
 
 
 ___
 
 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/rickcorteza%40gmail.com
 
 This email sent to rickcort...@gmail.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/kperry%40apple.com
 
 This email sent to kpe...@apple.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

Re: NSPathControl w/ popups and icons

[Kevin Perry]

NSPathControl doesn't map submenus in its menu to the individual 
NSPathComponentCells, so that's not going to work.

This will probably require some heavy subclassing of at least 
NSPathComponentCell, and perhaps NSPathCell (if the layout isn't quite how you 
need it). You'll need to provide some way to set a menu on your component cell, 
and you'll also need to override cell mouse tracking so you can show the menu 
when the user clicks on the cell. That might be enough, but depending on your 
expectations, you may need to do more than that.

On Jul 31, 2010, at 5:44 PM, Shane wrote:

 I'm trying to create an NSPathControl where there are several items
 (components) within the row and each item (component) is a popup menu.
 And then I would populate each of those popups w/ items. But I'm
 having a problem in understanding if that's how it really works.
 
 I'm playing around w/ the following code. Can anyone offer guidance on
 using NSPathControl?
 
 
   NSPathComponentCell *cell1 = [[NSPathComponentCell alloc] init];
   [cell1 setTitle:@cell 1];
   [networkComponents addObject:cell1];
   
   NSPathComponentCell *cell2 = [[NSPathComponentCell alloc] init];
   [cell2 setTitle:@cell 2];
   [networkComponents addObject:cell2];
   
   NSMenu *pathMenu = [[NSMenu alloc] initWithTitle:@Main];
   NSMenuItem *pathItems = [[NSMenuItem alloc] initWithTitle:@item #1
 action:nil keyEquivalent:@];
   NSMenuItem *pathItems2 = [[NSMenuItem alloc] initWithTitle:@item #2
 action:nil keyEquivalent:@];
   [pathItems setSubmenu:pathMenu];
   [pathItems2 setSubmenu:pathMenu];
   
   [networkPathControl setMenu:pathMenu];
 
   // setStringValue works, but its' only 1 single popup that's empty 
 unless
// I click on it, then I see the string values
   //[networkPathControl setStringValue:@cell 3 / cell 4];
 
   //[networkPathControl setPathComponentCells:networkComponents];
   //[networkPathControl setBackgroundColor:[NSColor blueColor]];
   //[networkPathControl setNeedsDisplay:YES];
 ___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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

Re: Finding Application support folder without Cocoa or Carbon

[Kevin Perry]

You can use the C API in /usr/include/NSSystemDirectories.h.

On Jul 12, 2010, at 1:17 PM, Alexander Cohen wrote:

 Hello,
 
 I need to find the system Application Support folder without using either 
 Carbon or Cocoa, i can use CoreFoundation though. Is there a way to do this?
 
 thx
 
 AC___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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

Re: Problems with NSPathControl

[Kevin Perry]

Dave,

I believe what you're seeing is the intended behavior.

There are cases where developers have not wanted the URL to change when an item 
in the pop-up menu is selected. Instead of doing this automatically and forcing 
developers to prevent or undo this behavior, NSPathControl instead expects you 
to set URL yourself in the action method if you want this behavior.

On Jul 12, 2010, at 1:26 PM, Dave DeLong wrote:

 Hi everyone,
 
 I have an NSPathControl set to the Pop Up style, with an initial path of 
 /Users/dave.  It's restricted to items of type public.folder.  When I run 
 this project and interact with the path control, I see a menu like this:
 
 Choose 
 
 dave
 Users
 (Volume name)
 (Computer name)
 
 The Choose... item brings up a standard open panel which restricts 
 selection to folders (as specified by the allowedTypes:).  This works 
 correctly, and the path control updates to reflect the newly chosen item.
 
 However, when I try to select something from the bottom portion of the menu, 
 like Users, the menuitem highlight does its little flickering thing to 
 indicate that the item was chosen, but the path doesn't change.  
 
 Am I correct in expecting that choosing an item from the menu should change 
 the path of the control?  If that's a correct assumption, then do you have 
 any suggestions about why it's not behaving properly?  By own attempts to 
 debug this (introspecting the menu, pathcontrol, etc) have been fruitless.
 
 Thanks,
 
 Dave DeLong___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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

Re: Problems with NSPathControl

[Kevin Perry]

Yeah, this is an unfortunate bug that we didn't catch until Snow Leopard.

Here's one way to work around it (there may be a better alternative that I'm 
not aware of). You can implement pathControl:willPopUpMenu: and keep a pointer 
to the menu it gives you. When the action is called, -[NSMenu highlightedItem] 
should give you the NSMenuItem that was selected. No need to modify the menu 
items' targets or actions.

On Jul 12, 2010, at 1:50 PM, Dave DeLong wrote:

 Or do I have to do something wonky like altering the target/action of 
 menuitems before they show up?
 
 Dave
 
 On Jul 12, 2010, at 2:45 PM, Dave DeLong wrote:
 
 Fair enough;  How can I retrieve which item was clicked?  The sender of the 
 action is the actual NSPathControl, and -clickedPathComponentCell:, which 
 works on 10.6, returns nil on 10.5.
 
 Dave
 
 On Jul 12, 2010, at 2:39 PM, Kevin Perry wrote:
 
 Dave,
 
 I believe what you're seeing is the intended behavior.
 
 There are cases where developers have not wanted the URL to change when an 
 item in the pop-up menu is selected. Instead of doing this automatically 
 and forcing developers to prevent or undo this behavior, NSPathControl 
 instead expects you to set URL yourself in the action method if you want 
 this behavior.
 ___
 
 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/davedelong%40me.com
 
 This email sent to davedel...@me.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/kperry%40apple.com
 
 This email sent to kpe...@apple.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

Re: NSFileManager 'attributesOfItemAtPath:error:' does not traverse a link?

[Kevin Perry]

That documentation is incorrect and is scheduled to be corrected. 
-attribtuesOfItemAtPath:error: will never automatically resolve symlinks, and 
that will never change.

-Kevin Perry

On May 28, 2010, at 8:17 AM, Charles Srstka wrote:

 On May 28, 2010, at 10:01 AM, Tito Ciuro wrote:
 
 The old statement traverses the link:
 
  NSDictionary* attr = [[NSFileManager defaultManager] 
 fileAttributesAtPath:file traverseLink:YES];
 
 The problem is that the header states that 'attributesOfItemAtPath:error:' 
 that it's a replacement for 'fileAttributesAtPath:traverseLink:', but 
 provides no provision for traversing the link.
 
 How would I obtain the attributes of an item that needs to be traversed 
 first?
 
 You can easily traverse a link just by using [file 
 stringByResolvingSymlinksInPath] or [file stringByStandardizingPath] instead 
 of file. Where this gets tricky is if you *don’t* want to resolve the 
 symlink. Currently, the method doesn’t traverse symbolic links, but the 
 documentation claims that this behavior could change in a future version of 
 OS X, so if you need to guarantee that it won’t resolve, the only options are 
 either to use deprecated methods, or to use Carbon or BSD APIs.
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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

Re: Operation could not be completed. No such file or directory

[Kevin Perry]

It's referring to the source path. The documentation specifically states that 
no file should exist at the destination path. So, one can deduce that 
NSFileManager wouldn't report a no such file error if there was no file 
there, since that is what is expected.

-Kevin

On Apr 13, 2010, at 11:31 AM, k...@highrolls.net wrote:

 Using NSFileManager I get the error messaged referenced in the Subject Line.
 
 But, which is it referring to ... the copyItemAtPath or the toPath
 
 bool rtx2 = [[NSFileManager defaultManager] copyItemAtPath:prefsrcpath 
 toPath:prefdstpath error:error];
 
 -koko
 ___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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

Re: Attempt to nest an NSCollectionView fails.

[Kevin Perry]

Actually, you can still give this a try.

The Leopard-style NSCollectionViewItem was restricted to replicating just the 
prototype view so the array controller the prototype view was bound to would 
not be replicated. Since SnowLeopard uses a nib for the prototype view, the 
entire nib will be replicated each time a new NSCollectionViewItem is 
instantiated, hence it can create one array controller per item view.

Using this approach, you can still support Leopard by overriding 
-newItemForRepresentedObject: and instantiating the same nib yourself, instead 
of using the view replication implementation provided by NSCollectionView.

-Kevin

On Mar 23, 2010, at 9:30 PM, Brian Krisler wrote:

 Since I am testing this in a sample app as a proof-of-concept, I have
 a single nib.  Plus I have a requirement to support Leopard, so applying
 Snow Leopard specific code is not an option.
 
 After some further investigation, I thing the issue is with my 
 NSArrayController
 object in my nib file.  What I would really want is an NSArrayController
 for each view within the CollectionView, however it appears to me that this
 is not what is actually happening.  I think that when I bind my 
 NSCollectionViewItem
 representedObject.blockItems to my NSArrayController, this does not create
 a unique array controller for each CollectionViewItem.
 
 I think my option is to create my layout by hand and give up on attempting to
 use an NSCollectionView.  I was thinking the collection view would save me
 some work.  Appears to not be the case.
 
 Thanks for the assistance.
 
 Brian
 
 - Original Message -
 From: Kevin Perry kpe...@apple.com
 To: Brian Krisler bkris...@cs.brandeis.edu
 Cc: cocoa-dev@lists.apple.com
 Sent: Tuesday, March 23, 2010 12:07:03 PM GMT -05:00 US/Canada Eastern
 Subject: Re: Attempt to nest an NSCollectionView fails.
 
 I'm not sure this is really a usage case that I'd expect to be well tested, 
 since it seems a little out of the ordinary.
 
 Anyway, which approach are you using for your prototype view? Is the view in 
 the same nib, or have you factored it out into a separate nib, using the fact 
 that NSCollectionViewItem became a subclass of NSViewController in Snow 
 Leopard? If you're using the former, then the bindings may very well not be 
 transferred correctly to each replicated view. Either switch to the Snow 
 Leopard approach (highly recommended -- see the AppKit release notes for more 
 details), or you can try overriding -newItemForRepresentedObject: and set up 
 the bindings yourself.
 
 -Kevin
 
 On Mar 22, 2010, at 8:31 PM, Brian Krisler wrote:
 
 Hi,
 
 I am trying to nest an NSCollectionView inside an existing collection view 
 and am not having much luck.  The example I am building runs without issue, 
 however the nested values do not appear.
 
 I currently have two model classes:
 
 @interface BlockModel : NSObject {
  NSString *blockTitle;
  NSMutableArray *blockItems;
 }
 @property (readwrite, retain) NSString *blockTitle;
 @property (readwrite, retain) NSMutableArray *blockItems;
 @end
 
 and 
 
 @interface BlockItem : NSObject {
  NSString *itemName;
  NSString *itemDescription;
 }
 @property (readwrite, retain) NSString *itemName;
 @property (readwrite, retain) NSString *itemDescription;
 @end
 
 In my delegate, I have an NSMutableArray of blockModels.
 
 Then in Interface Builder, I have an NSCollection view with a label and a 
 nested NSCollection view.  The label contains the BlockModel.blockTitle 
 (which displays correctly).
 
 To get content into the nested view, I have an Array Controller with the 
 Content Array bound to the Collection View Item from the parent and a model 
 Key Path of: representedObject.blockItems
 
 My nested collection view has its content bound to my Array Controller 
 arrangedObjects. And my array controller is configured to be an object 
 controller with the keys: itemName and itemDescription. I then have two 
 labels in my nested collection view bound to the nested collection view item 
 representedObject.itemName and representedObject.itemDescription.
 
 When I execute my code, I can see a few blocks with the proper titles, 
 however the nest view is completely empty.
 
 Is there a step that I am missing?
 
 Thanks for any help.
 
 Brian
 ___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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

Re: Attempt to nest an NSCollectionView fails.

[Kevin Perry]

I'm not sure this is really a usage case that I'd expect to be well tested, 
since it seems a little out of the ordinary.

Anyway, which approach are you using for your prototype view? Is the view in 
the same nib, or have you factored it out into a separate nib, using the fact 
that NSCollectionViewItem became a subclass of NSViewController in Snow 
Leopard? If you're using the former, then the bindings may very well not be 
transferred correctly to each replicated view. Either switch to the Snow 
Leopard approach (highly recommended -- see the AppKit release notes for more 
details), or you can try overriding -newItemForRepresentedObject: and set up 
the bindings yourself.

-Kevin

On Mar 22, 2010, at 8:31 PM, Brian Krisler wrote:

 Hi,
 
 I am trying to nest an NSCollectionView inside an existing collection view 
 and am not having much luck.  The example I am building runs without issue, 
 however the nested values do not appear.
 
 I currently have two model classes:
 
 @interface BlockModel : NSObject {
   NSString *blockTitle;
   NSMutableArray *blockItems;
 }
 @property (readwrite, retain) NSString *blockTitle;
 @property (readwrite, retain) NSMutableArray *blockItems;
 @end
 
 and 
 
 @interface BlockItem : NSObject {
   NSString *itemName;
   NSString *itemDescription;
 }
 @property (readwrite, retain) NSString *itemName;
 @property (readwrite, retain) NSString *itemDescription;
 @end
 
 In my delegate, I have an NSMutableArray of blockModels.
 
 Then in Interface Builder, I have an NSCollection view with a label and a 
 nested NSCollection view.  The label contains the BlockModel.blockTitle 
 (which displays correctly).
 
 To get content into the nested view, I have an Array Controller with the 
 Content Array bound to the Collection View Item from the parent and a model 
 Key Path of: representedObject.blockItems
 
 My nested collection view has its content bound to my Array Controller 
 arrangedObjects. And my array controller is configured to be an object 
 controller with the keys: itemName and itemDescription. I then have two 
 labels in my nested collection view bound to the nested collection view item 
 representedObject.itemName and representedObject.itemDescription.
 
 When I execute my code, I can see a few blocks with the proper titles, 
 however the nest view is completely empty.
 
 Is there a step that I am missing?
 
 Thanks for any help.
 
 Brian
 ___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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

Re: IsReadableFileAtPath

[Kevin Perry]

In general, this kind of check-then-do pattern opens the door for file system 
race conditions. The documentation for this method (and related methods) has a 
little more information about this in the Note section.

Could you just try to copy the symlink and then deal with any errors that 
result?

-Kevin

On Mar 1, 2010, at 11:20 AM, gMail.com wrote:

 Hi,
 I need to check whether a file or a symlink could be really copied.
 I have just seen that the Cocoa API isReadableFileAtPath traverses the
 symlink, so, in case the target file is not readable, my app doesn't copy
 the symlink, while the Finder can properly do. So my app does wrong.
 
 The question is:
 How can I understand whether a file or symlink can really be copied?
 I have seen that isReadableFileAtPath uses the C command access which
 indeed traverses the symlink. So I cannot use it. So, any idea?
 And I wouldn't use the Carbon APIs because I need to compile for 64 bit.
 Thank you.
 
 Leonardo
 
 
 ___
 
 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/kperry%40apple.com
 
 This email sent to kpe...@apple.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