Thanks Chris, see my last reply to myself. I basically ended up doing
what you are describing at found that this works. Your explanation
makes it a bit clearer as to why though.
Jeff
On Oct 4, 2008, at 1:00 PM, Chris Hanson wrote:
On Oct 3, 2008, at 10:48 PM, Jeff Wilcox wrote:
Not expl
On Oct 4, 2008, at 12:37 PM, Jeff Wilcox wrote:
I played around with what Uli seemed to be hinting at, and indeed it
does seem that NSOutlineView is not particularly thread safe.
It's not a matter of whether a facility "seems" thread-safe.
In Cocoa, the rule is very simple:
If it's not do
On Oct 3, 2008, at 10:48 PM, Jeff Wilcox wrote:
Not explicitly, but maybe. This seems to be taking place when the
content for the NSTreeController is changing (explicitly) in one
thread, causing a reload in the outline view, and in another thread
the NSOutlineView's drawrect is getting ca
I played around with what Uli seemed to be hinting at, and indeed it
does seem that NSOutlineView is not particularly thread safe. If you
update the content for the NSTreeController that is the data source
for the outline view outside of the main thread it blows up as I
described, and does
Not explicitly, but maybe. This seems to be taking place when the
content for the NSTreeController is changing (explicitly) in one
thread, causing a reload in the outline view, and in another thread
the NSOutlineView's drawrect is getting called. I can't say for sure
that this accounts f
On 04.10.2008, at 03:00, Jeff Wilcox wrote:
I seemed to be able to make this go away by subclassing the outline
view and locking it down before starting a reload or evaluating the
number of rows (found mostly by lots or trial and error) with the
following:
Wait, you're not calling number
I am suddenly having a load of issues with NSOutline view failing with
the following assertion:
Assertion failure in -[NSOutlineView
_expandItemEntry:expandChildren:startLevel:](), /SourceCache/AppKit/
AppKit-949.35/TableView.subproj/NSOutlineView.m:1003
I seemed to be able to make this go
