Android Question IME.HideKeyboard

[LucaMs]

I just now noticed that hiding the keyboard in an event EditText1_FocusChanged then it does not even appear in EditText2_FocusChanged (that is, it is a final closure until next ShowKeyboard).

This depends on B4A or Android?

 

[Erel]

The behavior depends on Android. If you like create a simple project and upload the code.

 

[LucaMs]

It is not a big problem, even if forces you to manage the opening in another part of the code.

I noticed this while I gave a hint, then the sample project is ready.

 

[Erel]

You are not checking the value of HasFocus. The event first fires when EditText1 is focused and then when EditText1 loses focus.

 

[LucaMs]

What I have to say? L O L

 

[TheWind777]

What I have to say? L O L

Back to the task at han... this method should do exactly what I want with no flicker of a keyboard trying to pop-up. That is extremely unprofessional and can't be used in commercial products.

This, in theory, should work... but doesn't. Why?

Sub Globals

   PrivateHideKeyboard As IME : HideKeyboard.Initialize("IME1")
   DimStopKeyboardAsReflector
   DimEditTextWBLessonAsEditText

End Sub

Sub Activity_Create(FirstTime AsBoolean)

   EditTextWBLesson.Initialize("EditTextWBLesson")
   Activity.AddView(EditTextWBLesson,0,0,300dip,300dip)

   EditTextWBLesson.Text = "This is a test."

   StopKeyboard.Target = EditTextWBLesson
   StopKeyboard.SetOnKeyListener("NoKeyboard")


   ' Also tried StopKeyboard.SetOnKeyListener(Null), which should have worked

   DoEvents

End Sub



Sub NoKeyboard(viewtag AsObject, keycode AsInt, keyevent AsObject) AsBoolean

   Log("NoKeyboard Entered")
   HideKeyboard.HideKeyboard

   ReturnTrue' This Sub must return True if it wants to consume the event or False otherwise.

End Sub

 

[TheWind777]

You are not checking the value of HasFocus. The event first fires when EditText1 is focused and then when EditText1 loses focus.

Here is the code that I am actually using:

Sub EditTextWBLesson_FocusChanged (HasFocus AsBoolean)

IfPGDebugging4ThenLog(" +++ Begin of EditTextWBLesson_FocusChanged")



If HasFocus Then

IfPGDebugging4ThenLog("EditTextWBLesson_FocusChanged - Keyboard.HideKeyboard")

Keyboard.HideKeyboard

EndIf



IfPGDebugging4ThenLog(" --- End of EditTextWBLesson_FocusChanged")

IfPGDebugging4ThenLog(" ")

End Sub

I have always been checking the HasFocus variable. It does not work.

Next, I tried doubling-up that with this one:

Sub EditTextWBLesson_Click

IfPGDebugging4ThenLog(" +++ Begin of EditTextWBLesson_Click")



Keyboard.HideKeyboard



IfPGDebugging4ThenLog(" --- End of EditTextWBLesson_Click")

IfPGDebugging4ThenLog(" ")

End Sub

That method does not work in my particular situation.

It SOMETIMES works the first time you click on the keyboard.

The reason is... my program is doing intricate things in the background; there's no way you can ensure that their EditText box is going to keep focus for the entire time that the guy is typing.

Hidden in the background is a queue timer that checks the timer queue. As it counts-down, it writes that information to an EditText box in a completely different panel. It then writes more information into an EditText box in yet another panel.

So, will never be able to guarantee any focus will be constant on the EditText box the guy is working in. Therefore, I need to disable the KeyListener for their EditText box.

Tiny little examples which are in perfect worlds just don't work in the real word of Android programming. In the case of having the keyboard go-away, it just isn't yet being done in the right way.

I also have notifications being written from the service module, many different EditText boxes being updated constantly. Etc. Any intricate program does intricate things, and any method which stops the keyboard has to take all things such as that into account.

So, no, simple 'HasFocus' checks is going to keep the keyboard away, in my case. A complete disabling of the KeyListener for their EditText box is needed.

 

[TheWind777]

You are not checking the value of HasFocus. The event first fires when EditText1 is focused and then when EditText1 loses focus.

That's in a simple world where you have the focus and keep it forever until you are done.

The problem with that method, any way you look at it, is that very unprofessional flicker where the keyboard tries to open.

By the research I did, if you send a Null to the KeyListener, the keyboard doesn't pop up, yet you retain the copy/paste capability.

If the example I just posted actually went to the NoKeyboard sub (as it should-have, I would say), then a sending of Null to it should, then, also work.

However, for unknown reasons the reflector is NOT sending the Key information to the NoKeyboard sub.

Why?

Is there some 'Set it to do it now' line I have to add to the Reflector code after I have set the name of the Key Listener sub?

 

[TheWind777]

That's in a simple world where you have the focus and keep it forever until you are done.

The problem with that method, any way you look at it, is that very unprofessional flicker where the keyboard tries to open.

By the research I did, if you send a Null to the KeyListener, the keyboard doesn't pop up, yet you retain the copy/paste capability.

If the example I just posted actually went to the NoKeyboard sub (as it should-have, I would say), then a sending of Null to it should, then, also work.

However, for unknown reasons the reflector is NOT sending the Key information to the NoKeyboard sub.

Why?

