On May 25, 2005, at 9:49 AM, Luke Bellandi wrote:
It's no trick really. AU Lab installs event handlers on the Carbon Windows that contain the AU to manage the deactivation events. Namely:
EventTypeSpec applicationEventTypes[] = { {kEventClassApplication, kEventAppActivated }, {kEventClassApplication, kEventAppDeactivated } };
EventTypeSpec windowEventTypes[] = {
{kEventClassWindow, kEventWindowHandleDeactivate } };
In the event handlers for window-deactivate, we trap and eat the event so that it doesn't propagate to Carbon's standard event handler (which would re-draw the view's controls with a disabled appearance.)
- Luke
===
Personally, I'd consider that a trick... a very very clever one. ;)
So this is technically trapping the redraw if I'm reading it right correct - so the Carbon window is actually *always* deactivated in this state, but just not *drawn* as such... or is it the case where the Carbon window never *knows* it's been deactivated in terms it's knowledge of itself, but it actually is? (Basically what I'm saying is does the Carbon window *know* it's not active?)
I'm assuming you've tested this with a number of AUs, and this doesn't cause any issues with 3rd-party controls thinking they're deactivated and not accessible but visually they're still active (just thinking ahead - trapping and "patching" side effects have hit me a lot in the past)..
I'd imagine the trapper itself is a very small code snippet - the installation of the trapper and the trap itself... Coming from the Cocoa side, getting into the Carbon headspace takes a little bit - would you be willing to post the code snippet(s)?
Thanks for the trick! :)
Ev Technical Knowledge Officer Head Programmer/Designer Audiofile Engineering
|