Re: Sort of OT: Closing Carbon-based view windows with the menu
Re: Sort of OT: Closing Carbon-based view windows with the menu
- Subject: Re: Sort of OT: Closing Carbon-based view windows with the menu
- From: Robert Grant <email@hidden>
- Date: Sat, 5 Mar 2005 14:09:46 -0500
Well the awesome gandbug utility has at least revealed that the
NSCarbonWindow is first on the responder chain when the window is key
and ordered front - so the chain isn't buggered as I thought:
========Responder Chain========
1 : <NSCarbonWindow: 0x54b9650>
2 : <AUEditController: 0x546c9f0>
So it looks like it's eating the performClose: because the
AUEditController (which my NSWindowController) is not getting a chance
to handle it (I put a performClose method in there just in case).
However murat's work-around is now working nicely. BTW to get past the
compiler error on NSCarbonWindow just forward declare the class:
@class NSCarbonWindow.
Thanks for the help everyone,
Robert.
On Mar 4, 2005, at 11:20 PM, m wrote:
This is for the archives and is a correction to my earlier post.
I'm assuming you're hosting your AUs in carbon windows. In Cocoa,
these get wrapped up in an NSWindow subclass called NSCarbonWindow,
which as you've discovered, doesn't seem to handle the performClose:
method correctly.
closeWindow: is a method in my app delegate (not the window's delegate
as I erroneously claimed in my earlier note). Then you have to wire up
the close menu to call the closeWindow: method of the app delegate.
This should take care of the cmd-W and Close menu item not working.
The other tip about activating when the AU content is clicked is
correct as described.
_murat
On Mar 4, 2005, at 1:43 PM, m wrote:
On Mar 4, 2005, at 12:41 PM, Robert Grant wrote:
A user just brought to my attention that Apple+W is not closing the
AU editor windows. Testing with Cocoa and Carbon AU views shows that
it's Carbon windows that are causing trouble. The Carbon in Cocoa
docs imply that there's nothing to do to support it and sure enough
the sample app happily closes the Cocoa'ized Carbon window. But in
Rax I just get an annoying beep. So it looks like the Responder
chain is buggered somewhere along the line.
Hi Robert,
I thought I had written to you about this a few months ago. I had
wrestled with the same thing and concluded it was "just broke".
Here's how I worked around it.
In your window's delegate:
- (IBAction) closeWindow:(id)sender
{
NSWindow* keyWindow = [NSApp keyWindow];
if ([[keyWindow class]isSubclassOfClass:[NSCarbonWindow class]])
{
[keyWindow close];
}
else
{
[keyWindow performClose:sender];
}
}
By the way, many AU hosts also have a problem where clicking in the
content area of an inactive AU window won't activate it. Here's a fix
(in a subclass of NSApplication):
- (void)sendEvent:(NSEvent *)anEvent
{
if ( [anEvent type] == NSLeftMouseDown &&
!([anEvent modifierFlags] & NSCommandKeyMask) &&
[[anEvent window] isKindOfClass:[NSCarbonWindow class]])
{
[[anEvent window] makeKeyAndOrderFront:self];
}
[super sendEvent:anEvent];
}
_______________________________________________
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
_______________________________________________
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