Is there some 'Set it to do it now' line I have to add to the Reflector code after I have set the name of the Key Listener sub?

Once this works... we'll have an actual real way to stop the keyboard from EVER coming up for any particular EditText box. Yayyyy.

Now, let's just go that one step further that makes it do it.

 

[TheWind777]

What I have to say? L O L

Well, I almost get rid of the keyboard completely by waylaying the Touch Event.

I do a:

Dim Keyboard As IME

Keyboard.Initialize("Keyboard")

DimRemoveKeyboardForWB As Reflector
DimRemoveKeyboardForACIM As Reflector

RemoveKeyboardForWB.Target = EditTextWBLesson
RemoveKeyboardForWB.SetOnTouchListener("OnWBTouch")

Then, for subs I do:

Sub OnWBTouch(viewtag AsObject, action AsInt, X AsFloat, Y AsFloat, motionevent AsObject) AsBoolean
   Keyboard.HideKeyboard
   ReturnFalse
End Sub

Sub EditTextWBLesson_FocusChanged (HasFocus AsBoolean)
   If HasFocus Then
      Keyboard.HideKeyboard
   EndIf
End Sub

Sub EditTextWBLesson_Click

   Keyboard.HideKeyboard
End Sub

It's still not perfect-perfect. There's one small time when the keyboard appears, then goes away.

For unknown reasons, the KeyListener never seems to trigger, and setting it to Null does nothing.

RemoveKeyboardForWB.SetOnKeyListener("OnWBKey")
' RemoveKeyboardForWB.SetOnKeyListener(Null)  ' also doesn't work

Sub OnWBKey(viewtag AsObject, keycode AsInt, keyevent AsObject) AsBoolean
   Keyboard.HideKeyboard
   ReturnTrue
End Sub

However, adding the Touch Event does what I want. I can now press long on a word and it highlights. Then copy to the clipboard. From that I can then find the sentence they clicked. Yayyy.

Good enough.

 

[LucaMs]

My LOL:

I laughed to myself.

For the fact that I had not noticed that the keyboard was hidden twice, thinking instead that it was definitely hidden.

 

[TheWind777]

My LOL:

I laughed to myself.

For the fact that I had not noticed that the keyboard was hidden twice, thinking instead that it was definitely hidden.

I wonder why the 'setting to null' did nothing (or, for that matter why the KeyListener never triggers at all?

Why touch does so well is... it keeps doing it. So, when the system misses (or is really slow to respond to) the Keyboard Hide, the machine-gun attack of Hides definitely works.

I wish I could get the keyboard to go away for good... but this method actually works pretty well now. It rarely pops-up the keyboard any more. Thanks for your help.

...

Next problem is... Ever seen the keyboard be fooled, and it pops up on a panel that doesn't even have an EditText box on it? It seems like it is seeing 'through' the panel to the panel beneath? Why would a textbox that is hidden by another panel be causing the keyboard to respond? Any thougts?

I'm also dimming a panel behind it to simulate a modal dialog... and that panel also acts 'invisible' to clicks, allowing them 'through' the panel. I mean, yes, he alpha channel is on so the background 'shows-through'... but that shouldn't allow clicks on underlying panels to trigger, I would think.

My questions are never easy ones.

Look at it this way... if *I* have a problem, it's a doozey. I can figure-out lesser problems. The ones I have are the ones that plague everybody... but I don't just agree to slipshod methods. That keyboard thing still bugs me. I'll get it. I know nobody ELSE has succeeded yet; but my inability to accept such shoddy behavior from an operating system generally leads me to an answer, in the end.

Android is the only operating system I've ever seen where you have to do things like do something twice... because the first time it didn't take... What? That's called 'A Major bug' in my book.

 

[TheWind777]

My LOL:

I laughed to myself.

For the fact that I had not noticed that the keyboard was hidden twice, thinking instead that it was definitely hidden.

Yeah... The best word which can be placed upon the keyboard's actions is 'S0METIMES'.

Sometimes it comes up when you DON'T want, or even need, it. And when you want it to go away? It's like some annoying friend who keeps knocking at your door at 11 PM and you stand there staring at them thinking maybe they'll get the hint, but they never do.

 

[TheWind777]

My LOL:

I laughed to myself.

For the fact that I had not noticed that the keyboard was hidden twice, thinking instead that it was definitely hidden.

Oh, Since I modified the Touch Listener... that mean my Listener Sub is getting all Touch events, it would seem. Hmmm. Interesting. I think that might be why the keyboard is popping-up 'through' the panel. Once I understand what it's doing, that could be a very helpful function to understand fully. I also (in my experimenting) grabbed all the 'other' listeners. No wonder why I'm having strange things happening. Makes me understand better what that function is doing, though.

I will have to turn off the unnecessary ones and then do some if-thens on the Touch Listener. Should work fine after I've done the right things.

 

[cbal03]

Just read through this thread looking for a way to hide the soft keyboard and noticed this..

"Next problem is... Ever seen the keyboard be fooled, and it pops up on a panel that doesn't even have an EditText box on it? It seems like it is seeing 'through' the panel to the panel beneath? Why would a textbox that is hidden by another panel be causing the keyboard to respond? Any thougts?"

If you want a "modal"panel you can catch the panel's click event with:

sub panel_Click
'leave empty, nothing to do
End Sub

This will stop the "touch through" to the underlying editText.