Re: New way for Cocoa AU hosts to wrap Carbon AU GUIs?
Re: New way for Cocoa AU hosts to wrap Carbon AU GUIs?
- Subject: Re: New way for Cocoa AU hosts to wrap Carbon AU GUIs?
- From: William Stewart <email@hidden>
- Date: Wed, 25 May 2005 17:59:45 -0700
Yes, pretty much. thanks. We'll get the Tech Note written to
summarise all of this as soon as we can
Bill
On 25/05/2005, at 5:37 PM, Evan Olcott wrote:
On May 25, 2005, at 6:54 PM, Luke Bellandi wrote:
You're right: there is a concept of 'key window' in Carbon, though
it's called 'user focus' instead.
What is the specific problem you're having? You say you don't
want the Carbon window to become key. Can you expand on that a bit?
Certainly.
Using the method of making a AU carbon view a "hooked on" child
window of a Cocoa window (via the document I was pointing to a few
emails back), the caveats were many. One of them being when you
clicked on the Cocoa parent window, the carbon 'window' would be
deactivated. When you clicked on the carbon 'window' child, the
Cocoa window parent would be deactivated (visually, the title bar
made it look like it was in the background). It was very confusing.
Watching AULab overcome this issue, I was intrigued.
Now with the first trick you've given us, we're now able to trick
the Carbon 'window' from ever getting deactivate messages, which
prevents the controls, et al from going visually inactive. So we've
got that. Now the other side of that coin is when we click on the
Carbon 'window' or an AU's control - bringing that Carbon window
"to the front" or "becoming key" (or I suppose "having user
focus"), the Cocoa window host still becomes inactive.
SO - using the same (or similar) methodology, I assume we can do
one of two things: prevent the Carbon window from becoming key, or
prevent the Cocoa parent window from losing it's key status. The
second option is dangerous, but assumedly possible (there are other
Cocoa NSPanel "palettes" in my app - it should be able to be
"deactivated" at times).
Thus my asking how to prevent the Carbon 'window' from becoming key
(or having user focus), but this sounds kind of unlikely - would a
window without user focus get events for it's controls? Etc etc.
Does that help explain what we're looking for?
Ev
Technical Knowledge Officer
Head Programmer/Designer
Audiofile Engineering
http://www.audiofile-engineering.com/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
--
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
________________________________________________________________________
__
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden