Re: Issue with -[NSOutlineView autosaveExpandedItems] - SOLVED
Re: Issue with -[NSOutlineView autosaveExpandedItems] - SOLVED
- Subject: Re: Issue with -[NSOutlineView autosaveExpandedItems] - SOLVED
- From: Bill Cheeseman <email@hidden>
- Date: Fri, 11 Jul 2014 16:29:23 -0400
On Jul 11, 2014, at 3:10 PM, Lee Ann Rucker <email@hidden> wrote:
> On Jul 11, 2014, at 5:35 AM, Bill Cheeseman wrote:
>
>> 4. In -awakeFromNib or equivalent, set up the initial expanded/collapsed state of rows in the outline view only once, at first launch on a given computer. Thereafter, leave it to the datasource methods to expand or collapse the outline view at launch based on the autosaved information from a previous run.
>
> Also, don't use the presence or absence of the autosaved prefs item as an indicator of whether you've autoexpanded already, because the pref only saves the array of expanded items and if everything's collapsed, it'll just remove the pref entirely.
Right.
And I've discovered another difficulty, although I think I can handle it. When you add, remove or edit a row that is a child of an expanded parent item, AppKit does not automatically call -outlineView:persistentObjectForItem: to update the autosaved data for the parent. Therefore, when you quit and relaunch the application, the new expanded parent item does not match the old expanded parent item autosaved in user defaults, and -outlineView:itemForPersistentObject: does not find a match. As a result, it returns nil and AppKit collapses the parent item on relaunch. The same thing will happen to an edited row if it was expanded before being edited. I think this issue is inherent in the autosave mechanism as Apple has implemented it.
One way to handle this might be to collapse and expand the affected row programmatically (and invisibly to the user) in order to trigger the datasource methods. Not elegant, but I think it ought to work.
Another way to handle it would be to retrieve the autosaved data when you add, delete or edit an expanded item, add the new data by calling -outlineView:persistentObjectForItem: explicitly, and saving it back to user defaults. I'm half way through doing this now, and it isn't quite as messy as I thought it might be -- but still pretty messy.
A third way to handle it would be to go the autosaved UUID route. The autosaved UUIDs would still be correct after quit and relaunch, and you could retrieve the revised items directly from the datasource in your implementation of the -outlineView:itemForPersistentObject: method. The datasource is always up to date by definition, and you would never encounter a mismatch.
I fear the third approach might be the best. I hate to have to add a UUID to every item in the datasource, but Apple does provide a Cocoa UUID class to make it easy.
Can anybody suggest another approach? It's time for me to quit for the day.
--
Bill Cheeseman - 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