wpf - WindowStyle None and touch input

Question

In Windows 10, when using touch device like Surface, touching an input control like a TextBox in a not maximized window, causes moving the whole window up, so that the user can see what he is typing (if keyboard is docked). But it does not happen when WindowStyle is set to none. Why it does not happen? We need this behavior in our app. Can it be fixed on WindowStyle=None? I found it's not connected with it's style - there are no build in triggers or something. We need WindowsStyle=None for custom close button bar (we want the bar to be transparent, only the button is visible).

Answer 1

I faced a similar issue trying to get my application to react to the presence of the Windows 10 touch keyboard properly, but it wouldn't do so unless WindowStyle was set to something other than None.

Struggled with it for a while, until I decided to just try and style the Window myself and removing the borders manually, which led me to discover the WindowChrome class.

The WindowChrome documentation mentions this about WindowStyle="None":

One way to customize the appearance of a WPF application window is to set the Window.WindowStyle property to None. This removes the non-client frame from the window and leaves only the client area, to which you can apply a custom style. However, when the non-client frame is removed, you also lose the system features and behaviors that it provides, such as caption buttons and window resizing. Another side effect is that the window will cover the Windows taskbar when it is maximized. Setting WindowStyle.None enables you to create a completely custom application, but also requires that you implement custom logic in your application to emulate standard window behavior.

So it seems that because this non-client (or OS) frame is missing, it causes the application to not be able to react to the keyboards presence.

The solution is to implement a custom WindowChrome. This can be done like this:

<Window x:Class="WpfApp.MainWindow"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:shell="clr-namespace:System.Windows.Shell;assembly=PresentationFramework"
    Title="MainWindow" Height="350" Width="525" WindowState="Maximized">
    <shell:WindowChrome.WindowChrome>
        <shell:WindowChrome NonClientFrameEdges="None"
                            UseAeroCaptionButtons="False"
                            CornerRadius="0"
                            GlassFrameThickness="0"
                            ResizeBorderThickness="0"
                            CaptionHeight="0" />
    </shell:WindowChrome.WindowChrome>

    <Grid Background="DarkOrange">
        <TextBlock Text="TEST" VerticalAlignment="Center" 
                   HorizontalAlignment="Center" FontSize="32" />
    </Grid>
</Window>

If you absolutely must use WindowStyle="None", then according to the documentation above, the Window logic must be custom. Fortunately there's a nice example from Microsoft on how to write custom logic to react to the presence of a touch keyboard: See this link.

If you would like to add your own custom buttons to the title bar, check out this excellent post about styling your Window.

Hope this helps!

UPDATE:

After further investigation, it turned out that this solution only worked on Windows 10 version 1903. When tried on 1809 which we use in production, it didn't work. The reason is that apparently Microsoft have changed the way applications react to the touch keyboard when in full-screen mode.

This can be easily tested by maximizing Explorer in both versions of Windows, and to see how in 1809 nothing happens, but in 1903 the Window is resized to fit the remaining space on the screen.

Another important thing I noticed is that when I start the application from Visual Studio (whether debugger is attached or not), when the touch screen shows up, the UI doesn't react to it, but when I run the executable from explorer, then it does work. So in my testing I would always build, then go to binDebug, and start the exe from there.