On 5 Jan 2010, at 17:34, Martin Stanley wrote:

> Thanks for the very quick response! 
> 
> I don't quite understand step 2:  how do I decide what to return from 
> -openDocumentWithContentsOfURL:  if the callback hasn't been called yet and 
> therefore I don't know if the user cancelled the close of the first document?

I mean to say that either approach should work. But I haven't tried them, so 
keep your options open.
> 
> I think the basic problem for me is that  -canCloseDocument… does not block.

Well it can't block, because the sheet needs to be interacted with.
> 
> Martin
> 
> 
> On 2010-01-05, at 12:10 PM, Mike Abdullah wrote:
> 
>> Override -openDocumentWithContentsOfURL:
>> 
>> 1. If you've already got a document open, send -canCloseDocument… to the 
>> open document, supplying the callback info
>> 
>> 2. Either:
>>      A) Return nil and an NSUserCancelled error.
>>      B) Return the existing document.
>> 
>> 3. When you get the callback from -canCloseDocument… call super's 
>> implementation of -openDocumentWithContentsOfURL:
>> 
>> On 5 Jan 2010, at 16:45, Martin Stanley wrote:
>> 
>>> I have a Core-Date application that uses the Cocoa Document architecture 
>>> (NSPersistentDocument) and would like to ensure that the user only can have 
>>> 1 document open at a time. Think of this application as similar to Mail.app 
>>> or Addressbook.app, etc. except that I would like the user to be able to 
>>> open different persistent stores at will, just not simultaneously.
>>> 
>>> (As an aside, the reason for this is because my document has many related 
>>> windows and I think it would be confusing for the user. It would not be 
>>> obvious which auxiliary window relates  to which document. I may fix this 
>>> in the future by using the concept of Inspectors, but at this point I'm not 
>>> sure if this is the correct model.)
>>> 
>>> I searched extensively and came up with the recommendation that I subclass 
>>> NSDocumentController and override:
>>>     - (id)openDocumentWithContentsOfURL:display:error:
>>> This was recommended over simply trapping the open menu item(s).
>>> 
>>> 
>>> This seemed very promising until I ran into a stumbling block. In 
>>> openDocumentWithContentsOfURL:display:error: I check to see if there is an 
>>> already open document and if so call:  
>>>     canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo:
>>> with an appropriate delegate and selector. The problem is that this returns 
>>> immediately, even in the case when the document is dirty and it presents a 
>>> modal dialog to the user. Because of this, the 2nd document is opened 
>>> before I have a chance to deal with the first one.
>>> 
>>> All of this is making me wonder if I'm taking the wrong approach. 
>>> 
>>> Should I figure out a way to prevent the 2nd document from opening before 
>>> the first one is either saved or abandoned: (override 
>>> canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo: in my 
>>> NSPersistentDocument subclass)? This feels like the solution is getting 
>>> uglier by the minute.
>>> 
>>> Or is there a much easier way to accomplish what I want to do? Or should I 
>>> be looking at a entirely different approach for my application?
>>> 
>>> 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:
>>> http://lists.apple.com/mailman/options/cocoa-dev/cocoadev%40mikeabdullah.net
>>> 
>>> This email sent to cocoa...@mikeabdullah.net
>> 
> 

_______________________________________________

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

Reply via email to