Widget for text input...

Solar2D Widgets
#21

Rob, this is looking great! I was able to extend it with ease (as you suggested) to include options to manage the keyboard type shown along with the input prompt… Also added an option to bring the keyboard up automatically without having to tap on it first. This is quite common in situations where there is only one inputField displayed.

Additions to code hilighted below : 

    opt.inputType = customOptions.inputType or “default”

opt.keyboardType = customOptions.keyboardType or “done”

opt.autoPopKeyboard = customOptions.autoPopKeyboard or false

    opt.font = customOptions.font or native.systemFont

    field.textField.inputType = opt.inputType

field.textField:setReturnKey(opt.keyboardType)

    field.textField.text = opt.text

if opt.autoPopKeyboard then

native.setKeyboardFocus( field.textField )

end

#22

Rob, 

I wanted to implement the behavior where the input field is presented with an initial text which disappears when you first tap on the field. I managed to do this with ease in my main.lua using the following approach… Simple check and clear text in the began phase in my listener function.

local eraseInitText = true if event.phase == "began" then -- check if we are supposed to clear the initial text supplied to the widget if eraseInitText then event.target.text = "" eraseInitText = false end

This is all fine and it works but ideally I would like to push this capability into the widget code in widget.newTextField.lua and turn on/off through another opt.eraseInitText type variable. 

How can this be accomplished? Is it possible to have some of the listener code implemented on the widget code side rather than main.lua side?

Thanks much

#23

Hi Ksan,

Isn’t newTtextField.placeholder doing what you need ? Or you need some custom functionality?

Cheers

  Atanas

#24

The placeholder is fine. I just want it to disappear (optionally) when I tap on my field on display. Similar to what happens when you tap on Search in IOS mail for example. The code above accomplishes what I need so all is nice. It would be nicer if I can put this in Rob’s code though rather than keep it in the listener outside the widget code hence my question. 

#25

Aaaah got it:)

You can implement a listener in the widget and inside of it do the logic. Inside this widget implemented listener you would also show/hide the keyboard. Then if the user has supplied a listener function call it at the end

#26

Yup. Thats exactly what I need to figure out. Thanks for your guidance. 

#27

They have it in searchEditField - let me know if you need a code extract

#28

Ahh thanks for the pointer. Will look in there later tonight. Currently having fun with something else (with promising results!). 

#29

Did I include a placeholder?  I know newSearch had it, and its one of those things a full blown text widget would support.  I didn’t pay attention to how it was done in the search widget, but if it were me, I would use a display.newText() with the placeholder text where the text is supposed to be and when the textField handler gets a began phase, hide/remove the place older field.  I would not use the native.newTextField’s text as the holder of that placeholder.  I’ve seen some tools use it and sometimes, the placeholder text can become editable. 

In the search widget though, they have an internal field handler that passes the event on to the user’s field handler and the reason for that is to manage clearing the place holder.  I agree  you should probably look at the search widget and see how it was implemented there, as it seemed to be done in a logical manner.

Rob

#30

No you didn’t but I put one in. I did it crudely using the .text of the native itself but your point is a good one. I can change. Also thanks for the tips on the listener. Will try to crack it and post back. Thanks much!

#31

Rob, response to your request on the blog post. Sorry for the quality of my screenshots. Don’t know how to do it on Android so I took a photo of my Android with my iPhone… You can see the lower outline of my placeholder text (Search) in the photos. 

#32

Seems Rob’s scaling approach is not working on the Android?

Ksan - have you tried the searchField scaling on Android as it uses a different approach ? I don’t have an Android testing device setup right now.

Thanks

  Atanas

#33

Can you print out the values of display.pixelWidth, display.contentWidth for me?  Also it would help to get the value that’s being calculated for deviceScale.

Also what font are you using?  In fact why not post the code?

#34

Rob, I posted the updated code at http://forums.coronalabs.com/topic/41908-lets-work-together-to-build-a-nice-searchbar-sample-app/#entry218733 where I keep the searchBox sample app discussion going. Will get back to you with the values you want off the device. 

@Atanas, will also try the widget.newSearchField on the same Android device and see how that one fares.

#35

Got the values off my Samsung Galaxy S where the font size issue was observed. Here goes : 

deviceScale = 0.75

display.pixelWidth = 480

display.contentWidth = 320

Next will be to try the widget.newSearchField to see if the scaling method used there is doing any better. 

#36

I tried the widget.newSearchField on the same device and I see that it exhibits the same issue so the scaling mode used there isn’t working any better than Rob’s simplified scaling. Hope this helps shed some light on the matter.

#37

Thanks for letting us know Ksan, I guess we will need to use a more complicated solution like the one posted by Roman85 Rob, since the Corona QA probably has the largest number of devices to test on would it be possible to get them on board. It seems we are getting close to a workable solution for text fields. I have been trying myself the approach of swapping textfields and display newtexts and its working relatively fine on iOS but also needs testing to see what are the offsets on the various devices to make sure bot texts are aligned exactly the same when they swap. Thanks Atanas

#38

I’d be happy to test your approach if you wish on my Android device. Just shoot me a PM. 

#39

What I suspect may be happening is that you’re using a font that the device doesn’t recognize and that’s likely the problem.  I’ve seen it where I try to use a font and it starts using native.systemFont as a fall back, but the font is super tiny.

Can you post your code where you’re using your font?

Remember the Simulator has access to all of your Mac or Window’s installed fonts.  There is generally hundreds of fonts there.  Devices are much more Limited.  iOS probably has around 70 or so, but Android devices may only have a few.   Amazon and the Nook’s I think have the free Microsoft fonts there, but you will find they are not named consistently.

And you can be pretty certain that almost all Android devices will not have the commercial Mac fonts like Helvetica, Helvetica Neue, and so on.

Rob

#40

Rob, it the code from your tutorial. At first it was using HelveticaNeue-Light which could explain the issue on Android. Then I changed it so it uses native.systemFont but unfortunately the problem persists. When I use native.systemFont Android should default to something reasonable right? Thanks for your continued efforts.