Re: Panels shared by documents
Re: Panels shared by documents
- Subject: Re: Panels shared by documents
- From: email@hidden
- Date: Sun, 23 Jun 2002 08:09:47 -0500
Don't forget to explore using NSDocumentController to see if that would
help.. every document application has
a default NSDocumentController who (in effect) knows and handles all the
documents an app has..
NSDocumentController *dc = [ NSDocumentController
sharedDocumentController ] ;
There are LOTS of interesting / useful methods available to your
application at this point via the "dc"
object with regard to documents..
-SJM
On Friday, June 21, 2002, at 06:07 PM, Brent Gulanowski wrote:
On Friday, June 21, 2002, at 05:18 PM, Itrat Khan wrote:
I've seen this approach mentioned in a few places. The problem with it
is that you still need a way of refreshing the panel's outlets when
the model changes. You might tell the panel to update from your action
methods, but that prevents updates from AppleScript, undo, etc.; you
might listen to notifications from your model, but that becomes
tedious to manage over a large project.
Thank you for your helpful ideas. Currently I'm trying mine to see how
it works --
My idea is that the document is the datasource and delegate. I'm using
docs with multiple window controllers. When the user changes to another
window, first we check if the newly main window belongs to the same
document or a new one. When the document does change, send a
notification with the document attached (not the window, it's
superfluous in this situation).
The palette window (actually, the data view(s) inside it) receives the
notification and changes its data source and delegate outlets to the
document in the note, informs the document, and then updates itself.
Now any changes to the document will be accompanied by a message to the
palette's data views. When a different document is chosen, the palette
window sets the previous document's relevant outlets to nil.
Would this pattern also fail in ways you suggest? I don't know if one
is more or less efficient that the other. Does NSApp already know which
document is "current"? Or would I have to flag that or add another
outlet to follow your suggestion? I kind of didn't want NSApp to get
involved unless it was already built to handle that, and my reading
suggested that it kept a list of documents but didn't much care which
one was current, leaving the responder chain and active windows to do
the work by themselves.
Brent
--
Brought to you by Mail on Mac OS X. Think Different.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.