• 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: Delegates -- WHAT is delegated?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Delegates -- WHAT is delegated?


  • Subject: Re: Delegates -- WHAT is delegated?
  • From: mmalc crawford <email@hidden>
  • Date: Thu, 21 Dec 2006 09:02:32 -0800


On Dec 20, 2006, at 4:28 PM, Klaus Backert wrote:

E.g. the class NSMatrix has a method textShouldBeginEditing:, which sends control:textShouldBeginEditing: to the delegate of the NSMatrix by default. This delegate could be any class (e.g. a subclass of NSWindowController). The method control:textShouldBeginEditing: is defined in the header of this class, but not in the header of NSMatrix. The names of the methods don't have to be similar, of course.

Generally it's not necessary, that the delegated method is implemented in the delegating class at all, I think.


(1) When it comes to a point when behaviour may be influenced by a delegate, an object first checks whether a delegate has been set, then (if a delegate has been set) whether the delegate implements the currently-relevant method.



(2) If you want to implement and use a delegate, then:

(a) You must set the delegate for the relevant object (either through setting an outlet in Interface Builder or programatically with setDelegate:).
(b) You must implement the correctly-named method (for example, - windowSlouldClose: is not a valid substitute for -windowShouldClose:).


Failure to do either or both of these is a common cause for delegation not working as expected.


(3) The delegate is (almost? *) always an object other than the delegating object -- the whole point of delegation is to devolve responsibility to a more suitable locus of control. To use the canonical example, it is not the job of the window object to know whether there is unsaved data -- it's the role of a controller to track that information and to ensure that the window behaves accordingly (say, by not closing without prompting the user...).



This is all documented here:
<http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CommunicatingWithObjects/chapter_6_section_4.html >


mmalc


(*) I can't immediately think of a situation in which it is not, I'm sure someone will chime in if there is...
_______________________________________________


Cocoa-dev mailing list (email@hidden)

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: 
 >Re: Cocoa-dev Digest, Vol 3, Issue 1474 (From: Sam Colombo <email@hidden>)
 >Re: Delegates -- WHAT is delegated? (From: Klaus Backert <email@hidden>)

  • Prev by Date: Re: again with paths and images
  • Next by Date: Re: again with paths and images
  • Previous by thread: Re: Delegates -- WHAT is delegated?
  • Next by thread: Re: Delegates -- WHAT is delegated? (was Re: Cocoa-dev Digest, Vol 3, Issue 1474)
  • Index(es):
    • Date
    • Thread