Skip to main content
areohbee
Legend
September 2, 2010
Question

Bug Report: edit_fields not committed when losing focus due to button click.

  • September 2, 2010
  • 1 reply
  • 1293 views

SDK/UI should work the same on Mac as Windows - its nearly impossible to have a plugin on Mac where the user inputs into a text field, then clicks a button to do something with that text, since the text is only committed to the field via Tab. This makes it hard to write plugins in Windows that also work on Mac.

This topic has been closed for replies.

1 reply

johnrellis
Legend
September 2, 2010

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 value is updated) with every keystroke if immediate is true. If immediate is 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.

areohbee
areohbeeAuthor
Legend
September 2, 2010

John,

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.

Rob

johnrellis
Legend
September 2, 2010

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.