On 01-Mar-2010, at 9:29 AM, Kyle Sluder wrote: > On Sat, Feb 27, 2010 at 6:37 PM, Roland King <r...@rols.org> wrote: >> Thanks that's what I see too. That thread doesn't explain why of course. I >> have a trivial test case so I'll file this as a bug and see what comes back >> because I think the behaviour is wrong. For now I'm using a different object >> as delegate, which isn't so neat but works fine. > > The thread does explain exactly what's going on in the UITextField > case: it sends itself messages which are also sent to the delegate. > > In your case, -[UITextView keyboardInputChangedSelection:] calls [self > textViewDidChangeSelection:], which in turn asks if [self.delegate > respondsToSelector:@selector(textViewDidChangeSelection:)], which > obviously returns YES, so it calls [self.delegate > textViewDidChangeSelection:]. Because self == delegate, you infinitely > recurse. >
There's two reasons that theory doesn't appear to be right in this case. Firstly if that's what happened, the program would recurse, the stack would be full of textViewDidChangeSelection: calls each calling the next, but that is not what happens, the program hangs, the code infinitely loops, but it does not recurse, the stack stays about 20 stack frames deep. Secondly, respondsToSelector:@selector(textViewDidChangeSelection:) doesn't return YES, it returns NO (which is what I'd expect because I haven't implemented it or anything else come to that matter). UITextView does not implement or respond to textViewDidChangeSelection:. (UITextView does implement the other method in that trace, keyboardInputChangedSelection: but that's not a delegate method, it's not even a documented method so it must be private.) I think that thread is also confused about the delegate pattern as used in cocoa and mixes it up with the more general decorator pattern. The notion stated early in that thread is that delegation means if you yourself do not respond to a given selector, you ask your delegate if it responds to it. That may be close to what decoration means, but it's not cocoa delegation where there are a set of selectors your delegate may/must respond to, but they are in general a different set of selectors from those your class implements and they are conditionally called on the delegate object only, not the class itself, during the processing of a usually entirely differently named method. I agree that if a class implemented one of its own delegate methods and if that implementation called the delegate's implementation of that method without checking for delgate==self and if you then went to set delegate=self you'd recurse (I think if a class allowed that to happen by not checking that it would be a bug by the way). That's not what's happening here however, UITextView doesn't implement the delegate method, it's not being called and the code isn't recursing, it's looping for a different reason. I filed this one as a bug, I'll see what comes back and if I get a 'works correctly' on it I'll go burn up a support incident, I have two and they're expiring all too soon anyway. If anything interesting comes out of it I'll follow up. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
