Android device shows bad chars or black on textField when also using tabBar widget

Solar2D Daily Builds and Public Releases
#41

Hey, @tes_735, I just read this blog post about text field and text box:

http://www.coronalabs.com/blog/2012/09/12/faq-wednesday-native-newtextfield-and-native-newtextbox-events/

The very last entry says: By default the native.newTextBox is not editable. You can enable the edit mode by setting object.isEditable = true (where “object” is the native.newTextBox handle).

Edit: Woops, I just checked and I have already included object.isEditable = true for my text box object. I don’t remember when I included it, but I must’ve done it from the get-go, and that’s why my text box object behaves properly during editing phase.

Do you have this property set to true in your code?

Naomi [import]uid: 67217 topic_id: 30741 reply_id: 124201[/import]

#42

Ah. Interesting. I have mine set to that, but didn’t know it would be editable with it not set. Maybe editable=true is the default? In any case. I did already have that set. Too bad it’s not sending those other events. According to that link you sent earlier, it appears they’ve added a few things to textBoxes. Like, the last character you typed on an editable field. This is useful, or will be when it works :wink: [import]uid: 169520 topic_id: 30741 reply_id: 124202[/import]

#43

Thanks for posting your test results and for submitting your bug report. That’s very helpful. It’s also good timing too, because we’ve been recently looking into this issue as well. The problem here is that the different operating systems handle text input events differently, so it is up to us to force it to be consistent in Corona. That’s the next step for us. [import]uid: 32256 topic_id: 30741 reply_id: 124607[/import]

#44

tes_735,

I just tested the TextBox today. It is sending all of the “began”, “editing”, and “ended” events for me. Also, a TextBox is not editable by default. It is read-only. I just verified that today as well. You do not receive any events from a read-only TextBox.

Also, note that TextBoxes do not support the “submitted” event. This is by design. It was made this way to because the return key needs to create a new line in the multiline TextBox instead of raising a submitted event. Now, while we can add a Done button in Android to indicate that text input is finished, iOS does not have an equivalent. Hence, we intentionally limited it on Android to be consistent on iOS.

Are you absolutely sure that you are not setting the [lua]isEditable[/lua] property to true in your code?

If so, would you mind running a quick test on your end? Open the main.lua file for the sample project “Interface\NativeDisplayObjects” and comment out the [lua]textBox.isEditable=true[/lua] from the code… and then build and run it for your Android device. Tap the “textBox” button in the sample app and then tap on the text box that is created on screen. Is it editable? [import]uid: 32256 topic_id: 30741 reply_id: 124208[/import]

#45

Joshua, I tested in a simpler setup and I am indeed getting “editing” in that setup. The test was a strip-down of what I’m already doing. I do have it set to isEditable = true so I’ll have to troubleshoot my app as it appears to be a problem there someplace.

My device works with the stripped-down version of my textbox.

Since submitted isn’t fired from enter anymore, can you please advise me on how I may know when the user has hit enter? What I’m trying to do is “know” when the user has requested a new line.

  • Can I look for the new-line (\n) character? Is this sent when the user hits enter?
  • Is there any other elements of the box listener that I can take advantage of to accomplish this?
  • Can I use the ‘key’ Runtime even listener? I’ve tried this but I couldn’t get it to work. If this is designed for what I’m trying to do, then maybe I’m doing it wrong. Or maybe keys can’t be listened to if the field has focus?

Thanks!
[import]uid: 169520 topic_id: 30741 reply_id: 124224[/import]

#46

The TextBox has “never” raised a submitted event before. I’m sure of this. It doesn’t make sense to raise a submitted event when the return key is pressed in a “multiline” TextBox because a newline is valid input. This is because the end-user might want to hit the return key for a new paragraph.

The “userInput” event listener provides newly typed characters via its [lua]newCharacters[/lua] property. Please see the following API documentation…
http://docs.coronalabs.com/api/event/userInput/index.html
[import]uid: 32256 topic_id: 30741 reply_id: 124228[/import]

#47

I see. It’s just in the sim that you see submitted (I see it in the docs now). I also see this newCharacters functionality. If I can sniff for a newline character this way, then my problems are solved. Thanks.

***edit: I’m editing this to let you know that event.oldText returns nil. I double and triple checked my syntax. This is a copy/paste line form my code:
print("pretext: ",event.oldText)

  • it’s inside my “editing” phase

****SOLUTION:
For anyone that may be looking to do something similar. The following will return 1 if it’s an enter key newline, and nil otherwise (put in the editing phase):
local newline = string.find(event.newCharacters, “\n”)

[import]uid: 169520 topic_id: 30741 reply_id: 124231[/import]

#48

After talking to the rest of the team here at Corona Labs, we’ve noted that there are inconsistencies in native text field behaviors between iOS, Android, and the Corona Simulator. So, I see now where the confusion is coming from. That’s something we’ll need to address our on end… to make all event handling consistent.

But in any case, it sounds like you found a solution. So, that’s great to hear.

I am a bit concerned about you saying that the TextBox was editable by default, because it should be read-only by default. Did this only happen in the Corona Simulator? Or did it happen on your Android device… and if so, what model/make/version was it? [import]uid: 32256 topic_id: 30741 reply_id: 124400[/import]

#49

I agree Joshua, it is inconsistent.

Sorry about the confusion on the editable by default. I wasn’t saying it was. I was saying MAYBE it could be in response to what Naomi said about her’s being editable without having set it. Turns out, she did have it set, but forgot about it and thought it wasn’t (I think that was the case). Anyway, it’s not editable by default :wink:

Now, about inconsistencies; I’m currently trying like hell to get some things to work and yes indeed they’re inconsistent LOL!

Example:

  • In my app, I have a textbox that takes up the screen, and I’m grabbing the enter key to switch between some formatting using my above string.find for \n. It works great in the sim all the time. I put it on my device, and it works *some.* It depends. Sometimes it stops working (sending “editing”) when I hit the backspace. Other times it works regardless if I hit the backspace or not.

SO

  • I created a stripped down version using the same text code, but not all the other methods that aren’t used in this. And, it’s the only other storyboard scene in this test. NOW what I get is the cursor jumps to the beginning of my text box when I type instead of staying at the end, but will at least keep sending “editing”. IT’s the EXACT same text code in the handler and the instantiation of the textBox. This isn’t what happens in the other test – that one keeps the cursor at the end like it’s suppose to.

Strange.

I’m still troubleshooting and will report back if anything promising comes up.

[import]uid: 169520 topic_id: 30741 reply_id: 124448[/import]

#50

I just did a bug report with some example code. It is as follows:

Inconsistant behavior between sim and Android device on textBox.

textBox on sim runs fine with this code. event.newCharacters will give me one character at a time to use, which is what’s useful. Clicking the button at the top doesn’t break, but allows me to continue to use the textBox with expected behavior.

textBox on Android Tablet does the following:

  • event.newCharacters will continue to add new characters to the buffer if I continue to type, until space/enter etc is hit.
  • event.newCharacters stops working if I click off and the textBox loses focus.

I was going to put a link into this thread, but forgot to do that.

[import]uid: 169520 topic_id: 30741 reply_id: 124574[/import]

#51

Thanks for posting your test results and for submitting your bug report. That’s very helpful. It’s also good timing too, because we’ve been recently looking into this issue as well. The problem here is that the different operating systems handle text input events differently, so it is up to us to force it to be consistent in Corona. That’s the next step for us. [import]uid: 32256 topic_id: 30741 reply_id: 124607[/import]