Re: Show/Hide columns in NSTableView?
Re: Show/Hide columns in NSTableView?
- Subject: Re: Show/Hide columns in NSTableView?
- From: Matt Neuburg <email@hidden>
- Date: Thu, 27 Jul 2006 08:20:40 -0700
- Thread-topic: Show/Hide columns in NSTableView?
On Thu, 27 Jul 2006 10:37:59 +0200, Fredrik Olsson
<email@hidden> said:
>NSTableView only provide methods add and remove columns, not setting
>their visibility, not do NSTableColumn have any documented method for
>controling visibility.
>
>Almighty Google do not provide much help either, 'NSTableView "hide
>column"', yields only five results.
>One is interesting, a post to this list from 2002, stating that I could
>retain the column, remove it and add it later. But then I must remember
>it's position if the user have moved it and such. I think of this as a
>too common problem (Many applications have table views with configurable
>columns) not to have a more elegant solution.
>
>Is there a more elegant solution to letting the user (And
>programatically) toggle columns on and off? Retaining as much
>information as possible?
No. You just do it, and remembering what needs remembering is up to you. For
example, my app (NotLight) has three optional columns in the results table.
(Two in the currently released version - I just added one more yesterday.)
If the user asks to remove one of these optional columns, I remove it. If
the user asks to insert a column, I insert it (by creating it in code and
moving it into place in the table). When the user resizes a column, I
remember what columns are present and what all their sizes are. I remember
this information in the user defaults, so we can restore the status quo the
next time the app starts up. When the user removes or inserts a column, if I
am remembering a setting for the sizes of that set of columns, I use it;
otherwise I just use some reasonable values. To make things simpler for
myself, I do not permit reordering of the columns (though knowing now what I
know, I could probably add this feature easily enough at this point). None
of this is difficult to do, though at the beginning I did have some issues
fighting against the auto-save mechanism (signs of that struggle are
preserved for posterity in the archives). It really isn't very much code,
either. I agree, though, that it would be nice to have Cocoa help more with
this. IIRC, Corbin Dunn has signalled that in the future this might happen.
m.
--
matt neuburg, phd = email@hidden, <http://www.tidbits.com/matt/>
A fool + a tool + an autorelease pool = cool!
AppleScript: the Definitive Guide - Second Edition!
<http://www.amazon.com/gp/product/0596102119>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden