Re: How to control the commit of text edit field with binding?
Re: How to control the commit of text edit field with binding?
- Subject: Re: How to control the commit of text edit field with binding?
- From: Dustin Voss <email@hidden>
- Date: Sat, 6 May 2006 04:29:01 -0700
On 6 May 2006, at 1:54 AM, mmalcolm crawford wrote:
On May 5, 2006, at 9:25 PM, Dustin Voss wrote:
On 5 May 2006, at 2:28 PM, James Bucanek wrote:
Are you settingAppliesImmediately to NO? You might be able to
use the
various methods that are enabled with that setting to control this.
Ah ha! I think this might be my solution -- at least for
NSUserDefaultsController values. It would seem that I can turn
off propogation of model changes to the actual NSUserDefaults
object, then manually save: or revert: those changes at the end
of the dialog.
<http://developer.apple.com/documentation/Cocoa/Conceptual/
CocoaBindings/Concepts/NSUserDefaultsController.html#//apple_ref/
doc/uid/TP40001092-165558>
Sadly, it doesn't appear that this metaphor applies to other
NSController classes.
I handled a situation vaguely like this by treating the window
controller as a model object. Basically, the window controller
copies the original settings into local variables, the user sets
everything he likes, and the window only manually adjusts the real
settings only when the user presses OK.
It's not clear why you would use separate instance variables. If
you're using bindings, you're using KVC, so in the "worst case" it
would be easier to use a dictionary. The problem with that
approach is that if your custom class implements any validation
methods, they won't be applied (at least not before all the values
are committed simultaneously)...
The NIB would have an NSObjectController whose content object is
the window controller itself, and all the controls would bind to
the settings kept by the window controller through that
NSObjectController.
... why not just let the object controller manage its own object --
a dictionary, or a temporary instance of the correct class?
Well, you mention validation. And, personally, I prefer keeping the
number of strings floating around -- in this case dictionary keys --
to a minimum. I think I'm trying to swim against the tide on that,
though. Finally, there might be a need to use older outlet-based
tricks, which would be hard to do if the outlets are dictionary
values. :)
The only trick is that you have to use the NSObjectController's
content outlet to connect it to File's Owner (assuming the window
controller owns the NIB) instead of NSObjectController's
contentObject binding. This is because when IB binds a binding to
to File's Owner, it assumes that you really want to bind the
binding to a property of the Owner, not the Owner itself.
No, you could use bindings is you use the key-path 'self'.
Ah, I was not aware of this key-path. Where is it documented?
But in your case, involving defaults, you probably want to keep
the settings in a dictionary anyway to map setting to value. So
just make the dictionary a property of the window controller, and
bind NSObjectController's contentObject binding to that
dictionary. Then each control's content can be bound to the actual
user default key through the NSObjectController.
No, if you're using NSUserDefaultsController, use the API it provides.
What I am suggesting is an alternative to NSUserDefaultsController.
Since NSObjectController is taking on the controller role here, there
is no reason not to use NSUserDefaults.
Of course, it looks like James B. has already implemented an
NSUserDefaultsController-style solution... but my suggestion is a way
for other OK/Cancel-type dialogs to use bindings.
You still have to copy defaults from NSUserDefaults to your
dictionary, and vice versa, but that is easy. Just make an array
of the user default keys of interest and loop through that to set
your dictionary, and to copy the other way, loop through the
dictionary's keys to set the corresponding NSUserDefaults entry.
No, if you do ever need to update an object using a dictionary, use
the API key-value coding provides:
<http://developer.apple.com/documentation/Cocoa/Reference/
Foundation/ObjC_classic/Protocols/NSKeyValueCoding.html#//apple_ref/
occ/instm/NSObject/setValuesForKeysWithDictionary:>
I don't believe that NSUserDefaults is KVC compliant. I don't see
that it implements valueForKey: or setValue:forKey:. If it is KVC-
compliant, the API you linked would obviously be better.
_______________________________________________
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