On Mar 5, 2011, at 06:05, Jonathan Taylor wrote:

> Question 1 - you state "Nothing in any of this will or should have any effect 
> on what's selected in the text field where editing was in progress", but if 
> we are both talking about the same thing then I don't think that's happening 
> for me. The screenshots before and after clicking the "send" button (which 
> triggers a commit) are shown here:
>       www.dur.ac.uk/j.m.taylor/before_send.png
>       www.dur.ac.uk/j.m.taylor/after_send.png
> The text field has lost focus. Would you expect this to happen? Does this 
> suggest that I've slipped up somewhere in how I have wired everything up 
> together or something?

It's quite possible I was wrong on this, but it's kind of hard to know where 
the behavior is coming from. However, it wouldn't be hard to save and restore 
the current selection around your 'commitEditing' invocation, if that's the 
behavior you want. Possibly there's a more direct way I'm not thinking of at 
the moment.

> 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.

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.

_______________________________________________

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