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: Chris Reed <email@hidden>
- Date: Wed, 21 May 2003 21:59:10 -0500
On Wednesday, May 21, 2003, at 13:52 US/Central, Marc Poirier wrote:
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?
Like Airy said, we use HIView subclasses in AUGUI. Writing these
subclasses is very easy.. the HIView stuff takes care of lots of the
hard work for you. For most controls, you only have to implement a
small handful of methods.
Imho, there are lots of reasons to use real HIView subclasses or
Control Manager controls. But one case where it makes sense to abandon
(well, not quite abandon) high-level control/view objects is when you
have lots of small sub-view type objects.
You might consider creating a HIView subclass that is a container
object for your own light-weight view objects. These objects might
support only a limited subset of the normal control methods. Maybe just
drawing and mouse handling. The container control would pass events to
these sub-view objects.
This would mostly be helpful in a case like Urs' where he has hundreds
of similar controls.
In any case, if you do decide to forgo the Control Manager, I would
wrap everything up in a custom HIView subclass (actually, pretty much
what I described above). This would give you an event target, as well
as a CGContext to draw in. I think most if not all the concerns you
stated here would be addressed. In general it would makes things
easier. And you could easily reuse your custom view system in other
projects by just creating one of these controls.
(Hmm. I like this idea a lot actually... I'm going to look at it
myself.. I wonder how hard it would be to wrap the VSTGUI source up in
a HIView subclass >;-)
I do see some potential problems with abandoning Control Manager,
though.
Primarily I'm wondering upon what target I should install my event
handlers and how I will determine a CGDrawContext for drawing. One
idea
would be to keep the mCarbonPane parent PaneControl and just request
all
ControlClass events for that target. Then I'd have to basically
create my
own kEventControlDraw events by making calls to
Draw1Control(mCarbonPane)
whenever I need to redraw some part of the GUI. But maybe there's a
better way? I'm not sure, though, if there's a good way to get or
create
a CGDrawContext without it being a reaction to a kEvent*Draw event...
[snip window target stuff] Am I being a bad child in the host window?
Is there a
recommended way for an AUCarbonView to do this stuff?
Take a look at the AUGUI code. Airy came up with a great solution for
doing non-modal tracking (in the TViewNoCompositingCompatible class).
But to answer your question: yeah, I think installing handlers on the
window target is a bad idea. The host owns the window, so you really
should not touch it at all, imho. There's no telling what the host uses
the window for in addition to your editor.
On the other hand, if you always returned kEventNotHandledErr or
whatever, it might be safe. Doing this would cause the next installed
handler for the event target to be called. Still, you don't know if the
host has installed another handler on top of yours. And they probably
won't return kEventNotHandledErr, so you can't be sure you'll get all
the events you are looking for.
cheers
-chris
_______________________________________________
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.