Ahh thanks for the pointer. Will look in there later tonight. Currently having fun with something else (with promising results!).
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
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!
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.
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
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?
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.
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.
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.
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
I’d be happy to test your approach if you wish on my Android device. Just shoot me a PM.
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
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.
Humor me and change it from native.font(native.systemFontBold) to just native.systemFontBold
native.systemFont and native.systemFontBold are userdata objects. display.newText() is smart enough to look at the font passed in and determine if it’s a string or one of the userdata based native.whatever font. native.newFont() is supposed to also not care if you pass it a string or a userdata object, but native.font spits out a userdata object so you should be able to bypass calling that and go straight to the native.systemFont or native.systemFontBold.
I’ve not tried it (and I don’t have a device to demonstrate it anyway), so give that a try.
Rob
Sure. It wasn’t native.font(native.systemFontBold) anyways. Line previously read
opt.font = customOptions.font or native.systemFont
I changed it to the following just to make sure.
opt.font = native.systemFontBold
Still the same result. Thanks for the idea though. Any other thoughts?
Thanks Ksan, I will clean up the code and send it your way
Sure thing. Also feel free to send me your apk if you don’t wish to share proprietary code at this point. Just build for Android and send it to me. I can load it via USB and test. Will send you a PM with my email. Thanks
I wasn’t thinking about the options defaults Kerem, but later in the code after it creates the native.newTextField, there is a line that looks something like:
field.textField.font = native.newFont( opt.font )
Maybe try:
if type(opt.font) == “string” then
field.textField.font = native.newFont( opt.font )
else
field.textField.font = opt.font
end
or something like that.
Rob, thanks for that. I found & changed
field.textField.font = native.newFont( opt.font )
to
field.textField.font = native.systemFontBold
just to be direct. When I build and run this I get the following error after clicking on my inputField
widget_newTextField.lua:100: bad argument #3 to ‘?’ (native.Font expected, got userdata)
message
This connects back to what you wrote earlier. Should I find the exact name of a font that I know exists on my Android device and try passing the actual font name and see what happens?
Hi Ksan,
Sent you a sample project with the sources - its a real early beta that I am working on, so be patient :). It will probably not work on your Android as it is using Rob’s scaling method
Features -
– display.newEditField creates edit fields that can be preserved when a graphic object is displayed on top (fixes the issue of newTextFields being always on top).
– allows a text label to be attached to the edit field
– allows small icons to be attached to the field - left or right aligned
– allows buttons with events to be attached to the field - left or right aligned
– supports all newTextField features, like isSecure, inputType, returnKey, setting the font etc.
– supports custom theming with a 3-slice image (if you do not have a custom theme installed will revert to the theming of newSearchField)
I will post a little later some screenshots of my screens implementation with this newEditField to give everyone heads up on what is possible. If there is interest I might open a closed beta to iron out the issues.
Cheers,
Atanas