Re: Subclassing NSOutlineView causes failure of window to become main or key
Re: Subclassing NSOutlineView causes failure of window to become main or key
- Subject: Re: Subclassing NSOutlineView causes failure of window to become main or key
- From: Dennis Hartigan-O'Connor <email@hidden>
- Date: Sun, 02 Mar 2008 17:15:33 -0800
Thanks, John,
In all these cases, I can use NSLog to print to the Run Log--but no
errors are printed there by the system.
In all cases, the Console Log is blank.
In cases where the window doesn't become main or key, if I attach the
debugger I find that the thread list looks exactly the SAME as when the
window does become main or key:
#0 0x9000b348 in mach_msg_trap
#1 0x9000b29c in mach_msg
#2 0x907ddad8 in __CFRunLoopRun
#3 0x907dd3dc in CFRunLoopRunSpecific
#4 0x9329bb20 in RunCurrentEventLoopInMode
#5 0x9329b1b4 in ReceiveNextEventCommon
#6 0x9329b020 in BlockUntilNextEventMatchingListInMode
#7 0x937a1bc4 in _DPSNextEvent
#8 0x937a1888 in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
#9 0x9379ddcc in -[NSApplication run]
#10 0x9388e974 in NSApplicationMain
#11 0x00011fa8 in main at main.m:13
I don't fully understand this information but I'm assuming it represents
the normal event loop, since it looks exactly the same as when the
application runs perfectly.
John Stiles wrote:
Is anything printed to the Run Log or Console?
Dennis Hartigan-O'Connor wrote:
I'm trying to use a subclass of NSOutlineView to allow merged columns,
so that some cells can run over their bounds, using methods I read
about at:
http://www.mactech.com/articles/mactech/Vol.18/18.11/1811TableTechniques/index.html
I have four instances of my custom subclass organized in an NSTabView.
I have the rather strange problem that my program runs, without
crashing, and displays the tables with merged columns just as I
desire. However, the main window fails to become either main or key,
so no input is accepted from the user.
I've done a lot of work trying to diagnose this problem and I have two
key results:
1) Using NSOutlineViews, everything works fine. In particular, by
using windowDidBecomeKey and windowDidBecomeMain methods, I find that
the main window becomes both key and main, and accepts user input, and
everything works fine.
2) In an attempt to diagnose this problem, I created an "empty"
subclass of NSOutlineView, which behaves exactly the same as
NSOutlineView, because no methods are overwritten. Here's the really
strange part. If I set ONE OR THREE of my four NSOutlineViews to the
custom "empty class", everything works fine--the application runs just
as if I were using four NSOutlineViews. windowDidBecomeKey and
windowDidBecomeMain are both called. If I set TWO OR FOUR of my four
NSOutlineViews to the custom "empty class", then the main window fails
to become either main or key and no input is accepted.
windowDidBecomeKey and windowDidBecomeMain aren't called.
Believe it or not, I've actually been able to make everything work by
adding a FIFTH instance of my custom subclass (providing merged
columns) to the window and setting it to be hidden. When I do this,
my whole application works great, with merged columns.
In short, my custom subclasses are somehow preventing my main window
from become key or main--but only when I use an even number of
instances of such subclasses. When I use 1, 3, or 5 instances,
everything is fine.
I am running Xcode 2.4.1 on OS 10.4. I have already set the Nib file
format to "Pre-10.2", because I've heard that newer formats can cause
problems with custom subclasses.
I know that this is a strange story...I hope that there is a simple
explanation that will make me look stupid. My application is working,
but I just can't stand having to use such a blatant kludge as a hidden
instance of my custom subclass.
_______________________________________________
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
_______________________________________________
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