Re: Automatic population of NSTableView with custom columns at launch time
Re: Automatic population of NSTableView with custom columns at launch time
- Subject: Re: Automatic population of NSTableView with custom columns at launch time
- From: Rick Hoge <email@hidden>
- Date: Mon, 4 Aug 2008 20:42:09 -0400
Also, let me step back for a moment and recommend another approach.
Ideally, if you know all possible permutations of the columns that
the user could ever want, then just add them all at design time in
the nib, and hide (setHidden:YES) the ones you initially want
hidden. Then, add a pop on the header to hide/unhiden individual
columns. That is the ideal way to do this. Granted, I realize all
table columns can't always be known at design time (ie: populating
them from a SQL database, or whatever other logic).
I'd seen mention of the fact that it's better to define 'known'
columns in the nib and use hide/unhide to control display - thanks for
confirming that this is indeed a recommended practice.
Unfortunately I have a combination of known columns (comments, path)
and other stuff that isn't known until launch time (a dictionary is
loaded and could have hundreds of possible pieces of information, of
which a user would typically select some small number).
So I'm stuck supporting at least part of the table structure
programatically.
Rick
corbin
On Aug 4, 2008, at 5:31 PM, Rick Hoge wrote:
Hmmm. Does not seem to be doing it.
Unfortunately, I'm out of ideas; these were mainly off the top of
my head. Without seeing your specific source code, I can't offer
any more suggestions -- it is quite possible something else is
wrong (ie: the identifier isn't set). You probably want to debug
the app to find out why/when your columns are being removed, and
go from there. You can try breaking on the internal tableview
methods, _readPersistentTableColumns and
_writePersistentTableColumns, however, these methods are purely
internal, and may be removed in future releases. In other words,
don't call them or override them.
Thanks anyway -
Of course it never hurts to actually show some code (in case this
might prompt an idea).
This is a test method that adds a column and then sets the autosave
info - I wouldn't actually use it this way, but for testing it does
the steps in the suggested order.
-(IBAction)addTableColumnTest:(id)sender {
// documentTable is an IBOutlet
// autoSaveTableName: is empty in the nib
// Get existing column to copy some formatting info
NSTableColumn *prototypeColumn = [[documentTable tableColumns]
lastObject];
// Create and add the new column
NSTableColumn *newColumn = [[NSTableColumn alloc]
initWithIdentifier:@"comments"]; // app is GC
[[newColumn headerCell] setStringValue:@"Comments"]; // Assign
header text
[[newColumn dataCell] setFont:[[prototypeColumn dataCell]
font]]; // Copy font from existing table column
[newColumn bind:@"value" toObject:documentArrayController
withKeyPath:@"arrangedObjects.comments" options:nil];
[documentTable addTableColumn:newColumn];
// Set the autoSave info
[documentTable setAutosaveTableColumns:YES];
[documentTable setAutosaveName:@"MyDocTableInfo"];
}
You are correct, step #3 shouldn't be required.
If all else fails, you may have to hand-roll a solution where you
don't use the tableview logic, and store out the widths/table
columns yourself.
-corbin
I set autoSaveFileName to nil in the nib file, then do the
following in my code:
1) add the new table columns (addTableColumn: etc.)
2) call setAutosaveName:@"someFile" , call
setAutosaveTableColumns:YES
3) manually change width of table column in UI just in case this
will force an autosave
4) quit app
On next launch, the column I added in step 1 is not there.
Changes to width of columns defined in the nib are preserved
though.
Also is step 3 really needed to force an autosave? Ideally the
added columns would have to be 'remembered' even if the user does
not resize any...
thanks for the suggestions, though!
Rick
On 4-Aug-08, at 7:05 PM, Corbin Dunn wrote:
Are you calling setAutosaveName: yourself? Set it to nil in the
nib. Then, call it yourself. Before you call it, print out all
the table columns to see what they are. Then, load your
tablecolumns that you want (add new ones). Then call
setAutosaveName:<something>. Change the width of a column in
your GUI. This should save out the autosave values. Quit your
app. Restart it. Are the columns restored?
This pattern should work; I use it internally in the open and
save panel.
corbin
On Aug 4, 2008, at 3:36 PM, Rick Hoge wrote:
Thanks for the suggestion -
I tried calling setAutosaveTableColumns: after adding a column
from code, but on next launch it only showed the columns that
are defined in the nib with IB.
Rick
On 4-Aug-08, at 5:39 PM, Corbin Dunn wrote:
If you add all the columns (and remove old ones) before
calling setAutosaveName:, or setAutosaveTableColumns:, then it
should work out okay; it will restore all of the widths,
positions, etc.
corbin
On Aug 4, 2008, at 2:03 PM, Rick Hoge wrote:
I'm working on an application that will allow users to add
columns of descriptive information to an NSTableView - the
available columns are determined at launch time by loading a
dictionary.
In my test app, I can add columns to my table no problem.
Now I am trying to decide on a robust and efficient way to
make sure that the set of columns chosen by the user, and
their geometry, is saved when quitting the app and restored
at the next launch.
I can think of a number of brute force ways to do it - save
an array of column identifiers and/or value bindings to user
preferences, for example.
I know it's possible to autosave column layout information
under Leopard through the framework, and this appears to
work. The autosave info appears to restore the geometry of
columns defined in the nib file, but it won't force a reload
of columns created programatically in the last session. I
suspect that the autosave file may actually contain the
identifiers of all columns displayed as of the last
application quit, and wonder if there is a way, during nib
loading, to access this list so I can initialize the table.
I don't like having the same information stored multiple
places (i.e. my own NSArray in user prefs replicating info
that might be more complete in the NSTableView autosave file)
if I can avoid it, but can't seem to find a way to get at all
the info in this file.
If anyone has some good examples of how this can be done, or
some past experience to share on what works well, I'd be very
grateful.
(43092.6825)
(43092.6825)
(43092.6825)
(43092.6825)
_______________________________________________
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