5

I have already specified in the manifest as Landscape and LandscapeFlipped, I know this is just a preference and on top of this I've added the below code in the App.xaml.cs OnLaunched. But yet when tested on a tablet the app goes back to portrait mode.

 DisplayInformation.AutoRotationPreferences = 
                     DisplayOrientations.Landscape | DisplayOrientations.LandscapeFlipped;

Also is there any alternative way I could test this in a simulator instead of an actual tablet/device?

Thanks in advance.

Reporter
  • 3,897
  • 5
  • 33
  • 47
AbsoluteSith
  • 1,917
  • 25
  • 60

3 Answers3

4

Since my comment helped you im going to add it as answer

Reference

Solution

[DllImport("user32.dll", EntryPoint = "#2507")]
extern static bool SetAutoRotation(bool bEnable);

SetAutoRotation(false);
Community
  • 1
  • 1
lokusking
  • 7,396
  • 13
  • 38
  • 57
  • Is there really no other way? Also do you know if this interop call will pass the store certification? – Pavel Durov Dec 08 '16 at 10:38
  • 2
    This function is not documented or supported anywhere. It won't pass store certification or even Win32 certification of any kind. Please do not use it (ever). MSFT reserves the right to remove it at any time. – zhuman - MSFT Mar 23 '17 at 18:58
  • 1
    This solved my problem partially. It blocks the orientation on the device, not the application. Is this the right approach? – mbob Aug 01 '17 at 07:21
  • @mbob : Make sure you set the orientation of the app in packagemanifest. – AbsoluteSith Aug 01 '17 at 11:10
  • @AbsoluteSith that's what I did. And the app still rotates – mbob Aug 01 '17 at 12:37
2

First a note: the DisplayInformation.AutoRotationPreferences provides roughly the same functionality as the Win32 SetDisplayAutoRotationPreferences function, except that the DisplayInformation one is for UWPs and the Win32 one is for Win32 apps (e.g. with HWNDs). You can't use the UWP API for Win32 apps and vice versa.

The UWP API is only designed to work when the device is in Tablet Mode on Windows 10. Auto-rotation must also be turned on by the user and the device needs to have an accelerometer. In general, your app needs to be the foreground window as well for it to work.

Now that you know all the requirements of the API (which are subject to change, by the way - this is an orientation "preference" after all), is it still not working as intended? The intention is that the user is still in control of the experience.

In some cases, I've seen developers trying to use this API for custom OEM devices running a single app in kiosk mode all the time. The API was designed for normal app scenarios, not for kiosk scenarios. If you have a scenario like this, then ideally you can just describe the hardware configuration you want to drive (like a normal OEM device - e.g. you write the ACPI tables and firmware) and the OS will use the correct orientation. If you're just building a one-off device, you could consider setting the screen rotation using SetDisplayConfig from a Win32 app on startup rather than relying on auto-rotation at all.

zhuman - MSFT
  • 1,028
  • 12
  • 16
0

You used the right API to force the orientation in UWP app, but you can refer to the official DisplayOrientations enumeration, in the remarks part:

Applications typically use this property to translate the reading of an accelerometer or to translate the physical button events in accordance with the current screen rotation.

It means, these work but only if the device has an accelerometer, on laptop even simulator, they have no effect.

Also is there any alternative way I could test this in a simulator instead of an actual tablet/device?

No, simulator is not suitable, you can test this on Mobile or Mobile emulator.

Grace Feng
  • 16,564
  • 2
  • 22
  • 45