I’ve seem that Xojo removed keystrokes events from web, but the detection of a small set of the special keys like ESC, TAB and ENTER are crucial to many, many systems. Specially those tied to hardware that emits such keystrokes like barcode readers that would not change such behavior.
I have a desktop app where a “special field” that responds differently if ended by TAB or ENTER. It’s how such market is used to. ENTER skips some extra conference steps and accepts the value (if valid) directly, clears the field, and start the entry again. TAB shows data about it and focus on a button that does what ENTER does. ESC clears the field. Such code can be read by scanner that sends its value to the data field and finishes it with a CR code (0x0D, Enter). I would say that detecting such thing is crucial to convert such system (and many others similar to this one) to web.
Can we handle this currently, in native Xojo, without workarounds like injecting proprietary JavaScript subject to a future mess; or I must create a feature request asking a way to solve such basic problem?
Sad news for me, Tim. We know you did a great job hacking the system to fix it, but I wished that we had a solution not touching the guts of the beast to avoid a future break.
Now I will have to think my options:
Use TP_WebKit
Write my own workaround (trying to be lighter as possible)
Use another tool for this job
Try to redesign the UX in some unusual way that clients could refuse it.