OK - that makes some sense, excepting that if I don't set the delegate, and just define the methods, they don't get called at all. Also, all the delegates are useless to me, b/c none of them fire when the selection has been made, only when the box is initially created. I've set the delegate to be the class that contains it and resolved my overall issue, but I cannot get a mouseUp event from the IKImageView, without which, I don't see how to respond to the end of a selection action, as opposed to the start of it ? Thanks
Christian On Fri, Feb 6, 2009 at 2:12 PM, Graham Cox <[email protected]> wrote: > > On 6 Feb 2009, at 11:50 am, Christian Graus wrote: > > I have a class derived from IKImageView, and in my initWithFrame ( which >> is >> the only init I call ), I set [self setDelegate:self]; >> Once I do this, I have this code: >> >> - (void) selectionRectAdded: (IKImageView *) imageView >> >> { >> >> NSLog(@"Created sel rect"); >> >> } >> >> I run the app and make a selection. This log message is displayed twice ( >> sadly, both times before the selection ends, which is a PITA ). Now, >> here's >> where it gets interesting. My app crashes with a bad access, and then >> XCode >> reports that it's loading 400000 stack frames or something. Which makes >> me >> think I've created infinite recursion, but I don't see how. I only set >> the >> delegate in initWithFrame, so I don't see how I could have set the >> delegate >> over and over ( does it even work that way ? ). Does anyone have any >> suggestion what I may be doing wrong, please? >> > > > > Setting an object's delegate to itself is never a good idea. It's a common > pattern that an object will implement a message <foo> which in turn will > test if its delegate implements <foo> and if so, call it, and if not, do > nothing or some default behaviour. If the delegate is self this will > immediately enter an infinite loop (and it seems rare that an object will > also test if delegate == self in these cases). > > If you are subclassing the IKImageView, you have only to override the > methods you're interested in. There's no need to set the delegate to self, > it's not going to tell you anything different from what your subclass can > find out directly. By the definition of the delegate pattern the delegate is > *another object* that assists yours. If it's the same object it's not a > delegate. (You don't keep a dog and bark yourself). > > WAYTTD? > > --Graham > > > > > _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
