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

Solar2D Daily Builds and Public Releases
#21

@tes_735, I read on the release note (for daily build 904) about changes made to native.newTextField (which is specifically related to event phases):

http://developer.coronalabs.com/release/2012/904/

I haven’t investigated this further, but the API doc that comes with the latest build may have additional info? Anyhow, I thought I’d mention this just to let you know why you are experiencing this.

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

#22

Right Naomi, I saw that too, and I changed my code to account for it. BUT, nothing is being sent after “began” on the device. I was originally expecting “submitted” per that release on the enter key, but found that “editing” was what was being sent so I changed my code to that (only on the sim). It may be some change related to this being a textBox and not a textField. Something strange is happening tho either way.

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

#23

Hey, @tes_735, I just checked iOS device build (using daily build 912), and the native.newTextField appears to be working as expected. So maybe this is Android specific issue that might’ve gotten introduced when changes were made to native.newTextField.

BTW, I really like the way “began” phase works for native.newTextField now. I hope the issues you are seeing on Android device will be fixed soon.

Naomi

Edit: I just kind of realized you are talking about native.newTextBox – and I’m not quite sure what problem you might be seeing. Will you take a look at the native.newTextBox section of the API doc and see if native.newTextBox is behaving differently on Android device? On iOS device, native.newTextBox works as expected (and I haven’t really noticed any changes to its behavior from the daily build 904 – maybe it’s because I don’t particularly use some functionality that might’ve been changed…) [import]uid: 67217 topic_id: 30741 reply_id: 124118[/import]

#24

Right. newTextBox. It should be sending “editing,” and it does, but only on the sim. I don’t get that event phase on the android device. [import]uid: 169520 topic_id: 30741 reply_id: 124164[/import]

#25

This vertical alignment bug is now fixed. This fix will be made available in daily build #907, tomorrow. Thank you for bringing this issue to our attention. [import]uid: 32256 topic_id: 30741 reply_id: 123765[/import]

#26

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]

#27

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]

#28

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]

#29

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]

#30

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]

#31

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]

#32

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]

#33

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]

#34

Thanks Joshua. Built and tested. Shows at the top left now as it should. However, the enter key no longer sends “submitted” for a multiline textbox. Is this on purpose? If so, how do I capture the enter key? I had it capturing before I updated to 907.
[import]uid: 169520 topic_id: 30741 reply_id: 124059[/import]

#35

Actually, it’s not sending several things. I may need to file another bug but I’ll run it past you and see what you think. Probably even need a new thread.

It now sends “editing” on the android mac sim. I only get ended and submitted when I click off somewhere. I thought, “Okay, I’ll use editing,”

BUT, it doesn’t send anything but “began” on the actual device. No more “editing”

I also tried to capture key presses using the “key” event, but it never captured anything. Very simple stuff with a Runtime: event listener sending to a handler that adds the event.keyName to the text of the field so I can see it in the device. All I get is “began” from my field handler (which I also have contact to the text field)… and that’s it. I need other events to be able to do anything useful.

Please advise. [import]uid: 169520 topic_id: 30741 reply_id: 124060[/import]

#36

@tes_735, I read on the release note (for daily build 904) about changes made to native.newTextField (which is specifically related to event phases):

http://developer.coronalabs.com/release/2012/904/

I haven’t investigated this further, but the API doc that comes with the latest build may have additional info? Anyhow, I thought I’d mention this just to let you know why you are experiencing this.

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

#37

Right Naomi, I saw that too, and I changed my code to account for it. BUT, nothing is being sent after “began” on the device. I was originally expecting “submitted” per that release on the enter key, but found that “editing” was what was being sent so I changed my code to that (only on the sim). It may be some change related to this being a textBox and not a textField. Something strange is happening tho either way.

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

#38

Hey, @tes_735, I just checked iOS device build (using daily build 912), and the native.newTextField appears to be working as expected. So maybe this is Android specific issue that might’ve gotten introduced when changes were made to native.newTextField.

BTW, I really like the way “began” phase works for native.newTextField now. I hope the issues you are seeing on Android device will be fixed soon.

Naomi

Edit: I just kind of realized you are talking about native.newTextBox – and I’m not quite sure what problem you might be seeing. Will you take a look at the native.newTextBox section of the API doc and see if native.newTextBox is behaving differently on Android device? On iOS device, native.newTextBox works as expected (and I haven’t really noticed any changes to its behavior from the daily build 904 – maybe it’s because I don’t particularly use some functionality that might’ve been changed…) [import]uid: 67217 topic_id: 30741 reply_id: 124118[/import]

#39

Right. newTextBox. It should be sending “editing,” and it does, but only on the sim. I don’t get that event phase on the android device. [import]uid: 169520 topic_id: 30741 reply_id: 124164[/import]

#40

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]