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: Fri, 5 May 2006 21:25:46 -0700
On 5 May 2006, at 2:28 PM, James Bucanek wrote:
Brian Stern wrote on Friday, May 5, 2006:
At 8:25 AM -0700 5/5/06, James Bucanek wrote:
However, one of the places that the name is editable is in a
modal sheet
where the user can edit several properties then click on OK or
Cancel. If
I bind that text field to the defaults controller, edits to the
name are
commmited immediately. I don't want the changes to the field to be
propogated until the user clicks the Save button, and ignored if
they
click Cancel.
The way I've dealt with this is to:
Save the value of the field before showing the sheet
If the user clicks Save do nothing (it's already saved)
If the user clicks Cancel: restore the value in the user defaults
controller with the saved value.
In this particular (possible rare) instance I can't do that. The
value in the model is used by background tasks that could
potentially start at any time. If I allowed the modal dialog to
store half-edited or invalid values in the model, one of those
background processes could start with invalid data.
You might imagine doing it the other way around but I don't know
how to
intercept the editing that is committed through the bindings.
I guess this is what I was trying to do. So far I don't know of any
way of doing that.
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. 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.
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.
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.
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.
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.
_______________________________________________
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