Re: Tracking an NSArrayController's selection
Re: Tracking an NSArrayController's selection
- Subject: Re: Tracking an NSArrayController's selection
- From: Camillo Lugaresi <email@hidden>
- Date: Thu, 29 Dec 2005 02:38:38 +0100
On 28/dic/05, at 13:00, Camillo Lugaresi wrote:
If it helps visualize the problem, here is a log of the messages
received by first-tier objects when the second-tier selection changes:
set <currentFirstTierObject> selected child: 0 -> 3
get <currentFirstTierObject> selected child: 3
and when the first-tier selection changes:
set <newlySelectedFirstTierObject> selected child: 5 -> 0
get <newlySelectedFirstTierObject> selected child: 0
get <newlySelectedFirstTierObject> selected child: 0
I guess I could simply set a delegate on the NSTableViews and track
the selection using tableViewSelectionDidChange, but since the rest
of the interface is completely based on bindings, that would look
like an ugly asymmetry. Any suggestions on how to implement this
properly using bindings?
Update: I almost got it to work by disabling _both_ the "preserve
selection" and "avoid empty selection" attributes of the second-tier
controller. This way, the selection is accurately saved and restored
sometimes, but it is reset to 0 when switching from an object which
has less children than the selected-child index of the newly selected
object. In that case, I get this series of messages:
1) set <selectedParent> selected child: 4 -> null (ignored)
2) get <selectedParent> selected child: 4
3) set <selectedParent> selected child: 4 -> 0
4) get <selectedParent> selected child: 0
Commentary:
1) with "avoid empty selection" active, this tries to select the
first child; when it's off, at least I can look for an empty range
and ignore the request;
2) "which child was select, again?" 4
3) "but that's more children than you have!" (NSArrayController is
still thinking of the previously selected parent, which had less
children, even though it's sending these bogus messages to the new
selected parent) "select the first one instead"
4) "did you really set it to 0? I'm watching you!"
If, instead, the previously selected parent had at least 5 items, I
get this:
1) set <selectedParent> selected child: 4 -> null (ignored)
2) get <selectedParent> selected child: 4
2) get <selectedParent> selected child: 4
It looks like NSArrayController gets a bit confused while its content
(which is bound to parentArrayController.selection.children) is
changing. To work around this I would need to ignore messages sent
during the change (by temporarily unbinding or setting a flag or
whatever), but the key-value observing protocol is not flexible
enough to do it.
It looks like I will have to use an old-style delegate on the
NSTableViews after all... or is there another solution? I find it
hard to believe that Cocoa Bindings can't handle such requirements. I
wouldn't describe the interface I'm implementing as particularly
unusual or advanced.
Camillo
_______________________________________________
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