I have a few PDA/terminal devices with integrated barcode scanners and hardware keys for typing numbers.
I have tried all of your .aix files but the software keyboard still manages to pop up for a couple of milliseconds, which makes my app janky when typing with physical keyboard keys.
Meanwhile I tested the devices in web browsers with text boxes that are programmed to disable the keyboard and there are no hiccups. What exactly could Google Chrome and other web browsers be doing differently to ensure that a software keyboard NEVER shows up, not even 1% of the time?
So basically to sum things up I'm trying to create App Inventor "clones" of web apps that I already built for my business. (Point of Sale, inventory counting, etc.)
How the web apps work is that I just have the PAGE listen for keypresses, NO textbox at all. From there I have a function that determines what key was pressed based on the keyCode, and converts that keyCode into a string (like a product ID/barcode number). If I want to focus on a text box that takes input like text where I need the keyboard, (email, name, etc.) I just prematurely end the pagewide keypress listener when a typeable textbox is focused.
Is there an AI extension that someone has made that would allow me to get keypresses on the screen rather than in a textbox, and convert keyCodes to values? Just curious. The most recent AIX provided by TIMAI2 seems to work actually.
My apologies, I'll try to elaborate as best as I can.
Instead of listening for input in a textbox, you listen for any keyboard input when the page, or screen in AI's case, is open.
Basically when my web app initializes, there's no text box in focus. There's no text box at all. But if I press a key on my physical keyboard (on my PDA or even my laptop), or when my PDA scans a barcode (the barcode scanner acts a physical keyboard) I can get the value of each key pressed one by one, save it to a buffer, and submit it to the server/app to get details about the item scanned/keyed.
Imagine if AI had a block for screens like "Screen1.whenKeyPressed".
The reason I do this in the web app is because of the fact that since there is no text box, the software keyboard is never triggered. Of course there are ways to use textboxes in web browsers with no software keyboard popping up, but the method I explained ENSURES that there is no software keyboard popping up EVER because there's no text box for it to pop up for in the first place. Because of this, my web app can work across a range of browsers, even browsers that are 4ish years old. Older browsers don't support blocking the software keyboard on textboxes, so that is why this polyfill works great.
But if as you say, the extension I provided prevents the soft keyboard from showing, having a text box is the easiest way to solicit and capture the input, also providing the user with visual feedback of what has been input?
