Yosu, send me your email for the files. The edit field supports 9-slice frames that can be used to draw various frame/backgrounds
Primoz, the back button should hide the keyboard if its visible. It is my understanding this is the default behavior on Android?
Yes ofcourse. What I am saying is that if the back button cancels the keyboard you don’t get an event for it in the key listener.
So you can’t move things back in their place until the user touches out of the edit and it looses focus.
Just to clarify: are you moving the whole content up or just the edit?
I will try it out today in the evening and see how it works.
Primoz, I am moving the container group or scroll view - it can be passed as a parameter to the edit field. And it is moved back when the editField loses focus.
If the editField has not lost focus when the keyboard is hidden with the back button, then it will wait until it loses focus.
Yes that’s exactly what bugged me. I wen’t with just hiding the content (leave background) and show just the label, edit and done button on the top of the screen, so the user wouldn’t get the screen where the keyboard is gone but the content is shifted up and emmpty in the bottom. I may be exagerating the issue but it really annoyed me.
I wouldn’t get too fixated on it - I suppose all apps under Android would exhibit the same behavior
They don’t as they use the system function to slide up the content which resets when the keyboard is canceled.
I’d love to try it out. I’ve been annoyed with the limitations of newNextField.
-Greg
Thanks Greg,
PM sent with the sample app as well as the sources for the widgets.
Atanas
Atanas has done such an outstanding job with this widget!!! It is very very versatile and robust. You will be seriously impressed.
On Android, due to device variability the font scale results might vary so please bring as much device testing as you can muster to the table. There is a calibration function in the sample app from Atanas where you can tweak various parameters to get the editField to work perfectly on your device and then report the calibration data back to Atanas for inclusion in the widget calibration data. The more people test this code with different devices the better.
So in a nutshell, please test on device. Don’t just look at this on simulator. Looking forward to all your feedback.
I tested here. Nice job.
The only problem is the one that you guys mentioned about font size on android devices.
I also noticed that on the “Super Size” scene, when I click outside the textField it is not losing focus automatically… I think that could be something to add… on the “Editors” scene, when I click outside, it is having the same behavior of the submit event. I don’t know if myself as user would expect that. If I click outside a field, I just want to get out of it, not necessarily submit it.
Apart from that, appears to be great.
Hi,
Thanks for the great feedback. The more Android devices we can run this test on the better. Can you use the calibration screen to get the native and display object to match in size and position and then hit the email button on the Android device? This will send Atanas info about this particular device which will then be added to a calibration file. The more the merrier.
Not sure if I understand the comment about SuperSize scene. It seems ok on my end. Is your comment specific to a platform, ie on Android etc?
I agree about your comment on tapping outside a field. Ideally we should be able to do either way depending on the situation. Atanas might have already put this capability in but if not perhaps he can do the same thing he did for the pickerlist where cancelOnBackgroundClick = true, gives you the exact behavior you describe.
Cheers
The comment relative to the SuperSize was that when I was inside the textField and clicked outside, it was not losing focus. Perhaps that cancelOnBackgroundClick param is not being used… (I didn’t look the code to check)
Ahh, I see what you mean. There is no cancelOnBackgroundClick parameter on the editFields yet. Based on your feedback we can ask Atanas to put this in. Meanwhile for the super-size scene if you could add the following on line 15 you will get the same response as on the editFields scene.
bg:addEventListener(“touch”,function (event) native.setKeyboardFocus(nil) end )
Kerem is correct about the background click - in the Super Size scene, the event is simply not added so you can see it work either way. In the other scenes, the event is added in the sample app.
About adding a generic handling of the background touch events in the editField widget itself, not sure how the editField would do it since it does not know what exactly is the background group (opposed to the pickerList case, where it creates the background itself and has a cancelOnBackgroundClick property).
Renato, can you please forward me your Android calibration data.
We can test it also if you want. We are doing a tourism app with Corona, therefore such a new widget would be more than welcome.
Nick
I’d be excited to try it out too. I’ve got a few arcane Android devices that would be useful to add to your tests.
Hey guys, nice work!
I would love to try this out!
Does this do anything to address the problem where you can’t display a navigation bar (next, previous, done etc) that sits above the native keyboard?
I am really in need of suggestions as to how to best handle closing the keyboard and moving to different fields when using number only keyboards etc.
I stuck a navigation bar at the top of the screen to do this, but it just looks weird at the top of the screen when it should be directly above the keyboard.
I hope I am not hijacking this thread.
Thanks!
@euphoriacorona, I think you are asking about the use of keyboards which does not have a Done/Return type of button right? We encountered this use case and Atanas made it possible to create the onSubmit event when user touches another field on the screen or simply the background. So your navigation buttons could be made redundant with this widget.
Hey Ksan, exactly.
So I guess my next question would be… What would be the best way to explain this to the user on the screen in question?
For instance… Say you have 4 text fields, the first two use the default keyboard, the next one uses a number keyboard and the last uses an email keyboard.
When the user gets to the number keyboard… What would be the best way to explain to make it intuitive as to what they should do to advance to the next field… Or conversely, to show them how to dismiss the keyboard?
I’m struggling mostly with making this all intuitive and simple for the end user.
Thanks for your help!