• 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
Responder Chain and NSViewController in non-doc applications
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Responder Chain and NSViewController in non-doc applications


  • Subject: Responder Chain and NSViewController in non-doc applications
  • From: Jerry Isdale <email@hidden>
  • Date: Mon, 30 Jun 2008 09:52:17 -0700

I'm trying to understand a bit more about the Responder chain, especially how it relates to regular (non-document) applications using NSView and NSViewController added into the View Hierarchy.
Katidev.com has a nice series of articles on the related issue for Document based applications. (It starts at http://katidev.com/blog/2008/04/09/nsviewcontroller-the-new-c-in-mvc-pt-1-of-3/)


However, it doesnt give me enough background to understand why I need a XSViewController (extension of NSViewController), and how the Controller hierarchy fits in with the View Hierarchy.

When does an application following the Responder Chain look at the ViewController?
The clues I have (from KatiDev and Apple's "Cocoa Event-Handling Guide" (aka EventOverview.pdf) is that the EVENT chain starts with the current focus Window's First Responder, and then it traverses the View Hierarchy's responder chain.... which I think means going up to the parent (containing) view and checking its responder until you get to the Window, then the WindowDelegate, and then the NSWindowController.


Event Messages (aka events) dont get passed to the NSViewController in the normal (NS) world. The XSController extension (katidev.com) puts these back in, such that it when the event gets to the XSWindowController it would get passed down the XS-responder chain (see the article).

Action Messages (actions) follow a slightly different path. Actions start by an Event responder (eg a ButtonCell) firing off a sendAction:to:from. If there is a designated Target (to:) defined by the responder, that object gets the action. Otherwise the sendAction:to:from goes to the First Responder, up the view hierarchy, to the NSWindow, to the WindowDelegate, to the NSApp then the AppDelegate.

Again, the NSViewController doesnt appear in the responder chain, unless it was designated by the initial Event Responder. If it was designated, but doesnt respond, what happens? An Error or does it go back to the responder chain?

The NSViewController is a Responder, but the associated view does not patch it into the responder chain for either event or action responding.

Correct?

But if my design explicitly specifies the target (connecting IBActions in InterfaceBuilder), I dont have to worry about the Responder chain for actions. Correct?

Thanks

Jerry Isdale
email@hidden



_______________________________________________

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


  • Follow-Ups:
    • Re: Responder Chain and NSViewController in non-doc applications
      • From: Cathy Shive <email@hidden>
    • Re: Responder Chain and NSViewController in non-doc applications
      • From: Jonathan Dann <email@hidden>
    • Re: Responder Chain and NSViewController in non-doc applications
      • From: j o a r <email@hidden>
  • Prev by Date: Some advice re. "saving" a variable so it is accessible to all classes/methods
  • Next by Date: Re: NSDateComponents question
  • Previous by thread: Re: Some advice re. "saving" a variable so it is accessible to all classes/methods
  • Next by thread: Re: Responder Chain and NSViewController in non-doc applications
  • Index(es):
    • Date
    • Thread