Re: Programmatically created NSView subclasses, and mouse events
Re: Programmatically created NSView subclasses, and mouse events
- Subject: Re: Programmatically created NSView subclasses, and mouse events
- From: Kyle Sluder <email@hidden>
- Date: Thu, 17 Feb 2011 23:59:24 -0800
On Feb 16, 2011, at 9:36 AM, Howard Moon <email@hidden> wrote:
> Hi all,
>
> I'm teaching myself Objective-C and Cocoa, by working on a simple (so I thought) modification to the default AudioUnit effect project. But in this project, I create my own views programmatically instead of using the NIB. (I know - why??? Just go with me, ok? :-))
If you're going to learn Cocoa, you should do it the right way. I'd also suggest doing it outside of the context of Audio Units, where you need to worry about Carbon host apps. Come back to your Audio Unit project when you've got a good grasp on Cocoa fundamentals.
>
> I have a hierarchy of NSView descendants, and ones below a certain "base" class in the hierarchy need to respond to mouse clicks. (Other branches do not.)
It sounds like you've got a large number of NSView subclasses, and that their place in the class hierarchy might almost mimic their place in the view hierarchy.
Please stop to reconsider whether you really need many subclasses. Always prefer composition over inheritance. If you have five different widgets that are 99% the same, but all act differently in one respect, do not make five widget subclasses. Make one widget class that has a delegate which can implement or be queried about the divergent behavior.
>
> My first attempt was to add -mouseUp: and -mouseDown: to the "base" class that directly inherits from NSView, and then only override those in subclasses that need changes to the default behavior. However, none of my subclasses of that "base" class respond to mouse clicks when I do it that way.
In your coreaudio-api thread on this topic, I linked you to documentation that specifically addresses complication with mouse tracking. http://developer.apple.com/library/mac/#documentation/cocoa/conceptual/EventOverview/HandlingMouseEvents/HandlingMouseEvents.html#//apple_ref/doc/uid/10000060i-CH6-SW18
Please read this and make sure you understand it. In particular, think of how you would implement mouse tracking if you were writing framework code. It might help illuminate how you're expected to use it as an API client.
>
> In order to get the descendants of this base class to respond to mouse clicks, I had to override those functions in *each* class that I want to handle mouse clicks. (And in order to get the default behavior, I assume I'll just call [super mouseDown:theEvent], right?)
Maybe. It depends on how super is implemented. Read the aforelinked document.
>
> I know I'm new at this, and maybe this is really an Objective-C question, but.. why? What causes those functions to be called when implemented in the individual subclasses, but not when only implemented in the base class? Shouldn't all derived classes inherit the behavior of their ancestors, including those functions?
Again, it depends on the implementation. If -mouseDown: runs the runloop itself, the other mouse methods don't get called.
>
> I'm *guessing* that is has something to do with the way events are handled, and that some kind of check is done to make sure the class implementing those functions is in fact the same class as the target of the event, but that's just a guess. My alternate guess is that's the way Objective-C works.
Neither of these.
>
> Anyone care to enlighten me? I'm reading my little eyeballs out, but just can't find much info on programatically-created NSView hierarchies (my Cocoa programming book is all NIB-based stuff).
The reason you are finding so little information about programmatic view creation is that a) it's really not that complicated and b) you should be using NIBs.
I'm guessing you want to learn how to create views programmatically because your AU's interface needs to be configurable.
--Kyle Sluder
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden