I don’t think there is one right answer. I will look at native apps to see if I can find examples to relate. In my opinion (which is often wrong! 
users tend to start tapping around the second they are done entering info and discover there is no Done button. You could perhaps visually wiggle the next editField once the current one with a number keyboard has valid data in it.
Lets see what others might be doing in this situation.
Thanks for the suggestions.
I’ll create a thread for this to stop derailing this one.
No worries. Certainly a relevant question IMHO. Give the beta a try and see how it works in your use case. Thanks
Thanks guys,
PMs sent with the files. Looking forward to your feedback
Atanas
Would love to give it a go on the business app I am working on and provide some testing rletx
Thanks Rich, PM sent. I am over some attachment limit with PMs, so please send me your email
atanas, thanks for letting me test your widgets.newEditField. I’ve run the test app and the first thing I noticed is the text doesn’t show up until I’ve finished typing. Does this only happen in the simulator? I haven’t test it on the device yet. Here’s a video capture of what’s happening.
Hi hectots, This problem is due to an incorrect font scaling in the simulator. In the simulator, the font scaling can be off because i do not have a way to retrieve the simulator Zoom factor from Corona. For practical purposes, any devices that have a height of more than 1000 pixels, I assume the simulator will be zoomed out 1 time. While if the device height is less than 1000 pixels high, then you need to zoom in all the way to get the fony scaling correct. This is done assuming a screen like a standard Macbook Pro. This issue does not happen on actual devices and is only related to the simulator’s zoom factor, which I wish could be retrieved.
I noticed the widget fails if the default anchor is modified. for example, adding:
display.setDefault( “anchorX”, 0 )
display.setDefault( “anchorY”, 0 )
causes rendering issues
I’m working on a business type app and found it easier to to set the reference to the top left vs the center. Not sure if this would be a common use case?
http://www.coronalabs.com/blog/2013/10/15/tutorial-anchor-points-in-graphics-2-0/
Top left is common for me as well but I tend to set the anchorX, anchorY 0,0 each time I create the object rather than using the setDefault. When G2 was initially released setDefault was causing all sort of issues so I never warmed up to it.
hectots, here it is working fine in the simulator.
What Corona build are you using? I would say that it appears that your editFontColor is with alpha 0, making the text invisible…
@atanas I sent you calibration data from Galaxy S2 which is way off.
I’m a bit worried though whether people knew what to do in the calibration screen.
I want to check if this is what I was supposed to do:
Increase height until line is in the middle of the edit field.
Increase height adjust so no text is cut-off.
position label on the line (though x is subjective so I just put it on 0 cause i think it’s far enough from the edge)
adjust font scale and position to match and overlap red text
Is that right?
Renato, I’m using build 2013.12.7. I haven’t changed the code on the sample project, which is the one I’m running in the video.
I’m sure Atanas will chime in regarding your questions but I think you are right about your assumptions.
What your questions highlight for me though is the fact that the current calibration screen is not something we can throw at end-users and expect them to survive. I know Atanas designed it as a quick tool for us, developers so please don’t take this as criticism.
I made a version, a mockup for what an end-user version of the calibration tool could be like. Please see attached image. Comments welcome as always.
@primoz, you are on the right track, just you dont really need to adjust the height of the font, the horizontal line alignment is optional
Thanks kerem, the screen looks great
Thanks gj, I will look into fixing this.
@ksan that looks great although I would add +/- buttons like there are now so you can fine tune the settings.
Also this is to adjust the font scale but if ou want the calibrate the positioning also then I would suggest a horizontal line like there is now to center it and also vertical line indicating where the start of the text should be. I think vertical positioning will be just as hard to tacle for this devices as the font scale. Although, as atanas has just figured out, it might just be the android 2.x.x devices that have this issues, so maybe a y/x offset can be set for all of them as well.
I know what you mean. I was thinking about how we could offer a simple looking UI if we were to ask an end-user to calibrate so I chose to eliminate some of the extra details etc. In any case, I think Atanas is very close to making all this unnecessary.
I just received an update which seems to be very close to perfection on my Android 2.2 device right out the box without using any calibrationdb entries. It would be great if all beta testers could update and run their Android device testing and send results again to Atanas. Thank you so much for all your help.
If not too late i have an Archery Utility app that i could embed this in and test it.