Re: should I use Control Manager for AUCarbonView?
Re: should I use Control Manager for AUCarbonView?
- Subject: Re: should I use Control Manager for AUCarbonView?
- From: Airy André <email@hidden>
- Date: Wed, 21 May 2003 22:05:23 +0200
Le mercredi, 21 mai 2003, ` 20:52 Europe/Paris, Marc Poirier a icrit :
I'm starting to wonder whether I should even be bothering to use the
Control Manager for my AUCarbonViews. It's great because it provides a
lot of good default handling of a lot of useful standard controls like
sliders, pop-up menus, radio buttons, push buttons, etc. But my AUs
all
use 100% custom controls, which means that I don't get any of that
out-of-the-box default event-handling behavior but instead have to
implement it all myself. Given that, I'm really starting to wonder
whether it's worth my time implementing all of the proper, expected
Control Manager behavior for my custom controls. Aside from the fact
that
the Control Manager will keep track of which control my mouse clicks
land
in, I can't think of any advantages. Well, I guess that maybe it also
makes it easier to play along with the expected rules and behavior of
control focus, too (which is something that I haven't implemented yet,
but
plan to). But I have found disadvantages (for example, I'm still
struggling with how to implement a single XY control that controls
2 parameters and do it well).
But maybe there's just something important that's slipping my mind. So
that's my first question, I'm wondering what others think: Am I right
that I'm just wasting my time working with the constraints and
expectations of the Control Manager when I'm using nothing but a bunch
of
custom controls, or are there compelling reasons for me to continue
with
this approach?
As you know, I've choose the standard control way, using HIView and
HIFramework.
HIView are just for that.
This way, making custom controls is just writing simple C++ classes,
with easy and well documented methods. And your same controls can be
used for non AU projects (or for your hosts...)
The code is easy to write and easy to read.
And let the system dispatch the right events to the right object for
you...
About the XY control, why don't you just register your control for the
two parameters you are interested in. In your "ValueChanged" method
(sorry, I am speaking HIFramework here...) , just ignore the value and
ask the AU for the 2 parameters values.
And in your Tracking method, instead of setting the value of your
control, just change the parameters of the AU (but don't change your
value).
Being able to give a ControlData selector when creating
AUCarbonViewControl would be a very nice addition for this kind of
thing.
The AUCarbonViewControl::ControlToParameter and ParameterToControl
would use this selector if defined instead of
GetControlValue/SetControlValue.
After all, this is already what it is done for text controls...
It would be a minor change to the SDK and would let make complex
controls much simpler and cleaner (and being able to stay AU
independant stuff) ...
Just a 5 minutes thought...so there is probably much better methods...
Airy
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.