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: Marc Poirier <email@hidden>
- Date: Thu, 22 May 2003 23:39:49 +0200 (CEST)
On Wed, 21 May 2003, Chris Reed wrote:
>
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.
Hmmm, I've been using the Control Manager API with a custom
ToolboxObjectClass for all of the controls. So there is code re-use, I'm
not writing all of the stuff from scratch for every type of control I use.
I should probably also add that I've already done most of this work, so my
question wasn't from the point of view of should-I-do-this but more
should-I-trash-what-I've-done. And also I should add that what I'm
working on is a cross-platform, cross-plugin-API GUI framework for Destroy
FX (it will, for now, support AU in Mac OS X and VST in Windows, which is
the platform that my DFX plugin partner uses). He's going to just be
taking mouse and key events and dispatching them to controls himself, so
I'm starting to wonder why I don't just do that rather than dealing with
the "mindset" of the Control Manager and control events and whatnot (all
values are int, one value per control, controls are rectangles, controls
don't overlap, etc.).
I'm pretty ignorant with respect to HIView, though. It sounds like it's
sort of a C++ API version the Control Manager C API? I guess I should
just go learn more about it...
>
Imho, there are lots of reasons to use real HIView subclasses or
>
Control Manager controls.
This is what I'm really curious about. :) So what are these reasons?
>
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.
Thanks, interesting idea.
>
(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 >;-)
Your framework is way better than VSTGUI! You're going way backwards if
you try that... ;-)
>
Take a look at the AUGUI code. Airy came up with a great solution for
>
doing non-modal tracking (in the TViewNoCompositingCompatible class).
Just to re-iterate since I wasn't clear: I have solved all of these
problems mostly and written all of this code, but I'm not sure it's the
best way. I have non-modal mouse tracking happening (I think it's the
same approach that you folks use, it's what an Apple person recommended
when I posted about this to the Carbon dev list a couple months back).
Well, with respect to the non-modal mouse tracking, I know that it's
basically the only way to get what I want (another limitation of the
Control events stuff, that I just have to work around, making me again
wonder why I'm even using Control events), but the next issue is whether
it is okay for me to install handlers for these window events...
>
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.
Thanks. I am kind of thinking the same thing, but a definitive answer
from someone in the CoreAudio team would be useful, also especially
regarding keyboard events. I'm working on implementing a lot of keyboard
control for our plugins, but I'm not sure what the protocol is for this
stuff.
Thanks,
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.