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: Bill Stewart <email@hidden>
- Date: Thu, 22 May 2003 17:56:52 -0700
Can't say that I'm keeping up with all of this... but...
On Thursday, May 22, 2003, at 02:39 PM, Marc Poirier wrote:
>
On Wed, 21 May 2003, Chris Reed wrote:
>
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...
We ran across this problem ourselves recently...
We were doing some drawing in response to moving a slider - the drawing
just happens off a EventLoopTimer object... Initially we'd used an
IdleEventTimer and of course, as we clicked on the slider to move it
the drawing would stop (we're not "idling" anymore) - the fix was easy
- to use EventLoopTimerRef rather than EventLoopIdleTimerRef
>
> 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.
I'm not sure that I can give you a clear answer on this... The window
is owned by the host and its not safe to make any assumptions about
what else is going on in the window - but except for edit text boxes
where the focus issue is clear - this is a knarly kind of problem... If
you have more than one AU's view in display at a given time - who gets
the key event?
I'm not sure that I have any answers to this - maybe this is something
we have to figure out together with some of the host apps...
Bill
>
>
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.
>
>
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
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.