Never late, as long as you send your Android calibration data 
Can you please send me a PM with your email as i have ran out of quota for PM attachments Thanks Atanas
The horizontal line in the calibration box was supposed to indicate something? (Like, it should be the bottom or be at the center of the box)
Its in the center of the editfield group - which can be off on Androids as they have those extra pixels (invisible) around the textfield. Its meant to help center the text
Hi Atanas,
PM sent …
It will be great to try it. Thanks
~Mustafa
I look like great widget. I would like to try it. The textfield is not working like I want and your widget may be my savior
Mustafa, sent you the files and looking for your Android calibration data. Hu, you will need to send me a PM with your email address Thanks Atanas
Hello, since I’m doing a business app (almost finished!) I would really like to be able to test this awesome solution with my application please!
Thanks!
Hi atanas.
You can create the “generic handling of the background touch events in the editField widget itself” by using the same way that you translate the editField to make it always visible (above the keyboard).
Thanks Renato for the suggestion The one problem I had with this approach is that it will require more code (in number of lines) that just adding the one-liner to the background. Still on the fence though
It shouldn’t be more than 5 lines. I have the code here and can implement for you.
Not exactly what I meant
If I use a parameter to newEditField to specify the parent group/container, then you need to do this for each editField so if you have 5 editFields, even if they are not potentially scrolling up to reveal the keyboard, you still have 5 extra lines of code. On the other hand, adding the event listener to the background is 1 line of code.
Something else that I was contemplating was to use my subclassing of storyboard scenes and add an invisible group to all scenes and then use this for handling background clicks. This would reduce the lines of required code.
Indeed, specify the group in the parameter is not good and we don’t have to do that. We can only add a boolean parameter like the “cancelOnBackgroundClick = true”.
You don’t have to create a invisible group. You can add the listener to the runtime. Eg:
Runtime:addEventListener("touch",yourFunctiontoRemoveFocusAndTranslateBackTheEditField )I was running it again here and actually you have everything done, it is only missing an “if”. Let me explain.
The normal behavior for a user that is inserting text in a textField and want to remove the focus to the keyboard without triggering the submit is to click outside the textField. Do you agree?
In the “editors” scene, if the user starts to insert text in the editField and click outside the field, your widget is submitting the content. Although this is a nice function to have, I would say that in majority of the times I wouldn’t want to submit the content.
But I noticed that your widget is submitting the content only when the text is changed. If it is not changed, it only removes the focus. So, you already have that implemented, is only not enabled by default.
Hey atanas.
I just modified your example passing the onSubmit = nil and it is working as expected. So we have been talking about something that is already there.
@ksan may have not understood correctly when I first post that problem because he said that it was not implemented.
Two more things:
-
I only don’t understand why the editField in the superSize scene doesn’t behave as the same as the Editors scene.
-
I think you should increase a little bit the vertical distance translated by the textField to avoid to be hidden by the keyboard. Look the image attached, my coffee editField (that I move it to start in the bottom) is not translated enough.
Hi Renato,
For the onSubmit, here is the current behavior
onSubmit is triggered in 3 cases
-
the users actually hits the Submit/Go/Search button on the keypad
-
the user types something in the edit field and then clicks to another field or background. If the text is modified then an onSubmit is triggered
-
the user clicks on the Clear button to remove any content from the edit Field
In the latest mods here, I am also passing the event.phase to the onSubmit event, so you can check if the phase is “ended” or “submitted” and decide how your app should respond to this - to submit or not the content.
I am sending you the latest files, so you can try how this works for you
>>I only don’t understand why the editField in the superSize scene doesn’t behave as the same as the Editors scene.
In the SuperSize scene, you can add a background handler bg:addEventListener(“touch”,function (event) native.setKeyboardFocus(nil) end ) and it would act the same as the other scenes.
The reason it wasn’t added to the sample was that initially I thought it might be better to show both ways (hide or not hide the keyboard on click), but since it seems to confuse users now in the latest sample app, the above event is already added to the Super Size scene. One case where you might not want to have the background click to hide the keyboard is if you onscreen keyboard does have a Submit/Go/Search type button and that is how you expect the user to close the keyboard.
Thanks for the keyboard input, actually this should be fixed already in the latest build that I sent you, Kerem beat you reporting this one
Renato,
The Runtime:addEventListener(“touch”,function (event) native.setKeyboardFocus(nil) end ) - wouldn’t that pretty much take all touch events, including ones you don’t want to close the keyboard? Example in case would be click on the edit field itself.
In any case, if you would like this behavior - its still simpler to do it in the app than have a parameter cancelOnBackgroundClick = true for each editField, no?
Thanks,
Atanas
I’m a bit late to the party. I’m thinking I might try an additional behavior.
Submit takes you to the next field on the screen. I know I can build this into the onSubmit listener and probably its the better way to go rather than bloat the widget but just putting it out there. It could be an option for the widget if you really wanted to put more stuff in there… Next widget field to go to on Submit etc.
I do think that we should keep it at the essentials level and focus on speed and efficiency though. Current feature set is already super awesome in my humble opinion.
Hi anatas.
I received your last code. I will test it.
Just answering you about the above, just adding the “Runtime:addEventListener(“touch”,function (event) native.setKeyboardFocus(nil) end )” doesn’t work well when the editField was vertically translated. So, I would have to call your internal function that makes the editField submit (but not actually submitting the content).