Further testing reveals that the binding will, however, work if the
string entered in the "Enabler" column" contains text (letters), but
starts with a number....
Thanks, Sam, but let's not worry about the interpretation of letters
vs. numbers in Tiger. In my real application, when I drive it from a
useful object that returns a NSNumber boolean, it works fine. Let's
keep the focus on the Panther problem.
OK. I just brought up the thing about letters vs. numbers because
just the fact that the binding is interpreting that character mix as
a binding at all could probably be considered a bug, and therefore
it's reasonable to expect that the nature of (probable) bug might
have varied between 10.3 and the present. However, I won't press
that since your real application is using a [NSNumber boolean] for
the "enabled" binding anyway.
It seems to me that a good workaround here would be to make a value
transformer that will come up with a Boolean value that makes sense
out of whatever is entered in the "Enabler" column.
Well, a value transformer returns a pointer of type id, i.e. an
object, which I've already shown does not work. Just to see if maybe
Apple's object would work better than my object, and since it doesn't
require any code, I just recompiled with the NSNegateBoolean
transformer patched in, but that did not help; still the same
exception in Panther.
I just was looking through the list archives from early 2005 (Tiger
was released in April 2005) to see if I could find anything on this
issue, and I found several hits. However, bad news: mmalc posted
February 11, 2005 that this is a known bug on Panther (http://
lists.apple.com/archives/cocoa-dev/2005/Feb/msg00686.html). Maybe
now's a good time to email devbugs and ask them why the bug hasn't
been fixed in over two years...
Sam
_______________________________________________
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
