Re: Bug in NSArrayController? (immutable instead of mutable dictionaries)
Re: Bug in NSArrayController? (immutable instead of mutable dictionaries)
- Subject: Re: Bug in NSArrayController? (immutable instead of mutable dictionaries)
- From: Uli Zappe <email@hidden>
- Date: Fri, 22 Oct 2004 01:17:58 +0200
Am 22.10.2004 um 00:24 schrieb Uli Zappe:
Am 22.10.2004 um 00:00 schrieb Brent Gulanowski:
Well I just encountered a problem with NSUserDefaultsController where
an array controller was creating immutable instances, but it seemed
to have an unrelated cause. See other messages I posted today.
It would be interesting if these issues were in fact related.
This may well be the case, because in fact my NSArrayController *is*
bound to an NSUserDefaultsController. This is about the only detail of
my setup I omitted (unconsciously), simply because in my case
NSUserDefaultsController seems to be the only way that *does work* to
add mutable dictionaries to NSArrayController. I.e., if I manually
edit a preferences plist so that it already contains an array with
dictionaries, NSUserDefaultsController will put these to
NSArrayController at startup, and these are *mutable*. So
NSUserDefaultsController seemed to be a solution, not a problem. (And
yes, my NSUserDefaultsController *is* set to setSavesImmediately:YES
...)
But I will investigate further in this direction, and tell you what
I'll find.
Brent, you were indeed right, the problem is (at least) with
NSUserDefaultsController.
NSUserDefaultsController has an extremely strange behavior in a
specific case, which I can only think of as bug, not as feature:
If NSUserDefaultsController is bound to an NSArrayController, and it
deals with an *empty* NSDictionary, it will return this NSDictionary to
NSArrayController's content array as *immutable* (no matter what is was
before).
If NSUserDefaultsController deals with an NSDictionary *with content*,
it will return this NSDictionary to NSArrayController's content array
as *mutable* (no matter what is was before).
So here's what happened in my app:
When it is started with a preferences plist that already contains an
NSDictionary with key/value pairs, it will send this dictionary to
NSArrayController as a *mutable* one. Once you've experienced this with
a manually edited test plist, you think that NSUserDefaultsController
behaves the way you want and think your problem lies elsewhere.
However, if you create a new NSDictionary in NSArrayController via
[arrayController insert:self], here is what happens (I debugged this
with a "transform-nothing" custom transformer class that allows me to
set breakpoints for each Bindings related communication):
A *mutable* dictionary will be created by NSArrayController (just as it
should be). This mutable dictionary is send *to*
NSUserDefaultsController. NSUserDefaultsController immediately sends it
*back* to NSArrayController. But since at this point the dictionary is
still empty, it is sent back as an *immutable* one.
So that's the problem. My cure so far is to let my custom transformer
transform each array with immutable dictionaries from
NSUserDefaultsController to an array with mutable dictionaries. Too
inefficient, but it works for now. Now I experience the next strange
problem: NSArrayController does not set its bound controls active when
it receives mutable dictionaries from NSUserDefaultsController, only
when it receives immutable dictionaries (!).
In other words: either you can't change a setting because the
dictionary is immutable, or you can't change it because your control is
inactive. But only if you could change it you could fill your empty
dictionary with a key/value pair that would correct the very cause of
the whole problem in NSUserDefaultsController. Oh well ...
Bye
Uli
________________________________________________________
Uli Zappe, Solmsstraße 5, D-65189 Wiesbaden, Germany
http://www.ritual.org
Fon: +49-700-ULIZAPPE
Fax: +49-700-ZAPPEFAX
________________________________________________________
_______________________________________________
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