actually I sent a build with align = “left”,“center” or “right” to Renato and he seems to say it works ok
Super!!! Thank you very much.
Hi atanas.
Still coding here with your editFields and I found something that I don’t know if it is a bug or not.
In your pickerWheel example, when it opens, it already shows “selected” the current date. If you press the Done button, that current selected value does not goes to the editField. Is that the normal behavior?
Hi Renato,
It was just an example for how to use the editField as a selection list in the sample app, but I agree that this is a bug - if the user doesn’t want the current date, he can still press the Cancel button.
I will change the sample app, but right now having an all-nighter on a small html reporting engine so if you fix it before me, please send me the fix
I took a quick look. In the scene-pickerlist.lua look for the following around line 100
local pickerList = widget.newPickerList( details omitted here for space )
and insert the following right after that
self.pickerField:setText(string.format("%d/%d/%d", month,day, year))
this then assigns the current date set on the pickerlist to the editField on click.
The Done/Cancel buttons are created in the widget code and Cancel already knows to revert the editField contents back to what it was before. Hope this helps.
I don’t know how I missed this thread, I saw two related ones but not this :).
Excellent to know this is getting done. I actually made my own version but slightly different.
@atanas I will send you pm with my email if you could send me the sample or a link to a repo please.
A question. How did you handle the repositioning of the edit field? As I understand it is not currently possible to get the correct keyboard height on all platforms or is it?
Also did you manage to get around the keyboard dismiss problem on android (hardware back button or keyboard dismiss on tablets) where there is no event fired and you are left with offset content?
Hi primoz, You can get the exact keyboard height only on iOS. For Androids, I have a default height and also you can change this default height - usually shooting for a higher number this way the editfield is visible even though there will be a small gap between the field and the top of the keyboard. Not sure about this dismiss problem - i will send you the sample and you can let me know. Thanks Atanas
Just focus a text field that is low enough so you have to slide it up and then hit the hardware back button on android. The problem is that android does not issue any event for that so corona can’t send it to you and you are left with an offset content. Don’t know how much this bothers people, but it annoyed me.
You have to track these situations manually and force the text field to go back to the original position.
Yes. Atanas has built some methods to manually set states as needed when needed. Its a little extra work on Android it seems. I didn’t tackle that scenario yet but it looks like we can follow Renato’s advice and deal with it.
Yes i know and I image it will go back once the edit looses focus, but I have not found a way to detect when the keyboard is canceled as you don’t get any event for it and the edit is still focused so the keyboard is gone and content shifted.
I am not sure I understood that. If the user press the hardware back key, you just call the listener simulating the event of the user canceling/submitting the field. That will make the text field to loose focus and translate the content back to the original position.
Yes if you got the event of the button but in this case android does not send a key event so you don’t know the user pressed it.
Primoz, do you mean on your device Runtime:addEventListener( “key”, onKeyEvent ) does not receive an event for the back button?
When the keyboard is active no!
Not just my device as i understand it’s all or most of android devices.
pls count me in too as beta testers. Will test it on android 2.3 and 4.2 devices.
It would be great it text field has some sort (or option) for a background-shadow (shader gradient), so it can look as closely as possible to a native text field.
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.