>> 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 (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to