should I use Control Manager for AUCarbonView?
should I use Control Manager for AUCarbonView?
- Subject: should I use Control Manager for AUCarbonView?
- From: Marc Poirier <email@hidden>
- Date: Wed, 21 May 2003 20:52:24 +0200 (CEST)
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?
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...
But actually, this whole topic brings up another issue that I've not
really been totally clear about with AUCarbonView, and that's the
expectations of event listeners hierarchies and target usage. Controls
should be higher up on the event target hierarchy than the window event
target, so if I did use the approach of keeping the PaneControl accross
the whole UI, then I should have no problem getting my mouse events before
any of the event targets that the host may have in the window. But beyond
that, is there any protocol in AU for lower levels of the event target
hierarchy, like, for example, the window? The window does belong to the
host, right? So do I have any grounds to assume that I can reliably
install window event listeners on the window's event target? Or is there
some chance that the host might install its window event handlers on top
of mine? Or is the very idea of an AUCarbonView installing event
handlers on the window's event target not recommended, or forbidden? Or
is the basic idea that I have reign over any events that might be
targetted for my view's region of the window, but otherwise the host has
priority? If it's the last situation, then this is pretty clear cut for
mouse events, but what about keyboard events?
Currently, I do install some event listeners on the window event target.
I do these for kEventMouseDragged, kEventMouseUp, kEventRawKeyDown,
kEventRawKeyRepeat, and kEventCommandProcess. This is because none of
these events are available for Control event targets, so I need to install
on the window event target. I use MouseDragged and MouseUp in order to
get non-modal mouse tracking of control mouse adjusting (rather than
TrackMouseLocation) and I use the key events obviously to receive key
presses. Am I being a bad child in the host window? Is there a
recommended way for an AUCarbonView to do this stuff?
Anyway, this is another line of questioning, maybe I should have put it in
a message separate from my questions about whether or not to use the
Control Manager, but the two things are pretty related, too...
Thanks for any insight or help,
Marc
_______________________________________________
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.