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: Howard Moon <email@hidden>
- Date: Fri, 18 Feb 2011 07:45:33 -0800
I guess the problem was not what I thought it was at all. Other problems I had led me to find a naming error (one letter capitalized that shouldn't have been), and that naming error made my class hierarchy break. (Doing a "Quick Model" showed me the broken link.)
I'm not too fond of the lack of detail in the Objective-C compiler errors. Many of the problems I've found in compiling my code so far seem really unrelated to the underlying errors. But I've learned to NEVER ignore the warnings in Objective-C! (Especially the "may not respond to" one! :-))
>
>>
>> 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'd love to, but being a working programmer, not a student, my time is quite limited, and I need to make substantive progress on something while learning. So I'm porting working code to the new framework while supporting as much existing C++ code as possible. Ditching the QuickDraw and the VST2AU wrapper stuff in favor of Cocoa and native AU is task one.
>>
>> 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.
>
I disagree with the "always prefer composition over inheritance" concept. At least the "always" part. One of my goals is to get rid of the multiple switch statements I've got in my C++ code, which are a pain in the butt to maintain and make my code listings HUGE (esp. with the large numbers of objects I have). I much prefer code that simply says "A doThis" and the objects know how to do it, over "if you're an A, doThisLikeA, else if you're a B, doThisLikeB, else...".
>>
>> 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.
I've understood that document fairly well, I think. The problem was that what I thought was a derived class was in fact not, due to a coding error that was not at all obvious. (GCC would have puked all over the attempt, but it compiled and ran in Objective-C. It just didn't do what I expected.)
<snip>
>
>>
>> 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.
Partially. Also, I have existing code (for Mac and Windows, AU, VST and RTAS) that generates the view hierarchy and parameters from XML. I'd like to leverage that existing code base as much as possible, and mirror it in Objective-C(++) in order to support 64-bit and remove the VST2AU wrapper we've been using.
Thanks for all the advice. (I do appreciate it, even if I sound like I'm defending poor practices, which I probably am.)
Regards,
Howard
_______________________________________________
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