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: mmalcolm crawford <email@hidden>
- Date: Sat, 6 May 2006 01:54:53 -0700
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?
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'.
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.
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:>
mmalc
_______________________________________________
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