Drawer window error


Bill Cheeseman
 


On Jul 17, 2017, at 8:13 PM, Graham Cox <graham@...> wrote:

I can’t see that I’m doing anything wrong - the hosting window (parent) does have -initialFirstResponder set to an outline view IN ITS OWN WINDOW. The drawer part has nothing to do with it - I’m not even making the drawer part myself, it has no existence within the nib, I only provide its content view.

Is it reasonable to suggest this is an Apple bug? I understand Drawers are a thing of the past, so maybe Apple doesn’t bother testing them properly, but for now I don’t have time to revise my design, so a drawer it is.

If you Google this enough, you'll find several threads reporting this error message in macOS Sierra 10.12 over the last year or so, including one from me. The conclusion of the discussion, including my personal conclusion, is that this is a harmless message and can be ignored. Someone reported that the message is gone in High Sierra, but I haven't yet verified that myself.

My main app will continue to use drawers for the first little while into High Sierra, for the same reason you give. I am in the process of rewriting it in Swift and will take that opportunity to completely redesign the UI.


-- 

Bill Cheeseman - wjcheeseman@...


Graham Cox
 

On Sierra, I’m getting the following posted when I open a window that hosts a drawer:

2017-07-18 10:06:31.546972+1000 Ortelius 2[10080:3577648] [General] ERROR: Setting <NSOutlineView: 0x10182d140> as the first responder for window <NSDrawerWindow: 0x10183ed30>, but it is in a different window (<NSWindow: 0x6180001e5400>)! This would eventually crash when the view is freed. The first responder will be set to nil.
(
0 AppKit 0x00007fff9f5969cf -[NSWindow _validateFirstResponder:] + 557
1 AppKit 0x00007fff9ed1174c -[NSWindow _setFirstResponder:] + 31
2 AppKit 0x00007fff9edb9cd2 -[NSWindow(NSDrawerSupportPrivate) _changeAllDrawersFirstResponder] + 101
3 AppKit 0x00007fff9edb9c5f -[NSWindow(NSWindowSharedFirstResponder) _changeAllAttachmentsFirstResponder] + 22
4 AppKit 0x00007fff9edb9acb -[NSWindow _realMakeFirstResponder:] + 659
5 AppKit 0x00007fff9edb97e4 -[NSWindow makeFirstResponder:] + 123
6 AppKit 0x00007fff9ee3c4c1 -[NSWindow _selectFirstKeyView] + 865
7 AppKit 0x00007fff9ee3c133 -[NSWindow _setUpFirstResponder] + 232
8 AppKit 0x00007fff9ee3af3d -[NSWindow _doWindowWillBeVisibleAsSheet:] + 169
9 AppKit 0x00007fff9f5a163e -[NSWindow _reallyDoOrderWindowAboveOrBelow:relativeTo:findKey:forCounter:force:isModal:] + 1514
10 AppKit 0x00007fff9ee396ce -[NSWindow _doOrderWindow:relativeTo:findKey:forCounter:force:isModal:] + 1041
11 AppKit 0x00007fff9ee39263 -[NSWindow orderWindow:relativeTo:] + 153
12 AppKit 0x00007fff9eeebbab -[NSWindow makeKeyAndOrderFront:] + 111
13 QuickLookUI 0x00007fffa6cbd519 -[QLSeamlessDocumentOpener showWindow:contentFrame:withBlock:] + 108
14 AppKit 0x00007fff9eeead37 -[NSWindowController showWindow:] + 689


I can’t see that I’m doing anything wrong - the hosting window (parent) does have -initialFirstResponder set to an outline view IN ITS OWN WINDOW. The drawer part has nothing to do with it - I’m not even making the drawer part myself, it has no existence within the nib, I only provide its content view.

Is it reasonable to suggest this is an Apple bug? I understand Drawers are a thing of the past, so maybe Apple doesn’t bother testing them properly, but for now I don’t have time to revise my design, so a drawer it is.

—Graham