| Subject: | Single line TextEditor field eats enter key when pasted or scanned |
We are using Curses::UI to implement an inventory tracking application
where barcodes are scanned off the inventory. We were encountering
issues where the KEY_ENTER after the barcode was not triggering the
expected events when read into a Curses::UI::TextEntry control. Namely,
after scanning the barcode it was supposed to exit the field, so it was
ready for scanning the next barcode.
We tracked down the cause of this to the code in add_string designed to
handle pasted input. Since the keystrokes generated by scanning a
barcode come in rapid succession, they also trigger this logic. This
logic only allows add-string and newline bindings to fire, regardless of
what keystrokes are used. However, on a single line TextEditor control,
the KEY_ENTER binding is not to newline, but to loose-focus. The
attached patch changes this so that paste will allow anything that binds
to add-string, and any bindings for KEY_ENTER to run.
Note: The workaround in Curses::UI::do_one_event() for pasting large
amounts of text in Solaris can also throw out keystrokes in some cases,
due to feedkey() calling flushkeys(). One of our test programs was
running into this failure case, initially causing us to suspect that as
the source of our problems with barcode scanning, but further analysis
found the above issue. It's probably not a good idea to mysteriously
throw away keyboard input whenever handling event takes long enough that
another key is ready. Either this workaround shouldn't throw out pending
keystrokes, shouldn't throw them out so easily, or it should be
restricted only to those operating systems that require it.