locked
Is there a way to suppress the onscreen keyboard from popping up? RRS feed

  • Question

  • Is there a way to keep the onscreen keyboard from popping up when a textbox is selected?  I still want the user to be able to input stuff when there is a physical keyboard attached to the device.  So, the IsReadOnly = "true" is out of the question. 

    Thursday, September 26, 2013 8:46 AM

Answers

  • No. The onscreen keyboard is controlled by the user, not the app. If the user taps to set focus to an input control then the input pane will open. The only way to avoid this is not to get into that situation.

    If you are validating the changes in the text boxes themselves then the onscreen keyboard shouldn't be able to bypass your filter. I don't understand how the input panel hinders that.

    That said, you have several options:

    Use a TextBlock (or read only TextBox) and handle the CoreWindow.CharacterReceived event to receive character input (the KeyDown event won't give you the information you need). I believe this is essentially what the Calculator app does. This has the downside that it will block more than the soft keyboard: it will block the stylus, interfere with speech recognition, etc.

    Make the UI more context sensitive. Listen to the InputPane classes so you know when and where it shows, and when it opens move your special keys out from underneath it. You can remove any keys which are easy to get to from the input pane (normal letters and numbers) from your special keys to make room. This will provide the most choice to the user and will allow your app to work well with speech recognition, stylus, etc.

    Use Matt's suggestion to give the user a setting to switch between a TextBlock and a TextBox (or to toggle IsReadOnly)

    You may be able to combine a few things and present a read only TextBlock but internally set focus to an obscured TextBlock. Since the user can't tap on it they shouldn't automatically get the input pane, but they could open it themselves if they want to use the stylus. I haven't tried this, so be wary of side-effects.

    --Rob

    Friday, September 27, 2013 1:34 AM
    Moderator

All replies

  • If there's a physical keyboard attached, the OSK should not be activated.  It might appear for a second, but then will disappear.

    Matt Small - Microsoft Escalation Engineer - Forum Moderator
    If my reply answers your question, please mark this post as answered.

    NOTE: If I ask for code, please provide something that I can drop directly into a project and run (including XAML), or an actual application project. I'm trying to help a lot of people, so I don't have time to figure out weird snippets with undefined objects and unknown namespaces.

    Thursday, September 26, 2013 12:41 PM
    Moderator
  • I'm aware of that.  I do not want the onscreen keyboard to pop up even without physical keyboard.
    Thursday, September 26, 2013 4:43 PM
  • The input pane is controlled by the user, not the app. It will appear when the user touches a text input control (whether a physical keyboard is attached or not is not relevant). See The touch keyboard for details.

    Why do you want to have a control that accepts input but that the user cannot use? How are users who don't have a keyboard supposed to use your app? What is the scenario here?

    --Rob

    Thursday, September 26, 2013 5:12 PM
    Moderator
  • My app is ported in from a desktop app.  It involves chemistry calculations.  Its for chemists and students.  The UI already has everything they need to input the chemical compounds and values.  I'm experimenting letting people input through the keyboard because it is faster.  On a touch screen it is faster and more accurate to use the UI I already made for them.  The onscreen keyboard will only hinder that. 

    The other thing is this.  Ive built in checkers to keep people from putting in nonsense.  The onscreen keyboard hinders that as well.

    Thursday, September 26, 2013 5:34 PM
  • Solution: don't use a textbox for input.  Allow users to "optimize" between keyboard input and touch input.

    Matt Small - Microsoft Escalation Engineer - Forum Moderator
    If my reply answers your question, please mark this post as answered.

    NOTE: If I ask for code, please provide something that I can drop directly into a project and run (including XAML), or an actual application project. I'm trying to help a lot of people, so I don't have time to figure out weird snippets with undefined objects and unknown namespaces.

    Thursday, September 26, 2013 5:39 PM
    Moderator
  • I'd leave the choice up to the user. Some will prefer the input pane. The only way to disable it will also disable other input modes and can interfere with accessibility and globalization.

    The onscreen keyboard shouldn't hinder validation: that sounds more like a bug in the validation code. The app needs to validate the data after it's been entered, not try to validate one path into the app and then put gates up over the others. It shouldn't matter where the input comes from and the on-screen keyboard isn't the only alternate to the physical keyboard. Just watching keystrokes will also miss speech, handwriting, cut & paste, etc.

    --Rob

    Thursday, September 26, 2013 6:18 PM
    Moderator
  • You don't understand.  The reason I have to put in filters is because... again chemistry.  For example, H₂O is fine, but if the user puts in H₂o then it's not ok.  That's why I have to put in filters and then eventually designed my own custom chemistry input UI.

    You know how users are with the blame game.  They put in a long and complicated chemical equation like

    Cr₇N₆₆H₉₆C₄₂O₂₄+MnO₄⁻¹+H⁺¹⇌Cr₂O₇⁻²+mn⁺²+CO₂+NO₃⁻¹+H₂O and when the calculations doesn't pan out because there's a typo in there instead of going back and check for a typo they write an ugly hate mail to me.

    That's why on the desktop version of my app I stopped letting them input the equations directly and instead they have to input using a periodic table type interface.  Because of user complaints, I've recently allowed them to input the equations via the keyboard directly again but with filters.  So, my desktop app will go back and read their equation and spot the error. 

    I've already experimented with touch and it's 10 times as hard to input an ionic equation like that using the onscreen keyboard.  So, I'd rather they just use the built in number pad and periodic table.  Right now, I have the textbox input disabled.  So, if they use the metro version they have to use the number pad and the periodic table I provided.  What I'm trying to do now is if they have a physical keyboard they can still input the equation using their keyboard. 

    Again, look at the equation I posted above.  It's simply not practical to use the onscreen keyboard to input something like that.  But it is very practical to input it via the physical keyboard. 

    Thursday, September 26, 2013 7:12 PM
  • You misunderstand me. I agree that you need to do validation, but doing it on keystroke is doomed to failure.

    Instead, watch what has been entered and validate that. You can do this on TextChanged and provide feedback to the user that their formula is invalid. You can remove any completely invalid characters and mark any logical errors so the user can fix them without being blocked from entering partial data.

    Thursday, September 26, 2013 7:23 PM
    Moderator
  • That's what my validator is already doing.  It's not watching for the keystrokes. It's reading the input textboxes.

    The reason I don't want the onscreen keyboard to pop up is because inputting a chemical equation using the onscreen keyboard is a pain in the butt.  Based on my experience with users, they will complain about everything.  When they click on a textbox and the onscreen keyboard pops up, they will feel obligated to use the onscreen keyboard instead of ignoring it and proceed to use the built in periodic table and number pad.  And then 6 ionic compounds later they write me a hate mail or give me a 1 star in the store.

    So, is there a way to disable to onscreen keyboard for the app or not?

    Thursday, September 26, 2013 7:35 PM
  • >So, is there a way to disable to onscreen keyboard for the app or not?

    No, but if you leave your TextBox as IsReadOnly=true, you can handle KeyDown events on its parent Panel.  You have to provide all the editing behavior, but since you are inputting special formulas, that's perhaps a good thing, as you can prevent invalid characters and perhaps implement shortcut keys.  eg

     private void StackPanel_KeyDown(object sender, KeyRoutedEventArgs e)
            {
                
                if (e.Key == Windows.System.VirtualKey.Tab || e.Key == Windows.System.VirtualKey.Enter)
                {
                    e.Handled = false;
                    return;
                }
                if (e.Key == Windows.System.VirtualKey.Back)
                {
                    if (tb.Text.Length > 0)
                    {
                        tb.Text = tb.Text.Substring(0, tb.Text.Length - 1);
                    }
    
                }
                else
                {
                    tb.Text = tb.Text + e.Key.ToString();
                }
                e.Handled = true;
            }


    David


    David http://blogs.msdn.com/b/dbrowne/



    Thursday, September 26, 2013 8:18 PM
  • No. The onscreen keyboard is controlled by the user, not the app. If the user taps to set focus to an input control then the input pane will open. The only way to avoid this is not to get into that situation.

    If you are validating the changes in the text boxes themselves then the onscreen keyboard shouldn't be able to bypass your filter. I don't understand how the input panel hinders that.

    That said, you have several options:

    Use a TextBlock (or read only TextBox) and handle the CoreWindow.CharacterReceived event to receive character input (the KeyDown event won't give you the information you need). I believe this is essentially what the Calculator app does. This has the downside that it will block more than the soft keyboard: it will block the stylus, interfere with speech recognition, etc.

    Make the UI more context sensitive. Listen to the InputPane classes so you know when and where it shows, and when it opens move your special keys out from underneath it. You can remove any keys which are easy to get to from the input pane (normal letters and numbers) from your special keys to make room. This will provide the most choice to the user and will allow your app to work well with speech recognition, stylus, etc.

    Use Matt's suggestion to give the user a setting to switch between a TextBlock and a TextBox (or to toggle IsReadOnly)

    You may be able to combine a few things and present a read only TextBlock but internally set focus to an obscured TextBlock. Since the user can't tap on it they shouldn't automatically get the input pane, but they could open it themselves if they want to use the stylus. I haven't tried this, so be wary of side-effects.

    --Rob

    Friday, September 27, 2013 1:34 AM
    Moderator
  • Thank you for your answer.

    I have decided to stick with my control freakish way for the metro version.  This means the IsReadOnly to remain true always.  They will have to input using the buttons I've provided, which will simply add the correct syntaxes to the textboxes.

    Over in the desktop side of things, I've enabled the input ability in the textboxes.  However, those textboxes are guarded by filters that will auto-correct known mistakes and cry bloody murder when the user inputs nonsense.

    Now, onto the 3-D modelilng!

    Sunday, September 29, 2013 8:40 AM