• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: bindings and NSNumberFormatter, enforcing min/max values
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bindings and NSNumberFormatter, enforcing min/max values


  • Subject: Re: bindings and NSNumberFormatter, enforcing min/max values
  • From: Martin Wierschin <email@hidden>
  • Date: Thu, 16 Sep 2010 15:59:42 -0700

Hi Quincey,

Thank you very much for taking the time to reply and help me out.

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.

I do have the "validates immediately" option checkmarked in IB.

It's actually okay if formatter validation is triggered before the KVC validation, so long as the latter happens at some point. I can simply have no min/max set for my formatter, so that validation always passes.

Unfortunately this doesn't help with my ultimate goal of validating values bound to NSUserDefaults.

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.

Fair enough.

TBH, adding a category to NSUserDefaults for this purpose seems kind of hacky, solely for the convenience of binding directly to NSUserDefaults in IB.

I don't feel like having categories on NSUserDefaults to add specific validator methods is a hack. It seems like a great way to enforce the constraint in the model (ie: the defaults are the model). If NSUserDefaults wasn't designed for this, then sure, it's not a good idea. But considering that Apple provides a shared controller specifically for binding to the user defaults in IB, I wish they had thought of validation too.


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".

That sounds like more glue code than with manual target/action/update code.


I think at this point my best option will be to subclass NSNumberFormatter and override the value extraction methods so that numbers outside the min/max are silently clipped before Apple has a chance to see them.

Thanks again for your help!

Best,
~Martin

_______________________________________________

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


References: 
 >bindings and NSNumberFormatter, enforcing min/max values (From: Martin Wierschin <email@hidden>)
 >Re: bindings and NSNumberFormatter, enforcing min/max values (From: Quincey Morris <email@hidden>)

  • Prev by Date: Re: CGContextSelectFont spinlock
  • Next by Date: Why is NSPopUp broken in drop-down mode?
  • Previous by thread: Re: bindings and NSNumberFormatter, enforcing min/max values
  • Next by thread: Re: bindings and NSNumberFormatter, enforcing min/max values
  • Index(es):
    • Date
    • Thread