Re: NSTableView and NSArrayController: modifying values does not change sort order
Re: NSTableView and NSArrayController: modifying values does not change sort order
- Subject: Re: NSTableView and NSArrayController: modifying values does not change sort order
- From: Frederick Cheung <email@hidden>
- Date: Fri, 17 Sep 2004 16:02:55 +0200
On 17 Sep 2004, at 14:55, M. Uli Kusterer wrote:
At 17:37 Uhr -0700 16.09.2004, Matt Neuburg wrote:
On Thu, 16 Sep 2004 21:15:11 +0200, Frederick Cheung
<email@hidden> said:
If I click in a column header then the tableview sorts the data as it
should, but if I modify one of the values (via the text fields or
directly editing the table) the data isn't resorted.
You always know (or can arrange to know) when the content changes, so
if you
want to resort when it does, you can. m.
The problem in my case was getting to know when content changes. Since
the content is an NSDictionary I don't know of a convenient way to trap
all changes, so I ended up subclassing the array controller and
overriding observeValueForKeyPath:ofObject:change:context. If the
changed keypath corresponds to one of the controller's sort descriptors
I ask the array controller to sort itself.
That works fine, but for fun and because most of this is new to me,I
also tried adding myself as an observer via
addObserver:toObjectsAtIndexes... which worked fine but in order for
this to work properly I also need to know when objects are added or
removed from the array and I couldn't get that to work. I would have
thought that adding myself as an observer of the array controller for
the key path arrangedObjects would have worked but my observer method
was never called. No biggie, this felt a little too messy anyway,
One suggestion: Make it slightly delayed, using a Timer, so if your
users want to edit three items in a row they don't have to scroll back
each time. It should also *not* re-sort at all while an item is being
edited.
So, in my ideal world:
-> User edits entry
-> Timer is installed to fire in 2 seconds and re-sort the list
-> User starts editing another entry
-> Timer is paused
-> User finishes editing entry
-> Timer is un-paused and reset to fire in 2 seconds and re-sort the
list
-> 2 seconds pass without the user editing or causing a re-sort by
clicking the headers
-> The list is re-sorted
IMHO this is better than what the Finder does, where you have items
that jump away because of re-sorting just when you want to click one.
This is indeed much better from the usability point of view, although
it does entail figuring out when the user is editing an entry, which I
am currently blissfuly ignorant of (I suppose one would do this via the
textfields' delegates or the appropriate notification)
Fred
_______________________________________________
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