widget.newEditField beta testers needed

Solar2D Widgets
#41

>>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 :slight_smile:

#42

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

#43

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.

#44

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).

#45

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

#46

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

#47

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! 

#48

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

#49

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!  :slight_smile:

#50

Hey atanas.

Quick question: what does the errorFrame params do?

errorFrame = { cornerRadius = 5 },
#51

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;

#52

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?

#53

Thanks for spotting this bug, I sent you an update. 

#54

Wow. That was fast. I think Corona should hire you their bugs… :slight_smile:

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.

#55

Hehe - thanks, I don’t think Corona can afford me:)

the placeholder color is 

editHintColor = …, by default its grey

#56

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.

#57

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

#58

No, thank you for the widget :slight_smile:

#59

It does not support center align of the text (both placeholder and the native text), doesn’t it?

#60

No, it doesnt currently