There are several ways to implement numeric input via the Nextion HMI, but no standard way to enter or modify a txt component. Patrick has shown us a clever implementation to do it, but it might be too complicated to use it in an everyday application of the Nextion.
I would like to have a 'key' component, that mostly acts like a button, but has also a 'target' object id and an alternate 'shift' txt value. Plus a 'kbdmode' system variable to toggle between txt and shift values being applied.
Here is an example:
given a text component t0, three key components k0, k1 and k2. t0.txt is assumed empty, all k0, k1 and k2 components' target values are t0. k0.txt='s', k0.shift='S', k1.txt="o", k1.shift="O". k2.txt=CHR(8) (Backspace), k2.shift=CHR(12) (Form feed).
Another button b0 could be used to toggle the kbdmode system variable between 0 and 1.
Now a consecutive tap on k0, k1 and k0 again yields "sos" in t0.txt.
Next, a b0 tap moves to shifted mode.
Then taps on k2, k0, k1, k0 in order yields "SOS" in t0.txt.
With these few additions we could create specialized keyboards easily, with as much (or few) keys as are required, are flexible to use any input characters we like.
This will be no full editor with cursor keys etc., but may serve most of the applications I imagine on the Nextion.
There is a thread in the Gallery that is Keyboard Examples.
The fact of the matter is that keyboards are hard work, nothing more.
I have implemented numeric keypads for passcode entry
I have implemented a full scrolling 32-126 ascii type writer.
Itead has even put a (encrypted) keyboard in their blog (a * is not really encrypted, but it was a keyboard)
I know that I have gone over this often - we are getting to the point that there be so little firmware room remaining, to get new features, what is it that we will be willing ditch? Should that ditch feature be ditched if the new feature is something that could have been programmed, or is it better to have both - one takes a bit more effort?
A document error occurred, and you feel what a removed feature could be like with "dp gone missing". So it would be that feeling when something gets swapped out ... mostly for no other reason than somebody didn't want to invest the work to make it happen for themselves. We have to wonder why our feature gets axed for something that was a couple of hours of work - but doable for both to still be had.
Then that travels further down the road.
Is every complex application to be made available for free, and what about the editors? I spent the time and made a Nextion side eeprom editor .. and yeah it works, but how then is this application different from the keyboard application? How do other multi-day projects to be handled? Or is it each programmer needs to put in their effort?
In version v0.42, there will be (should still be) the ability to import and export pages. This will indeed make it better to take a chunk of work and make it portable in your application. Such as a keyboard. The example I have seen so far is the basic A to Z touch tone phone keypad for entry and a cell phone style keyboard. I do not yet know if these are just examples, or if these are going to be included in the v0.42 package. However ...
The amount of work I speak about to implement a keyboard is still there. Functionally, these actually work. Graphically, oh there is so much work that needs to be done to customize the same keyboard so that it looks good enough to be in a final product. There seems to be no way of getting around this time investment.
Not everything in a keyboard has been implemented
But awesome start in v0.42.