• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: beyond MV and (one) C
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: beyond MV and (one) C


  • Subject: Re: beyond MV and (one) C
  • From: Daniel Child <email@hidden>
  • Date: Sun, 20 Jan 2008 23:57:14 -0500

Ken,

Your explanation below was super helpful. I tried passing a reference to the app controller directly as you suggest at the bottom, and that worked.

Judging from the rest of what you wrote, I see that my next readings should be on delegation and the responder chain. I will try those approaches next. And as you mention, duplicate code was bothering me, so I will try to put the window-opening code all in one place as well.

Thanks!

On Jan 20, 2008, at 5:45 AM, Ken Thomases wrote:

The nib should not contain an instance of a NSWindowController- derived class. An NSWindowController is intended to be the owner of the nib. As such, it's outside of the nib -- "above" it, in a certain sense. So, when it comes time to load WindowC.nib, you do:

WindowCController* myWindowCController = [[WindowCController alloc] initWithWindowNibName:@"WindowC"];

In the nib, you would set the class of File's Owner to WindowCController. You'd also connect its "window" outlet to the window in the nib. Then, anywhere that some other part of the code needs to refer to WindowC, you use this expression:

	[myWindowCController window]

If you want the WindowCController instance to know about the other windows, you can add some ivars to it and set them up. You can do that immediately after the alloc-init statement, above, or actually define your own custom init... method that takes additional arguments.

One thing that might be confusing you: you might want a controller which manages the window controllers. Often, there's an application controller, which might also be the application delegate. This application controller is what knows about the various nibs and window controller classes. So, it is what would allocate and initialize the WindowCController instance, as illustrated above except that myWindowCController would not be a local variable, it would be an instance variable. The application controller would also have the "global" overview sufficient to connect the various nibs and window controllers to each other.

How does a WindowCController get a pointer to the application controller? Well, it could be given one explicitly by the application controller when it creates the WindowCController instance. Or, the WindowCController can just use [NSApp delegate].

-Ken

_______________________________________________

Cocoa-dev mailing list (email@hidden)

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:
This email sent to email@hidden


References: 
 >beyond MV and (one) C (From: Daniel Child <email@hidden>)
 >Re: beyond MV and (one) C (From: mmalc crawford <email@hidden>)
 >Re: beyond MV and (one) C (From: Daniel Child <email@hidden>)
 >Re: beyond MV and (one) C (From: Ken Thomases <email@hidden>)

  • Prev by Date: Re: TableView::setDoubleAction's action always responding even editable items
  • Next by Date: crashing in Objective-C Cocoa code in Carbon app under Leopard
  • Previous by thread: Re: beyond MV and (one) C
  • Next by thread: Finder/iTunes Sidebar View?
  • Index(es):
    • Date
    • Thread