HI,

We are working with version 2.2 to create an on screen keyboard tool which contains a textbox to display the characters which are being typed and wish for this textbox to display the caret indicator.

We wait for a textbox on screen to be focused and then inside our 'SetSoftwareKeyboardCallback' function programmatically create and display our on screen keyboard control. As part of this show process we call Focus() on the new text box item which is part of the on screen keyboard and see that the call to Focus() returns true. However the caret indicator is not displayed in the new textbox, it remains displayed in the first textbox which was focused.

It was my understanding that after the call to Focus() returns true that textbox should now be displaying the caret, are there additional steps required?

Hi,

I tried to reproduce your scenario to see what was happening with the focus but noticed something. If you are changing the focus to another TextBox when showing your software keyboard control then the SetSoftwareKeyboardCallback will be called again to hide it (because original TextBox will lose the focus). How are you dealing with that?

If I detect that focus change to avoid closing the software keyboard in that case, then the caret correctly moves to the textbox inside my software keyboard control. But the code I had to write seems a bit hacky.

Are you showing the software keyboard using another View to avoid this?

If you are using a single View, could you please handle PreviewGotKeyboardFocus event and add some logs or breakpoints to identify when the focus comes back to the original TextBox?

We are not using a separate view. We create our keyboard custom control in code-behind and attach it to the existing panel. When we create the on screen keyboard widget we also call Focus() one on of its button components so that we can then navigate within that control using a game pad with KeyboardNavigation.DirectionalNavigation="Cycle".

It seems that we may not be receiving the request to hide the keyboard, which I think would mean the first text box has not given up focus? I have printed a few logs from our SetSoftwareKeyboardCallback and PreviewGotKeyboardFocus events and we get the following

For context, our view contains a TextBlock element displaying a first name. When the 'a' button is pressed on this TextBlock an overlay view containing the TextBox to type into is shown. We then call Focus() on the now visible TextBox to enable text input

INFO: ********Host textbox focused manually********
INFO: ********The host text box preview is being called********
INFO: ********SetSoftwareKeyboardCallback called. Show********
INFO: ********Call focus on Clear button returned true********
INFO: ********The preview of the attached text box has been called******** //on navigating into the textbox
INFO: ********SetSoftwareKeyboardCallback called. Show******** //on pressing 'a' on the attached textbox

For reference the line of manual focus corresponds to a function that does the following

Why did you call m_firstNameTextbox->SetSupportsFocusEngagement(false); before manually focusing the TextBox?
You don't need to do that when focusing from code. That property should only be set to false if you want a TextBox that shows software keyboard when navigating from gamepad without pressing the 'A' button.

Anyway, I now see why you are not receiving the SetSoftwareKeyboardCallback, there is a bug in the TextBox (solved in 3.0) when SupportsFocusEngagement is disabled. I've just fixed it in branch 2.2 for you (revision 9686). With that change you will see that the callback is being correctly called indicating software keyboard should hide.

So back to my initial thought, independently of the value of SupportsFocusEngagement, if you remove the focus from the original TextBox you will be called to hide the software keyboard. So my suggestion is to use a separate View to show the software keyboard, call HideCaret() on the original TextBox, and redirect input to the software keyboard View until it gets closed. Do you think that would work in your case?

Thank you for the reply.

Regarding the call to SetSupportsFocusEngagement that is apparently being called to allow pressing 'b' to cancel name input to work without having to press twice when the first name textbox has focus. That function was put in before we had implemented our on screen keyboard control. I will check if it is still needed.

I believe making use of a separate view may be possible for our case, I will try and implement your idea

Regarding the call to SetSupportsFocusEngagement that is apparently being called to allow pressing 'b' to cancel name input to work without having to press twice when the first name textbox has focus. That function was put in before we had implemented our on screen keyboard control. I will check if it is still needed.

In that case setting SetSupportsFocusEngagement to false made sense. Now with software keyboard maybe the workflow is different and you want to enable focus engagement, so you can show it pressing 'A' and hide it pressing 'B', without losing the focus on the TextBox.