The question sounds simple but it is not in case the NSOutlineView has an outline table column. In this case removeTableColumn: does nothing but says that nil should be sent to setOutlineTableColumn:.
BUT the docs say that a parameter of nil for setOutlineTableColumn: is being ignored and this is unfortunately also true. 😕
So, how do I get rid of all columns?
I don't understand the question. Under what circumstances would it be useful to get rid of all columns?
>> in case the NSOutlineView has an outline table column
This is not a "case" in any reasonable sense. The defining feature of an outline view is that is has an outline column.
What's the exact error message you got from trying to use "removeTableColumn:" on the outline column? I wouldn't be surprised (as an unrelated issue) if the error message is incorrect for historical reasons.
For example it is useful if you like to build up the view from scratch (with different number of columns and different data in the columns). So, just remove all columns and start again. This is mostly easier than doing all the modifications to existing columns and add and remove individual columns.
Here is the error message: *** NSOutlineView cannot remove outlineTableColumn with removeTableColumn:. Use setOutlineTableColumn: instead.
>> just remove all columns and start again
For that scenario, you can easily work around the issue by adding a new outline table column first, then delete all the other columns.
FWIW, it's not obvious that there's a really good reason for this restriction, at the API level, so it probably reflects some implemention detail. It would be reasonable to file a bug report to allow deletion of the outline column, but I wouldn't hold my breath that it would be done any time soon. 🙂
It would also be reasonable to file a bug report against the message.
Hi,
I have already filed a bug report. It is in the meantime more than 5 years old, I believe.😟
The issue with the workaround you mentioned is that it triggers another bug😠 (I already had the same idea). Therefore, I was looking for a second workaround. Unfortunately, I cannot provide a simple example but the bug is similar to that:
Assign the outline view to a scroll view (setDocumentView:) . Do not add any columns but remove it again and assign an new outline view. Change the size of the window containing the scroll view leads to a crash where the outline view is interpreted as a class for glyphs.
The reason seems to be that the outline view is not correctly (immediately) released when assigning a new document view to the scroll view (retain count is increased by two when assigning the outline view but is only decreased by one when another document view is assigned). Under certain conditions this will crash.
Hmm, interesting.
In the scenario you describe, I think I'd be inclined to try replacing the entire sub-hierarchy from the scroll view. Specifically, I'd put a starter outline view (along with its scroll view) in a nib, and load the nib each time I wanted a fresh start on the outline view.
(I'm not a big fan of creating UI elements programmatically, but you could create this sub-hierachy in code, too.)
The other choice would be to never remove the outline column, but just reconfigure it for your new column layout.
