99

I am developing a WPF application which will be displayed in Full screen. In addition, the application should work on many tablets of multiple dimensions. I'd like my application to run in full screen independently from its dimensions.

What is the best practice to accomplish this task?

B. Semchuk
  • 15
  • 1
  • 9
Lamloumi Afif
  • 8,129
  • 23
  • 79
  • 175

3 Answers3

192

Just set the WindowState to Maximized, and the WindowStyle to None.

Thomas Levesque
  • 270,447
  • 59
  • 580
  • 726
  • 6
    Also setting the Window as topmost will make sure no other Window shows up over your window. – Yash Gadhiya Nov 05 '13 at 07:48
  • 11
    @YashGadhiya Which you should never do. – Glenn Maynard May 18 '14 at 00:22
  • 2
    @GlennMaynard there are use cases where it's acceptable. A customer right now requires an app that can never ever have anything above it unless the app is closed. – Halaster May 20 '14 at 11:39
  • @LucasCordina That doesn't make it acceptable, it just means you're being paid to do something bad. – Glenn Maynard May 20 '14 at 23:12
  • @GlennMaynard Out of genuine curiosity, can you elaborate as to why using Topmost is bad? Take into consideration apps which need the machine to function as a kiosk temporarily, for instance. – Halaster May 21 '14 at 01:10
  • 8
    @LucasCordina If you're a kiosk app and you want to keep other applications from taking focus, putting yourself topmost isn't the solution. Topmost just *renders* you on top--if there's something else that can take focus, it still will, you just won't be able to see it. – Glenn Maynard May 21 '14 at 01:28
  • 10
    (And in case it's not obvious, Yash's blind "also set Topmost" recommendation is a very bad one, because if a typical application that's are trying to fullscreen does it, you end up with one of those broken fullscreen applications that leaves you blind and fumbling when you try to alt-tab to something else. I don't know why Windows even lets you do that--no application should ever be able to break the desktop that badly.) – Glenn Maynard May 21 '14 at 01:31
  • Ahhh, I wasn't aware of that! I concede, I can't think of any reason one would want to use TopMost (other than use because of misinformation). Thank you. – Halaster May 21 '14 at 01:33
  • 9
    We're working on software designed to be used in a hospital for a single purpose on a dedicated machine. The user should never be able to Alt-Tab to a new window for any reason. So there are contexts in which Topmost is the preferred option. – Julian Gold Jul 09 '15 at 08:28
  • 2
    @julian: Been there done that, does not work. I have seen machines with games installed on critical hospital machines. This requirement means only that alt-tab is mapped to a different key combo which only the service technician is supposed to know. That secret key combo will be passed on in the cafeteria in the hospital between the techs and suddenly your secret is known to all users which will pass it on over twitter. – Alois Kraus Jan 17 '16 at 19:03
  • @GlennMaynard Actually there is a way to prevent that. If you set your taskmanager window to "always visible" (essentially the equivalent to .NET's "topmost") on the "Options" menu, then it will be able to pop up in front of any window in any situation. I always leave it on specially because I might be working on a fullscreen, _topmosted_ application and hit an unexpected freeze (stuck in a loop), or VS hitting a forgotten breakpoint and not being able to show up. – Matheus Rocha Jul 19 '20 at 11:33
  • We're also building a kiosk application, and I feel topmost is perfectly reasonable there. Why are we attempting to seek commonality and standardization in such a wide array of possible domains? Quite sad to see the polarity on this topic stemming solely from the fact that it worked well / not well for specific engineers. I want the customer to be happy. – Zimano Feb 01 '21 at 12:15
  • There are situations where not only setting the window as topmost but also constraining mouse and keyboard focus to the application is a requirement. such as my use case described here: https://stackoverflow.com/a/66205692/4941462 – HUSMEN Feb 15 '21 at 09:41
46

Set the WindowStyle to None, and the WindowState to Maximized. This can be done like this:

WindowState = WindowState.Maximized;
WindowStyle = WindowStyle.None;

Or in xaml:

<Window x:Class="FullScreenApplication.Window"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="Full Screen WPF"
    WindowState="Maximized"
    WindowStyle="None">

And simply click ALT-TAB to escape from your full screen wpf. It allows you to switch between other applications.

Kurt Van den Branden
  • 9,082
  • 8
  • 60
  • 72
  • 3
    Actually, that seem to be the *incorrect order*. If you first maximize and then switch style you can be left with visible taskbar. This issue does not seem to be present if you `WindowStyle.None` frist and `WindowState.Maximized` after. – wondra Jul 30 '19 at 10:28
  • @KurtVandenBranden Adding use of `ALT-TAB` in your response was very helpful. – nam May 14 '20 at 22:41
0
  • WindowState.Maximized
  • SizeToContent.Manual