Re: Cocoa's custom class delegate conventions
Re: Cocoa's custom class delegate conventions
- Subject: Re: Cocoa's custom class delegate conventions
- From: Marco Scheurer <email@hidden>
- Date: Sat, 14 Jun 2003 05:46:11 +0200
On Saturday, June 14, 2003, at 05:25 AM, Jean-Francois Roy wrote:
I have written several custom classes (NSObject subclasses) and I want
to give a delegate to several of them. But I have hit what seems a
lack of documentation on how delegate methods should be called.
In particular, I was wondering how delegate methods should be called.
Once an object has checked if it has a delegate, should it simply call
the appropriate selector for the given context directly, use
NSObject's performSelector methods, which does not allow for more than
one parameter, use NSObject's performSelectorOnMainThread methods to
ensure that the delegate receives the message on the main thread, but
again with a one parameter limitation, or what?
First you should at least verify that your delegate does respond to the
selector (respondsToSelector:) you will invoke.
if ((delegate != nil) && ([delegate
respondsToSelector:@selector(thingWillDoStuff:)) {
[delegate performSelector:@selector(thingWillDoStuff:)
withObject:self];
}
Then there are performSelector methods with more than one argument,
such as performSelector:withObject:withObject:. If you want to do more
complicated stuff, you can always use an NSInvocation.
It seems that delegate methods rarely need more than one parameter.
This is because the parameter is usually the sender (or a notification
object) which can be queried for more information.
Marco Scheurer
Sen:te, Lausanne, Switzerland
http://www.sente.ch
_______________________________________________
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.