Sigh, now I understand the meaning of the documentation:
Creates an edit-field control, which accepts keyboard input when it has the input focus. User input is committed (that is, the
valueis updated) with every keystroke if
immediateis true. If
immediateis false, input is committed when the control loses focus. There is a platform difference in the focus behavior:
- In Windows, the control loses focus when the user clicks outside it.
- In Mac OS, it loses focus when the user uses Tab to shift the focus, not when the user clicks outside the control.
Since it's documented behavior, I would call this a "serious design flaw" rather than "bug". As you point out, you can't expect users to type tab after entering text!
Have you tried setting the "immediate" property? The documentation implies that user input is committed immediately.
I think I can get it to work by using "immediate" and deep sixing the "property observer", which gets called every keystroke in immediate mode.
Thanks for the tip.
If you're just worried about the performance cost of invoking the observer on every keystroke, you may not need to worry about it. I have a plugin that does a huge amount of work on very keystroke (linear search through a list of 10,000 words), and it's reasonably zippy.
Not so much worried about performance, I just need to redesign - observer is presently doing the action, since it was only called when the value was finally being commited. If its called every keystroke, it can't be used for knowing when the user has finished editing. Now that I think about it, it begs the question - how do you know when the user has tabbed out of a field on Mac, if you can't use the observer.
So what's the answer? ;-}
Now that I think about it, it begs the question - how do you know when the user has tabbed out of a field on Mac, if you can't use the observer.
You "know" when the user has finished entering input when she clicks on another button or control. So I think the general principal is to set the "immediate" property and then design the UI such that a click on another button or control triggers the desired action, at which point the plugin grabs the value of the edit_field. I think?
That is essentially what I've done now - seems to be working.
PS - I tried using a script to output a tab character on the mac to commit the field but for some reason its still not commited (even though the tab is working - i.e. going to the next field). I guess if it were that simple Adobe would not have let the problem persist in the first place maybe.