Hi Kerem, Moving to the next field on submit is an excellent idea. One way is to go by the edit field creation and select the field created after the current one. This is the easiest and I already maintain a list of the editfields created on each scene in the subclassed scene so implementation would be easy as well. However it will not work if the fields are not created sequentially. Another option would be to have a tabOrder property that would let the user assign random tab order, regardless of the creation sequence
Renato,
Ok, try out the new update and let me know.
For the global touch listener, there shouldn’t be any difference if the field is moved vertically or not - if you see an issue its probably caused by something else. The internal onSubmit is called always when the keyboard is hidden and shouldn’t have to call it yourself.
If you see any issues, post the code or send me a sample
So if I understand it correctly, since you maintain an internal list already, all we would need a bool flag in the widget setup. Something like jumpToNextOnSubmit = true and then you take care of it in the internal listener. I already almost always set my fields sequentially in a block of code and this would work well for me.
In due course if you wish you can implement the tab order approach which would give ultimate flexibility. Wouldn’t take much either. Add a numeric field at widget setup such as tabOrder = 1, etc. and the same jumpToNextOnSubmit = true. It would be up to developer to make sure not to assign duplicate numbers etc but it could work nicely.
Anyways, I don’t think this is urgently needed. Just another nice to have!
Yes, correct - but I think the boolean flag would be in the scene itself so just setting it once per scene. Also the tabOrder would be sequentially assigned by default at creation time and if you need to change the tab order for a field, it would simply push the tab orders of the other fields around - this way you would assign taborders only to a select few fields for which the taborder and sequential order are different
But what if we have a situation where 3 fields should jump to next and then loop back to 1st from the 3rd like in a carousel and the rest of the fields lets say don’t need to be part of this jump to next setup? If the bool is set once and is part of the scene then can we still handle this? Perhaps we can do it by not assigning tabOrder to some fields that need not be part of the jumpToNext carousel. Would that work?
I’m just being difficult I know! 
Hey atanas.
Quick question: what does the errorFrame params do?
errorFrame = { cornerRadius = 5 },Error frame is the frame that is displayed around the edit field when a you validate a required edit field, to visually show which fields need to have text in them. As sime point I will add regular expression validating and it will also show the error frame. Its basically a rounded rectangle and the parameters allow to customize it
errorFrame.cornerRadius - teh radius of the rounded rect, default is 0
errorFrame.strokeWidth - the width of the stroke , default 1
errorFrame.strokeColor - the color of the frame, default red
errorFrame.offset - by how many pixels should the error frame should be shifted around the editfield, default is 3;
Ok. I got it. I asked because I was with two textFields, one was using the errorFrame and other not, and they were not being aligned although I set the same left position. (They were misaligned for 1-2 pixels). I wanted to check if that was not some kind of marginError or similar.
Another question, we have the param editFontColor that is the color in the native field while typing. But i am not finding where to set the color of the “fake text” that will be used to replace the native. (usually the colors should be the same, but here they aren’t…).
Like, if i set editFontColor = {1,0,0,1}, I will have the text red while typing, but when I leave the field, the text is showing as black
UPDATE: I isolated here the problem. It appears to be a bug in the code. I have 5 editFields. For some reason (probably a pointer problem), the “fake text” of all editFields are using the editFontColor defined by the last editField. Do you want to me fix it and push the fix to your repository?
Thanks for spotting this bug, I sent you an update.
Wow. That was fast. I think Corona should hire you their bugs…
One more thing: It is not possible to change the placeholder color, isn’t it? If not, I will adapt it here to be possible (I need it) and I can send it to you.
I have been working with your lib this afternoon, and man, it is really amazing. Great Job! The params are very intuitive, it follows the basic widget format and makes it easy to use since it is what we are used to deal with.
I noticed that not many people sent the calibration info. I will request some people to submit it for you.
Hehe - thanks, I don’t think Corona can afford me:)
the placeholder color is
editHintColor = …, by default its grey
Hi atanas.
One more bug:
Try using this color:
editFontColor = {219/255, 142/255, 149/255,1},
The font color while typing will be white while the correct color should be light pink.
UPDATE: To fix that, just remove the multiplication by 255 on the line 401-402. It should became:
viewTextField:setTextColor(opt.editFontColor[1], opt.editFontColor[2], opt.editFontColor[3], opt.editFontColor[4]);
I don’t if that is due to Graphics 2.0 or not.
Aaah, you are right - I guess Corona fixed the native.textField:setTextColor to work with the Graphics 2 colors.
I sent you an updated version
Thanks again
No, thank you for the widget
It does not support center align of the text (both placeholder and the native text), doesn’t it?
No, it doesnt currently
[quote name=“Renato - RBG” post=“226061” timestamp=“1390033180”]I have been working with your lib this afternoon, and man, it is really amazing. Great Job! The params are very intuitive, it follows the basic widget format and makes it easy to use since it is what we are used to deal with. [/quote] +1000. This is the best thing that happened to Corona SDK in a long time!!! Thank you very much Atanas.
Hi atanas.
The new version with align property it is working perfect.
Just one thing: Remember the color bug (native now using 0-1 instead of 0-255)? It appears that it the range (0-1) is working only on iOS… on Android is still 0-255… Do you mind checking there if I am right? If so, man, what a bug from Corona…
UPDATE: Yes, I double checked here. It is a bug. Submitted it to the system… (#29756)
Indeed, great catch. Since I am using black fonts didn’t see this one.
Glad the align is working for you, I will check it in github then
Maybe a to-do item for future could be to right align. This is a typical use case for entering numbers.