Accessory NSPanel vanishes on first click after app launches - Follow up
Accessory NSPanel vanishes on first click after app launches - Follow up
- Subject: Accessory NSPanel vanishes on first click after app launches - Follow up
- From: Peter <email@hidden>
- Date: Tue, 02 Aug 2011 22:42:34 +0200
After setting a breakpoint at -[NSWindow orderOut:] (thanks for this and other hints to Kyle Sluder! - in a post on this list about a year ago) it turns out that it is exactly my
- (void)windowDidResignKey:(NSNotification *)notification
which takes the panel off the screen. (I wonder why I hadn't realized this before, when I set a breakpoint in that very method...)
I am still puzzled: why should a click on the panel make the main window resign from key only once and the first time after the app launched?
The initial state of the app before this first mouse click is: "main window is front and key, i.e. window header is hilited, insertion point blinking in the text view designated to be the first responder", "panel is visible but not key, i.e. window header is greyed out".
I added
- (void)awakeFromNib
{
[editPanel setBecomesKeyOnlyIfNeeded:YES];
}
to the controller, which does not change anything, except that now I have click on the window header of the panel to make it vanish. After that everything works normally again, as previously described.
I also tried
[editPanel orderWindow:NSWindowAbove relativeTo:[mainWindow windowNumber]];
but this also does not change anything.
Placing NSLogs in both delegate methods reports the following three messages when executing a single click on the panel header right after the app launched:
window resign: <NSWindow: 0x420bd0>
window key: <NSWindow: 0x420bd0>
window key: <NSPanel: 0x424dd0>
So after the click, the panel is key window and off-screen at the same time, where in fact the main window is key. And this is the last time I get a notification about the panel before I restart the app, no matter how hard I try. Both the panel and the window each have a single memory address throughout the app's lifetime.
Any pointers?
Thanks a lot!
(I corrected a couple of language problems in the following self-quotation)
> Developing for OS 10.5 and 10.6 I have an application with a main window (no documents window
> s) and a (non-modal) accessory NSPanel I want to show only when the main window is the key window. I want the NSPanel hidden, however, when the preferences or about window comes up or when the app is in the background. The panel is only for use with the mouse and does not have to become key window.
>
> I implemented this using the following delegate methods for the main window:
>
> - (void)windowDidBecomeKey:(NSNotification *)notification
> {
> if ([notification object] == mainWindow) {
> [editPanel orderFront:self];
> }
> }
>
> - (void)windowDidResignKey:(NSNotification *)notification
> {
> if ([notification object] == mainWindow) {
> [editPanel orderOut:self];
> }
> }
>
> Everything works as intended - except immediately after the applications launches:
>
> The main window is shown, and floating above it the panel, as intended.
> When I click on the the panel for the first time, however, the panel vanishes from the screen.
>
> After I deactivate and activate the window again (e.g. by showing the preferences window etc.) the panel is shown again and from then on works absolutely normally: When the main window is key, the panel is shown and accepts mouse clicks, and it is hidden when the main window resigns key. (Both the panel and the main window are instantiated in the nib. Turning visible at launch on or off does not seem to have an influence. I am not using any bindings for both windows in question. None of the windows in question use dedicated window controllers.)
>
> I am puzzled and I don't have a clue how to debug this. The debugger log shows nothing.
>
> I experimented with
>
> [mainWindow addChildWindow:editPanel ordered:NSWindowAbove];
>
> and
>
> [mainWindow removeChildWindow:editPanel];
>
> but did not manage to achieve the desired effect.
>
> Thanks for any insight or pointers to relevant documentation.
>
Peter_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden