Cocoa Bindings: initialization order & temporarily suspending bindings
Cocoa Bindings: initialization order & temporarily suspending bindings
- Subject: Cocoa Bindings: initialization order & temporarily suspending bindings
- From: Frank Reiff <email@hidden>
- Date: Mon, 12 Mar 2007 10:45:33 +0100
Dear all,
I have some recurring problems with Cocoa bindings and was wondering
whether any of you guys had found a better solution to these problems.
I have just run into the "the controller looks at my data while I
change it (and isn't quite ready yet) and thus crashes" problem once
again. The other (somewhat related) recurring problem is that "the
sequence in which the bindings are resolved at startup time is
undefined, but occasionally leads to errors".
This is what I'm currently working on:
1) I have an NSOutlineView connected to a NSTreeController
2) the NSTreeController gets its data from a Core Data fetch operation
3) the NSOutlineView is in a window that belongs to the application's
main controller
4) all this stuff is defined in Interface Builder (same nib file)
a) The window belonging to the main controller, it and its outline
view get initialized at the same time as the main controller. A small
problem is that depending on the order of initialization, the
database could potentially not yet exist when the outline view is
starting to resolve its fetch requests in accordance with its bindings.
b) The second problem is that at one stage, I go and delete all the
data that the outline view is currently showing, invalidating its
bindings and thus making it crash (not quite sure why actually). The
window is ordered-out at that stage but the bindings are still active
(?).
Problem a) is easily resolved by making the NSManagedObjectContext to
which it is bound, initialize itself when a reference to it is first
asked for. This guarantees that even if it is the outline view trying
to perform its fetch before the data actually exists, by the time the
method returns the data has been created.
I'm wondering however whether there isn't a better way of defining
the sequence in which the various bindings are initialized. As I said
before, this is a recurring problem. I'm never 100% certain that
there isn't a race condition in there somewhere.. Any ideas on this?
There are a couple of solutions to problem b), but none of them are
particularly appealing to me.. I wonder whether anybody on this list
knows of a way to "suspending bindings" programmatically without
sacrificing the power of being able to specify things from within
Interface Builder.
I'm frankly surprised that the bindings remain active even when the
window containing the view is ordered-out.
The easy way around this would be to put the window into a separate
nib file, load it when the bindings should be active and dispose of
it and its controller when they should be "off". The reason I don't
want to do this is because I do want to use Interface Builder to do
much of the wiring for my application. As far as I'm aware of, the
mechanisms for cross nib-file "wiring" are somewhat limited.
The other solution would be to set and reset the bindings
programatically instead of using interface builder, but as I said I
WANT to use interface builder.
I'd appreciate any suggestions.
Best regards,
Frank
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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