Keyboard shows 'Done' When it Should be 'Next'

Mahares · May 18, 2012

When I jump from a tab page to the next in a tabhost, the focus is set on the first edittext box as it should, but the keyboard shows 'Done' despite additional edittext boxes below the first one that need accessed. I tried different combination of code such as:

B4X:

Sub eText_FocusChanged (HasFocus As Boolean)
      If HasFocus=True Then eText.ForceDoneButton=False
End Sub

I also tried:

B4X:

Sub etext_EnterPressed
   eText.ForceDoneButton=False
End Sub

Nothing worked to make it display 'Next'. The device has ICS4.

Roger Garstang · May 18, 2012

I noticed this too and I think I noted it in the main IME thread where I was also having issues with adjusting the screen when the keyboard opens that ended up being an issue with calling .Visible for a view overriding the screen size message.

The Next/Done issue changes depending on which keyboard too. Full screen Landscape keyboard seems to always like to show Done for me even though it behaves like Next. The half screen portrait keyboard shows correct most of the time although at times it shows wrong too. I've tried all the things you mentioned too, and I think using the IME library only makes it worse or appear more often. Some custom keyboards like on my HTC or the Swiftkey thing show even odder and sometimes don't even show them or substitute Enter for them.

Erel · May 20, 2012

Why do you change ForceDontButton value in FocusChanges event? You can do it in the designer or when the activity is created.

Mahares · May 20, 2012

@Erel: The only reason I added that code you saw is out of desparation. I di d not have that code. I added it in case it helped, but it did not. The same phenomenon happens whether I have that code or not. It always shows 'Done' even if I eliminated it.

Erel · May 20, 2012

Can you upload your project (or a smaller one demonstrating this issue)?

mc73 · May 20, 2012

I've replicated your problem. What I've found is trivial in my opinion. By setting focus (which I suppose you do in order to avoid disabled txtBoxes) you somehow interfere with the 'normal' way the OS is handling tabStops. I've removed the requestFocus lines, and eveyrhing went back to normal (keyboard set back to 'next' instead of 'done' state).
After all, what's the point in manually setting the focus when your form shows up? I mean, let's leave the user click once, where he will text one way or the other

Mahares · May 20, 2012

@mc73: Before I unzip and look at your code I want to update you with one I have done. I followed your advice by commenting all Requestfocus in the entire code. hence, all requestfocus were stopped. Unfortunately the problem continues to occur. Keyboard shows 'Done' instead of 'Next'
I did not use the requestfocus to avoid disabled boxes as you alluded to. I took care of that using the reflector library as demonstrated in the code I showed in one of my other threads. That is working well now. The disabled boxes do not show focus any more.
This is a nagging problem, but not imperative that it be solved. It is simply odd that the behavior of the keyboard manifests itself in the way it does. It may be other parts of the code due to its complexity, but it cannot be the requestfocus because I have them all commented. Perhaps the use of the IME, although sporadically is contributing to that. I am totally lost with this issue. It behooves me to accept it the way it is and not seek perfection.
Thank you for your reply and valuable help.

@mc73: I unzipped and reran your code. By eliminating your requestfocus, you do get the 'Next', but your code has not really solved the disabled boxes issue. You still get the focus on disabled boxes. I took care of that in my project by using the reflector with Roger G. suggestion. If you have a firm solution to this I would love to explore it. If not, then I am sure some day Android wil resolve that like Microsoft did with much of their software.

mc73 · May 20, 2012

Mahares said:
@mc73: Before I unzip and look at your code I want to update you with one I have done. I followed your advice by commenting all Requestfocus in the entire code. hence, all requestfocus were stopped. Unfortunately the problem continues to occur. Keyboard shows 'Done' instead of 'Next'
I did not use the requestfocus to avoid disabled boxes as you alluded to. I took care of that using the reflector library as demonstrated in the code I showed in one of my other threads. That is working well now. The disabled boxes do not show focus any more.
This is a nagging problem, but not imperative that it be solved. It is simply odd that the behavior of the keyboard manifests itself in the way it does. It may be other parts of the code due to its complexity, but it cannot be the requestfocus because I have them all commented. Perhaps the use of the IME, although sporadically is contributing to that. I am totally lost with this issue. It behooves me to accept it the way it is and not seek perfection.
Thank you for your reply and valuable help.

@mc73: I unzipped and reran your code. By eliminating your requestfocus, you do get the 'Next', but your code has not really solved the disabled boxes issue. You still get the focus on disabled boxes. I took care of that in my project by using the reflector with Roger G. suggestion. If you have a firm solution to this I would love to explore it. If not, then I am sure some day Android wil resolve that like Microsoft did with much of their software.

In the example I've posted, the disabled txtBoxes focus problem was not occuring when you had the code-lines not commented, at least that was what I got while running the app. Then I've commented the lines, to demonstrate that by doing this, the 'next' <-> 'done' problem disappears (at least in this example) and, yes, the problem with disabled boxes reappear. This is exactly why I've asked whether there is a true need for setting the focus. I would certainly look deeper into this, if I was getting some info on whether it is trully important, cause as I've already said, I think that the user can set focus on our modern smartphones-tablets by touch. I hope you'll find a solution.

Roger Garstang · May 24, 2012

I was searching for a way to disable the full screen keyboard after seeing the Browser in android not having it and found a post on another site by Erel that helps out for this too:

Using a Reflector/Reflection-

B4X:

ref.Target = YourEditBox
ref.RunMethod2("setImeOptions", 268435461, "java.lang.int") 'IME_FLAG_NO_EXTRACT_UI | IME_ACTION_NEXT constants

This both disables the fullscreen keyboard and sets your button to show Next. (Mine usually only shows wrong in landscape) If you just need Next the value is 5. I don't think I agree with focus being the cause...or at least the only cause too (At least for the Full Screen/Landscape keyboard). In my app I commented out all IME code that were the only places a focus was changed as well and the landscape keyboard still showed Done everywhere.

Another weird thing I noticed-
I kept having issues with AddHeightChangedEvent when I changed my screen layout. First with hiding an Imageview then when clicking another button on the screen to go to another Activity and back the screen would still be modified like the keyboard was open. I ended up adding a scrollview and putting everything in it then doing:

B4X:

Sub IME_HeightChanged (NewHeight As Int, OldHeight As Int)
   pgFrame.Height = NewHeight
End Sub

This works pretty slick and allows you to then scroll your content in the adjusted screen. However when I use the trick above to disable the Fullscreen keyboard the IME_HeightChanged still isn't sent in Landscape mode, so my scrollview never gets resized and can't scroll then. I'm not finding anything to make the IME_HeightChanged fire 100% of the time if you use it.

Keyboard shows 'Done' When it Should be 'Next'

Mahares

Expert

Roger Garstang

Well-Known Member

Erel

B4X founder

Mahares

Expert

Erel

B4X founder

mc73

Well-Known Member

Attachments

Mahares

Expert

mc73

Well-Known Member

Roger Garstang

Well-Known Member

Similar Threads

Keyboard shows 'Done' When it Should be 'Next'

Expert

Well-Known Member

B4X founder

Expert

B4X founder

Well-Known Member

Attachments

Expert

Well-Known Member

Well-Known Member

Similar Threads

Privacy & Transparency

Privacy & Transparency