Hello, I just posted a feature request for improved text fields in Win32.
Go and vote for it: http://feedback.coronalabs.com/forums/188732-corona-feature-requests-feedback/suggestions/36137746-proper-text-field-for-win32
This is what I miss the most from Win32 Corona.
Thanks!
Hi @jaime9. Obviouslly win32 based apps have pretty flexible text input fields, but those text fields are not designed to work with OpenGL. It took some pretty creative programming techniques to get what we have. I’ll let engineering know about this request, but I don’t know how much we can do given the complexity involved.
Rob
I absolutely understand, Rob. I *think* a transparent background and removing the frame would be enough so they are totally usable.
Alternatively a win32 function to translate the native keycode to ASCII / Unicode would help a lot in making a custom, lua based solution.
Thank you, as usual!
I actually made such a function for a client some time ago where if the user clicked on a text field, which was really just a simple image rect in this case, the app started to listen for event.keyNames. As the user inputted keys, I simply added them to the string and updated the text display object.
In addition to that, I only needed to add a few other tricks like, if there is already text on the “text field” when the user clicks it, then I used event.x and event.y to calculate where on the string the user clicked and made that the active text input location. Additionally, I needed to write what happens when the user presses enter, delete, backspace, arrow keys, etc.
I have one such thing “half cooked”, too… but then I realized (and remembered from old times) that the mapping key - character is not trivial, there are tons of different keyboards out there. That’s why I asked, to enable the DIY option, to have a key code to ASCII / Unicode.
Absolutely. My solution isn’t universal by any means. My code works as I knew that my client would only use it with Nordic keyboards.
Edit: Oh, right. You can get some degree of ASCII codes by using event.nativeKeyKode. I’m using the phrase “some degree”, as 1 key returns 49, 2 returns 50, etc. but the keys for a, b, c, etc. return 65, 66 and 67, etc. which belong to A, B, C, etc. but you can get around them.
Hi @jaime9. Obviouslly win32 based apps have pretty flexible text input fields, but those text fields are not designed to work with OpenGL. It took some pretty creative programming techniques to get what we have. I’ll let engineering know about this request, but I don’t know how much we can do given the complexity involved.
Rob
I absolutely understand, Rob. I *think* a transparent background and removing the frame would be enough so they are totally usable.
Alternatively a win32 function to translate the native keycode to ASCII / Unicode would help a lot in making a custom, lua based solution.
Thank you, as usual!
I actually made such a function for a client some time ago where if the user clicked on a text field, which was really just a simple image rect in this case, the app started to listen for event.keyNames. As the user inputted keys, I simply added them to the string and updated the text display object.
In addition to that, I only needed to add a few other tricks like, if there is already text on the “text field” when the user clicks it, then I used event.x and event.y to calculate where on the string the user clicked and made that the active text input location. Additionally, I needed to write what happens when the user presses enter, delete, backspace, arrow keys, etc.
I have one such thing “half cooked”, too… but then I realized (and remembered from old times) that the mapping key - character is not trivial, there are tons of different keyboards out there. That’s why I asked, to enable the DIY option, to have a key code to ASCII / Unicode.
Absolutely. My solution isn’t universal by any means. My code works as I knew that my client would only use it with Nordic keyboards.
Edit: Oh, right. You can get some degree of ASCII codes by using event.nativeKeyKode. I’m using the phrase “some degree”, as 1 key returns 49, 2 returns 50, etc. but the keys for a, b, c, etc. return 65, 66 and 67, etc. which belong to A, B, C, etc. but you can get around them.