Unable to use symbols after saveas used

Hi Paul,

I tried to repro this on the Surface but was unsuccessful.  Everything seemed to work as expected.  Can you give exact repro steps starting with no documents open?  Thanks!

To replicate close out all documents. create a new HTML file. select save as and hit backspace, erasing content. enter a new file name and tap save. After doing so you should no longer have access to those keys using the screenboard

One thing I forgot to mention is that after hitting backspace i accidentally hit the &123 key to show numbers and symbols. I dont remember doing that the first time though.

Hi Paul,

I can repro it now, thanks.  After looking into it, we may be in a pickle.  Basically SyntaxEditor (our custom code editor control) is used as the code editor here.  We implement some code to allow the keyboard to show when its tapped for focus.

I think what's happening is that when we call the Windows Save dialog, the dialog is telling the soft keyboard to switch to a certain "input scope" (think of it like a hint for what keys should be enabled and show) that is appropriate for file names.  Standard TextBox controls have an InputScope property we can set but that does us no good here since our control is custom and doesn't inherit TextBox.  I've been searching the WinRT framework Microsoft provides to us and unfortunately don't see anything that looks like it would help either.

My next step is to context some folks in the text/input team at Microsoft to see what options are.

I found a workaround for when you get into this mode.  Slide out the charms and click the Search charm.  The TextBox there will tell the soft keyboard to return to "normal" input scope and it seems to carry over into the app too.

As a C# / Winrt developer myself I hate to suggest this, but have you considered adding a hidden textbox that takes focus after saving to change the inputScope, and then programmatically swap focus back to the custom editor box? Alternatively you could work some inheritance magic with generics to solve it. Assuming im not completely off base.

Hi Paul,

We have a workaround in place for this that will go live in the next version (v1.2).  We are waiting to hear a reply from Microsoft if there is a better way to handle this than our workaround too.