I use the IME library to process the Next button on the keyboard and navigate to the next control in a list. I just make all views Autocomplete even if no items for the popup list. Navigation to the next control works fine unless there are items assigned for the list. On Gingerbread and Honeycomb devices when I press Next in the control containing items for the autocomplete list it jumps focus twice past the next control to the one after then hangs. The Keyboard stays open between focus changes (By Design) so it usually stays drawn even if Im able to Force Close. The phone/tablet continues to get further unstable and often crashes the Launcher/Home Screen, etc. On Android 4.0 it works fine and navigates the views properly.
-
Welcome to B4X forum!
B4X is a set of simple and powerful cross platform RAD tools:
- B4A (free) - Android development
- B4J (free) - Desktop and Server development
- B4i - iOS development
- B4R (free) - Arduino, ESP8266 and ESP32 development
Weird issues with AutocompleteEditText View and IME
- Thread starter Roger Garstang
- Start date
- Similar Threads Similar Threads
Not really helpful from what I can see, it is like hitting next causes some endless loop of Extracting text. I don't do anything with text at that point and I didn't even type anything...just hit next to go to next control. I pulled the device to stop the never ending stream at the end and still had to trim some off the bottom to fit here.
I've been trying to get the same failure in a smaller app doing something similar, but I can't get it to freeze. Code I've tried is below and works fine, but real code is more complicated...I'm going to see if I can debug more and see where exactly it is when these crazy loops are going. So, what exactly does the AutoComplete boxes do with the action...or any other differences they have that Plain Edits don't do that could cause issues?
I made them all AutoComplete just to have a base control to work with that does it all. It appears in every way to be just like a Plain edit other than the list, so I figured it wouldn't hurt to just have it available. So far this is the first screen I've needed the list in because for Case Types there are a few hundred possible values. The values begin with a number followed by a description. Using a Spinner/Combobox or Listview involves too much scrolling. The Autocomplete functionality is perfect for this. The user types "Robbery" and the list pops up showing the 4-5 values containing that word, or they can start typing the number and it is filtered to it and they can select the one they need. It works kind of like a Windows Combobox that you can type in only with better item matching.
I made them all AutoComplete just to have a base control to work with that does it all. It appears in every way to be just like a Plain edit other than the list, so I figured it wouldn't hurt to just have it available. So far this is the first screen I've needed the list in because for Case Types there are a few hundred possible values. The values begin with a number followed by a description. Using a Spinner/Combobox or Listview involves too much scrolling. The Autocomplete functionality is perfect for this. The user types "Robbery" and the list pops up showing the 4-5 values containing that word, or they can start typing the number and it is filtered to it and they can select the one they need. It works kind of like a Windows Combobox that you can type in only with better item matching.
B4X:
'Activity module
Sub Process_Globals
'These global variables will be declared once when the application starts.
'These variables can be accessed from all modules.
End Sub
Sub Globals
'These global variables will be redeclared each time the activity is created.
'These variables can only be accessed from this module.
Dim textboxes(3) As AutoCompleteEditText
Dim IME As IME
End Sub
Sub Activity_Create(FirstTime As Boolean)
Dim ref As Reflector
IME.Initialize("IME")
For i= 0 To 2
textboxes(i).Initialize("")
textboxes(i).TextSize= 18
IME.AddHandleActionEvent(textboxes(i))
ref.Target = textboxes(i)
ref.RunMethod2("setImeOptions", Bit.Or(268435456, 5), "java.lang.int") 'flagNoExtractUi= 268435456, Next Button= 5
If i = 1 Then
textboxes(i).SetItems(Array As String("ABC", "123", "DEF", "456"))
End If
Activity.AddView(textboxes(i), 5dip, i * 50dip + 5dip, 100%x - 10dip, 50dip)
Next
End Sub
Sub Activity_Resume
End Sub
Sub Activity_Pause (UserClosed As Boolean)
End Sub
Private Sub IME_HandleAction As Boolean
Select Case Sender
Case textboxes(0)
textboxes(1).RequestFocus
Case textboxes(1)
textboxes(2).RequestFocus
Case textboxes(2)
textboxes(0).RequestFocus
End Select
End SubIt appears to be a combination of a few things. I was under the impression that returning false in the IME HandleAction closed the keyboard, so when an Edit/Autocomplete View got focus I was showing the keyboard. Showing the keyboard seems to be what caused it to blow up. After removing that it no longer froze and the keyboard stayed open. I had modified this to allow for showing the autocomplete list when a view that already had focus got focus again and not have the keyboard in the way. (Tap Twice or on a Label that I had set focus to an Edit View and it would show the list)
From the documentation I had gathered that the return value only controlled the keyboard state which it appears it really has nothing to do with. The return value is more of a stop point more like Windows message loops in that returning True doesn't pass it along for default processing. Returning True allows me to control navigation and returning False allows Android to navigate (Which for the most part went to the same controls except in that one location).
Returning True keeps it how I expect it and the keyboard honors the action buttons and View Input Types...not the Return Value. I'm guessing since my focus changes were the same as Android's the showing keyboard on focus worked fine, but when I focused to my next in line and Android focused to a different one there must have been some endless loop condition internally.
From the documentation I had gathered that the return value only controlled the keyboard state which it appears it really has nothing to do with. The return value is more of a stop point more like Windows message loops in that returning True doesn't pass it along for default processing. Returning True allows me to control navigation and returning False allows Android to navigate (Which for the most part went to the same controls except in that one location).
Returning True keeps it how I expect it and the keyboard honors the action buttons and View Input Types...not the Return Value. I'm guessing since my focus changes were the same as Android's the showing keyboard on focus worked fine, but when I focused to my next in line and Android focused to a different one there must have been some endless loop condition internally.
Last edited: