Re: Accepting current edited text field contents
Re: Accepting current edited text field contents
- Subject: Re: Accepting current edited text field contents
- From: Jonathan Taylor <email@hidden>
- Date: Sat, 05 Mar 2011 19:03:10 +0000
>> Question 2 - the method you have described seems to be very much tied to a single NSObjectController for the entire window, and indeed IB just seems to offer the option to bind to "Object Controller", without specifying "which one". In that case, is there any way of achieving neat group-based behaviour for the following window?
>> www.dur.ac.uk/j.m.taylor/grouped.png
>> Here there are two separate categories of editable fields. If "send" is clicked then it is important that any edits to the stage command field are committed, but I think it would make more sense if ongoing edits to the "stage limits" fields are NOT committed if "send" is clicked (they are completely irrelevant). n.b. the window does not close when "send" is clicked. Is there any way of achieving this?
>
> What does "not committed" mean to the user? Nothing, I think. The whole purpose of the NSEditor protocol is to *eliminate* the distinction in the user's mind -- to ensure that the One True value of each text field is the value the user sees.
I think I see what you're saying, but my motivation was based on a similar philosophy I think: if the user has accidentally typed something non-numerical into the "lower x" field, I was thinking they would be rather surprised if clicking on "send" caused the GUI to suddenly start complaining about "lower x" not being valid and refusing to send raw stage commands until that unrelated issue was rectified.
> If the text field changes are individually undoable, the whole question is a bit more subtle. If you have uncommitted changes in, say, the Lower X field, then undo actually says Undo Typing (and individual text field edits are undoable). After a commit of the text field, undo would say Undo Lower X, and if this happened because you clicked Send, then undo would (presumably) say Undo Send, and the *previous* undo action would be Undo Lower X. Whatever functionality you want, you're going to have to code carefully to implement.
Fortunately I'm not even going to consider Undo in this situation. These commands have actual real-world consequences in terms of motor movement, so the GUI-based concept of Undo does not really apply._______________________________________________
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