Re: Calling commitEditing text field loses focus

On Dec 21, 2011, at 2:45, Jim Correia wrote:

>=20
> On Dec 20, 2011, at 5:14 AM, Christiaan Hofman wrote:
>=20
>> I have a text field whose value is bound through an =
NSObjectController. Before performing certain actions I call =
-commitEditing on that object controller to make sure I have the current =
value from the text field. What I notice is that if there are any =
uncommitted changes to the text, the text field loses focus due to this =
call. This is certainly not what I want, I just want to commit the edit. =
I also don't recall this to happen in the past, but I am not sure for =
how long this has been going on. Also, the focus is not lost when the =
text had not changed since the last commit. To me this sounds like a =
bug. Can anyone confirm this is a bug, or tell me why this would make =
sense? Or tell me whether there is some kind of setting to change this =
behavior?
>=20
> This how it has worked since NSController was introduced.
>=20

I am pretty sure that long ago when I tested these things out it did =
remain first responder. I distinctly remember being frustrated that it's =
so hard to manually (i.e. without bindings) commit without losing first =
responder the way bindings can do.

> It is less than ideal for a number of reasons. (You need to commit =
editing before saving, but that really shouldn=92t change keyboard =
focus, nor should it change the user=92s selection in many situations.)
>=20

Sorry, can't think of any. If it can push through an edit on every key =
stroke without losing focus, why can't it do that at a point when I ask =
it to?

> If you want to solve this problem specifically, you can manually push =
the value through to the bound object when the field is editing. (Make =
sure you also take care of the value transformer case. Yes, this feels a =
little bit like you=92ve given up most of the advantages of having =
bindings.)
>=20

Not just a little. That basically makes bindings meaningless, it comes =
to manual updating the old way with an extra registration layer added.

> A more general solution would be to write something like adding
>=20
> 	- (void)commitEditingAndRestoreFirstResponderMumbleMumble;
>=20
> to NSController. It=92s a bit tedious to get this implementation =
right, since you have to handle NSTextView, plus field editors for the =
various types of things which might use them, scrolling selection ranges =
back into view, etc. This will take longer, but then you=92ll have the =
problem solved centrally,  once and for all.=20
>=20
> =97Jim

Well, and not to say that all the information I need about editors is =
not publicly available (all I can find is a private ivar _editors). So =
this seems impossible.

Christiaan