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