widget.newEditField beta testers needed

Solar2D Widgets
#21

I noticed the widget fails if the default anchor is modified.  for example, adding:

display.setDefault( “anchorX”, 0 )

display.setDefault( “anchorY”, 0 )

causes rendering issues

I’m working on a business type app and found it easier to to set the reference to the top left vs the center. Not sure if this would be a common use case?

http://www.coronalabs.com/blog/2013/10/15/tutorial-anchor-points-in-graphics-2-0/

#22

Top left is common for me as well but I tend to set the anchorX, anchorY 0,0 each time I create the object rather than using the setDefault. When G2 was initially released setDefault was causing all sort of issues so I never warmed up to it.

#23

Thanks gj, I will look into fixing this.

#24

If not too late i have an Archery Utility app that i could embed this in and test it.

#25

Never late, as long as you send your Android calibration data :slight_smile: Can you please send me a PM with your email as i have ran out of quota for PM attachments Thanks Atanas

#26

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)

#27

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

#28

Hi Atanas,

PM sent …

It will be great to try it. Thanks

~Mustafa

#29

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

#30

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

#31

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!

#32

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

#33

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

#34

It shouldn’t be more than 5 lines. I have the code here and can implement for you.

#35

Not exactly what I meant :slight_smile:

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.

#36

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 )
#37

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.

#38

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.

#39

Two more things:

  1. I only don’t understand why the editField in the superSize scene doesn’t behave as the same as the Editors scene. 

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

#40

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