On 3 May 2008, at 12:56 am, Matthew Gertner wrote:
Seems like you can "pretend" you implement them using
respondsToSelector (see Graham's reply).
Exactly - the delegate is sent the message if it says it implements
it, even if it really doesn't. Then NSObject says "wait a minute, I
don't
on 2008-05-02 10:44 AM, Graham Cox at [EMAIL PROTECTED] wrote:
> You also need to override -respondsToSelector: and return a logical OR
> of your delegate plus the old delegate's response, something like:
I use this techhnique in my PreFab Event Taps Testbench utility.
I call this the "delegate
Seems like you can "pretend" you implement them using
respondsToSelector (see Graham's reply).
On Fri, May 2, 2008 at 4:53 PM, Andy Lee <[EMAIL PROTECTED]> wrote:
> Delegate methods aren't sent at all unless the delegate implements them. I
> think your delegate is going to have to implement all p
Thanks, Graham. It seems like the superclass deals with rejecting the
message, but I was missing respondsToSelector. Added that and now it
works perfectly!
Matt
On Fri, May 2, 2008 at 4:44 PM, Graham Cox <[EMAIL PROTECTED]> wrote:
> You also need to override -respondsToSelector: and return a logi
This is smarter than my suggestion.
--Andy
On May 2, 2008, at 10:44 AM, Graham Cox wrote:
You also need to override -respondsToSelector: and return a logical
OR of your delegate plus the old delegate's response, something like:
- (BOOL)respondsToSelector:(SEL) aSelector
{
BOO
Delegate methods aren't sent at all unless the delegate implements
them. I think your delegate is going to have to implement all
possible delegate methods and then forward them *if* the old delegate
implements them, and otherwise return an appropriate default value if
there is a return val
You also need to override -respondsToSelector: and return a logical OR
of your delegate plus the old delegate's response, something like:
- (BOOL)respondsToSelector:(SEL) aSelector
{
BOOL responds = [super respondsToSelector:aSelector];
if( !responds )
