Re: bindings and NSNumberFormatter, enforcing min/max values
Re: bindings and NSNumberFormatter, enforcing min/max values
- Subject: Re: bindings and NSNumberFormatter, enforcing min/max values
- From: Quincey Morris <email@hidden>
- Date: Thu, 16 Sep 2010 15:06:46 -0700
On Sep 16, 2010, at 14:00, Martin Wierschin wrote:
> The quick summary:
Actually, you've covered a lot of ground here, so there are multiple issues implicit in your question.
If you look here:
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CocoaBindings/Concepts/MessageFlow.html#//apple_ref/doc/uid/TP40002149-BCICADHC
you'll see the message flow for bindings. In particular, look at figures 2 and 3.
These diagrams are *very* old (2003, it looks like), and it's not clear if they're accurate any more. So anything deduced from them needs to be verified. However, they don't give you any good news, because they suggest that NSFormatter validation occurs before KVC validation, which isn't what you said you wanted at all.
Aside from that, note that KVC validation doesn't happen when you expect unless you check "validates immediately" in the bindings options. You didn't say whether or not you did this.
For this much of the problem, you're probably better off configuring the text field only for KVC validation, and in your validate<Key> method use a local (created or cached) instance of NSNumberFormatter to convert the text field string value to a number. (AFAIK it's fine for the input value to be a NSString and the output value to be a NSNumber.) You would then capture any errors and incorporate them into the validate<Key> error recovery.
Regarding NSUserDefaults, I don't see anything in the documentation that claims KVC compliance for NSUserDefaults, though I could easily have missed it. Specifically, valueForKey: and setValue:forKey: are not part of NSUserDefaults' publicly documented API. The fact that you can bind to NSUserDefaults suggests that it is KVC compliant but the compliance may only be partial and not include validation. Or, it could support the validateValue:forKey:@"mySpecialValue"error: form of validation without supporting validateMySpecialValue:error:.
TBH, adding a category to NSUserDefaults for this purpose seems kind of hacky, solely for the convenience of binding directly to NSUserDefaults in IB. The alternative is to bind your user interface to properties of (say) your application delegate that provide the validation you want, along with custom getters and setters. These properties would use NSUserDefaults as their "backing store".
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please 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