locked
How can I avoid losing the soft keyboard in Cocos2d-x?

    Question

  • MS Open Technologies recently made a venture into cocos2d-x with their WinRT setup, but regrettably it is quite unfinished.  Here is the scenario I am trying to avoid:  

    1) Show soft keyboard via attachWithIME()

    2) Press the keyboard hide button on the soft keyboard

    3) Further calls to the same API no longer show the keyboard.

    Behind the scenes this is what happens.  There is an invisible button and an invisible text box inside of the window rendering OpenGL.  When attachWithIME() is called, the Focus method is called on the text box (with FocusState::Pointer as an argument).  However, after the keyboard is hidden, further calls to Focus on the text field do nothing (this seems to be by design...).  When the keyboard gets hidden, I set up my project to call detachWithIME() which calls Focus on the invisible button instead, and disables the text field.  However, as stated before, further calls to attachWithIME() are meaningless.  If I switch to the desktop, push the keyboard button, and switch back then everything is fine again, but I think everyone can agree that forcing the user to do that is outrageous.  

    So, I am looking for a way to amend cocos2d-x to avoid this unwanted behavior.  What can I do?

    Monday, July 07, 2014 3:26 AM

Answers

  • Whoops. Sorry about that. I thought that sample demoed for DX not just for custom Xaml controls. The concepts are the same: the DX app can and should implement ITextProvider to tell windows that it has a text control. This will allow Windows to see that the user set focus to a text control and pop up the input pane.

    The bug your users are complaining about is caused by trying to rely on a hack rather than implementing the text pattern properly. Programmatically setting the focus to a TextBox is not expected to always pop up the input pane. In particular, if the user had specifically closed the input pane then the app shouldn't be able to programmatically override that.

    In your case the problem is that since your text input isn't set up correctly the user can't set the focus by touch to bring up the input pane. Detecting the touch and then programmatically setting the focus isn't the same thing.

    There won't be any way to get this to work right with the hack. The only way to get this to work correctly will be for you (or cocos2d-x) to implement the text automation patterns. See UI Automation Text Pattern

    --Rob

    Wednesday, July 16, 2014 9:19 PM
    Owner

All replies

  • You'll have to check with the cocos2d-x folks.

    The API you're talking about aren't Windows Store API that folks on this forum are likely to be familiar with.

    --Rob

    Monday, July 07, 2014 7:46 PM
    Owner
  • Actually I have since confirmed this problem in XAML applications as well.  It seems that if the users hides the keyboard, then the ONLY way to get it back is either to show it again via the side charm, or click on a valid XAML control (setting the focus will not work).  The touch keyboard white paper seems to indicate that this is on purpose.  Is that right?  If so, that's a problem for cocos2d-x since it uses DirectX rendering instead of XAML controls.
    Tuesday, July 08, 2014 1:10 AM
  • The user is supposed to be in charge. If the user explicitly hides the input pane then it shouldn't come back except through user action.

    The input pane shows based on the accessibility patterns provided by the focused control. Those can (and should) be implemented by DirectX apps for text handling rather than trying to hack up a programmatic solution with hidden controls.

    Xaml controls implement text patterns and so act appropriately themselves, but they are not doing anything magical and are not required for proper input pane handling. The Input: Touch keyboard sample demonstrates implementing these patterns for custom controls.

    --Rob

    Wednesday, July 16, 2014 12:05 AM
    Owner
  • I understand Microsoft's stance on the user being in charge.  However, most of the people at my company don't understand this way of doing things.  They see the inability to tap on something and have the keyboard pop out as a bug.  The Touch keyboard sample was very helpful, but it cannot be applied as far as I can tell and I will explain why.  Cocos2d-x has created its own ecosystem of reference counted classes that must be derived from `CCObject` (which is a regular C++ class).  In particular, to be added to a view hierarchy it must be derived from `CCNode`.  However the examples in the sample must be derived from `UIElement` (which is a WinRT ref class) to be able to use `OnCreateAutomationPeer`.  There does not seem to be a possible way to derive from both as far as I can tell.  This is likely the reason that cocos2d-x, for which the WinRT version was written by Microsoft Open Technologies, does things the way it does for the cocos2d-x text input control (programmatic solution with a hidden control).  

    Thank you for your assistance.  In fact I don't wish to hack a solution to anything, but I am going to have to stick with my hacked solution in this case unless there is any further information.

    Wednesday, July 16, 2014 1:42 AM
  • Whoops. Sorry about that. I thought that sample demoed for DX not just for custom Xaml controls. The concepts are the same: the DX app can and should implement ITextProvider to tell windows that it has a text control. This will allow Windows to see that the user set focus to a text control and pop up the input pane.

    The bug your users are complaining about is caused by trying to rely on a hack rather than implementing the text pattern properly. Programmatically setting the focus to a TextBox is not expected to always pop up the input pane. In particular, if the user had specifically closed the input pane then the app shouldn't be able to programmatically override that.

    In your case the problem is that since your text input isn't set up correctly the user can't set the focus by touch to bring up the input pane. Detecting the touch and then programmatically setting the focus isn't the same thing.

    There won't be any way to get this to work right with the hack. The only way to get this to work correctly will be for you (or cocos2d-x) to implement the text automation patterns. See UI Automation Text Pattern

    --Rob

    Wednesday, July 16, 2014 9:19 PM
    Owner