I've developed a WinJs app for the Surface pro 4. The app Runs in fullscreen and is layoutet with the screen resolution of 2736x1824 (surface resolution).
Now when i start the App on the surface the DPI scaling comes into play and messes up my Layout.
Is there a way to disable the scaling for the app?
I've tried:
Windows.UI.ViewManagement.ApplicationViewScaling.trySetDisableLayoutScaling(true);
but that doesn't seem to work.
Actually, making your app layout only for one resolution, especially for such a big resolution is not really great idea since the app can run on device with, for example 1920x1080 resolution where even with DPI scaling disabled your layout will be messed up.
So I recommend making the app layout responsive so it will look right on every resolution.
Not sure if you're still looking at this issue but I've found that the code that you see all over the place is actually XBox only (Link To Docs)
And the Microsoft Devs have been saying for a while that it's a user based setting and they don't plan on allowing you to ds(Forum Link)
You can detect the scaling value though with ResolutionScale (docsLink)
Windows.Graphics.Display.DisplayInformation.getForCurrentView().resolutionScale
Here's a link to a sample that detects it and adjusts.
So what you can do (and what I did) was where needed I used css scale to adjust the system to fit. Most of my app is responsive so it didn't matter, but if you use an iFrame and set it to be 1000px wide with this scale factor it will actually be 1400px or even 1800px wide and totally cut off..
I have listeners setup for the resize events and just adjust as needed.
Hope that helps!
-Dennis
Related
I'm developing a React project in Windows 10 and the issue I've come across is that my website design looks too big(when on 100% resolution of Chrome) on my laptop screen and works fine on 75%, I guess it's rendering the design of large screens on my laptop. Please guide me how to get rid of this problem and view the website in normal mode.
I've set my Window's Scale and Layout as 150%(Recommended), and Resolution of 1920 * 1800(Recommended), but when I view my website in the Chrome inspect tool at the dimension of 1920, it seems fine but when I view it in normal mode, then it content becomes so bigger.
Note: You might say that it's due to 150% but I've also checked by decreasing this, it decreases all the other content on screen but website looks same.
Please note that Chrome's resolution and Window's layout are two different things mentioned above,
first one is set to 100% and the second is 150%.
How can I change the resolution of the phone representing the code when in xaml view in a project?
The phone serves as a drag and drop for the controls, does it have a setting somewhere to set it's resolution. Windows Phone 8 currently have three resolutions; 800x480, 1280x720 and 1280x768.
I'm aware the emulator can be started up with different resolution, but my situation is that my CPU does not support this, im debugging straight on my Lumia 920 (1280x768).
I've got no clue on how the application looks like in 800x480.
But it is a simple application, a preview would be good enough.
You need to open the Device Window: Design -> Device Window
There under the display section you can select the display size (3 available).
Additionally you can test any other resolution by disabling the 'Chrome' option in the device window and setting d:DesignHeight and d:DesignWidth of your page to the desired resolution.
I had the problem and after much time searching google and stackoverflow, I don't think that it is possible to change the resolution of the designer window. However, maybe this link can help you, it helped me back a while ago when I had that problem:
WP8 Emulator screen size
It refers to the emulator, but explains how the app UI will be scaled to match different device resolutions. Hope it helps!
We are having a problem with one of our existing Win32 MFC based applications. It does not render correctly on displays that use high dpi settings. More specifically in Windows XP with 120 dpi selected, there are several places in the app where the text scales up but not their containers (text overflowing the bounds of it's button, etc). This also occurs in Windows 7 (and Vista) when >96 dpi is selected and "use XP style dpi scaling" is selected. If xp style scaling is not selected then I understand Win7 uses DPI virtualization instead. Everything looks fine when using DPI virtualization (Ok things are blurry but at least they're correct). By default in Win7 120 dpi uses xp style scaling and the next setting (144 dpi) does not. So our app looks correct at 144 dpi but wrong at 120 dpi.
If I edit the applications manifest to declare the app as "DPI aware" then this turns of DPI virtualization (but not XP style dpi scaling) and this gets me no where. Things still look really bad (no change for 120 dpi, 144 dpi now broken).
I need to fix this problem and I've tried reading up on DPI/scaling issues in general and it has been a learning experience. So far I have not found a suitable solution. At the moment I currently have no intention of doing a thorough and correct fix (the app correctly scales all elements according to the dpi). That would involve a LOT of rewriting. I think there are really two possible solutions. One is turn off any sort of DPI scaling all together. That would mean that if a users Win7 system was set to 120 dpi then everything on their system would look good/big but our app would look correct but would be small compared to everything else in other apps. The second solution would be to some how force our app to use DPI virtualization but to never use XP style dpi scaling. I want this to be an application side change and not rely on end users to have to make Windows configuration changes.
So far I have not found a way to accomplish either solution.
Can someone more knowledgeable on this subject please respond and point me in the right way?
Thanks
You cannot force DPI Virtualization on 120 DPI settings. I have investigated this for a product myself because having the fuzzy look in high DPI seemed a good tradeoff.
We ended up making a full rewrite of the UI positioning and scaling to have it scale properly with the font scaling in high DPI settings. The client is now fully DPI aware and scales properly in any DPI setting.
The work to do this properly took one guy ~3 months in our case for a pretty complex client.
We had a secondary plan that we never tried but it might work for you:
At start-up read the DPI scaling factor of the OS. Then reduce all font instances you have by this factor so that when Windows scales the fonts up again they are back at the size where the UI can fit them. Of course users with high DPI settings will not get bigger fonts in your application but it will at least be usable.
I am debating whether to hide or not to hide the system tray in a Windows Phone 7 application. I've not found any general suggestions on this issue -the official Windows Phone design guidelines don't address this issue at all - except for Jeff Wilcox's blog post who suggested that he personally likes to see the system tray in applications. I'd like some general advice on this issue from other Windows Phone developers.
Some reasons for showing the system tray are
Doesn't take up that much space
Users may want to see it at times
Reasons for hiding it are
You can't control its background: unless you're using PhoneBackgroundBrush as the background the top row will stand out
Lots of widely used / official apps already hide it: all games as well as the official Facebook and Twitter app.
I'd appreciate all advice on this.
Transparency and colors are now possible with Mango by setting its BackgroundColor and Opacity :
shell:SystemTray.IsVisible="True"
shell:SystemTray.BackgroundColor="Transparent"
shell:SystemTray.Opacity="0"
I would say by default show it unless it really gets in the way in a way you can't workaround, especially if its an app and not a game.
I would say it depends on the application/game you are writing
If the app needs a network connection or if you will be in the application for a long period of time show it so the user can keep an eye on network and battery.
If you need the extra screen space (for a game?), and you rarely need network hide it.
Or... I guess you leave it up-to the user and give them a setting to programatically hide/show it.
I think its best to use the tray in applications that are tools or utilities. Typically these users would prefer more info than less when they're using applications on the phone (battery, network, time).
Also adding the tray in there tends to make the application look more native on the phone (according to me and others I've asked), which is a big plus because the user associates your app as if it was built with the phone OS.
But if the application is a game, media, etc. type of application I recommend you take it off, especially on panorama because it takes away from the intended design. Also these types of applications focus on the content and seeing multiple little icons at the top can take away from the experience.
Really to me the space it occupies isn't really THAT much, so that shouldn't be too much of an issue. But rather the purpose of the app as stated above.
I do like the suggestions that have been given as far as giving the user the choice. Check out this code:
bool ShowTray;
//ASK USER WHAT THEY WANT
//ShowTray = true or false;
SystemTray.IsVisible = ShowTray;
I've been reluctantly hiding, at least on any view where I have a background image; otherwise it looks too strange to me. I've been considering a setting in my app that would allow the user to choose, and persisting that to isolated storage.
Also considering maybe having the top of the screen in phone background brush color and have it fade / blend into another color or background image. Not sure how well that would turn out but as long as it is not a cheesy looking gradient effect, perhaps.
I'm hoping eventually MS will soon add support for transparency in the system tray or otherwise help address this issue. As a user I wish that I could force the system tray to always be visible across all apps, but as a developer I realize that the visual effect often doesn't look good.
Perhaps if the community came up with a new UX metaphor where maybe double-tapping in the system tray area would toggle whether it is visible. A single tap could perhaps start to animate / pop / hint at the system tray...
Up to now I been using the pda emulator in visual studios 2008 (I am using windows mobile 6.1 professional sdk).
So I just dragged and dropped most of my GUI components into the form. In one instance I made a panel then in this panel I dynamically generated labels in it with certain location positions.
I then put it on my Hp PAQ 110 Classic pda and it looked fine and everything. Then I was looking through the emulators one of them was called professional square. So I decided to run it and when it ran my program it looked like crap.
I had missing labels, missing controls and it just looked horrible.
I thought maybe it would like do some resizing for me but it seems to either did a shitty job or it does not do it at all.
So how do you make a GUI that will work well on all mobile phones(or at least the vast majority of them).
Is there like X number of types of mobile phones? Like the emulator emulates a pda and it works on my HP one so I am assuming that all window mobile device pdas have the same screen size.
Then the next question is how do you make the controls position properly from one device to another? I heard of people using XML files that have all the location position, sizes and etc that they call up and I guess essentially generate the GUI dynamically based on the information in XML.
But I could not find any examples how the XML file would look like, how to detect what phone type it is so that I could call up the right node of the file for that phone.
I am not sure if there are any other ways but this seems better then a set of GUI forms for each one.
Also would it be recommended to have most things in a panel so that way even if the stuff is bigger you can at least turn auto scrolling on.
thanks
I spent a good amount of time looking at different solutions for this problem (see my question here as well) and ended up with a pragmatic approach - consistent use of docking. You have to restrict yourself to the least common denominator, i.e. the lowest resolution you want to support, in terms of how much you can fit on the screen. The good news was that grids always use the entire available real estate, and my forms flow correctly on all devices and the screens don't look like they are broken.
This is far from being an easy task. You can follow some guidelines, but the only thing that will actually work is to always test the User Interface in all possible screen resolutions. Emulators are a good way to start, however it will be better to have an actual device. Some things like font sizes and text readability can only be tested in a real device. So, these are my advices:
Try to use docking for positioning your controls.
You need to be able to handle orientation changes correctly. Using docking helps, but again you always need to test in different screen resolutions.
At some point you will find out that it is inevitable to detect the screen size and adapt the User Interface dynamically. I don't agree that you should restrict yourself to only display what can fit in the smallest screen. A professional application should adapt itself to the available screen size and take full advantage of it.
Structure your application so that it is easy to support new screen resolutions. Make the main User Interface code screen size agnostic. Make it get all information about dynamic resizing - positioning from a configuration class. This way you only need to enhance a single item in your code in order to support a new screen resolution.
And of course:
Test in all possible screen resolutions. After even a minor change to the User Interface, retest.
Eventhough the above posts where helpful this video I found solves all my problems and you don't have to develop for the the lowest screen.
http://www.microsoft.com/events/series/detail/webcastdetails.aspx?seriesid=86&webcastid=5112