My form looks gorgeous (YMMV) at design-time:
...but gets "stretchy" vertically when running on the device and, in fact, is a little too tall for the screen:
Why would this happen, and how can I prevent it from happening?
Possibly noteworthy: Form's WindowState == Normal, FormBorderStyle = FixedDialog
please check your form settings: AutoScaleMode and Size settings.
Is this your first Windows CE application? You have to keep in mind that there are devices with different resolutions (ie QVGA, square like 320x320 pixels, etc), so you should adjust your layout to the screen size. Or make your form maximized and set AutoScroll to enbaled (if the content does not fit).
When you design your form, you are using pixel counts. These are transformed to twips (1/1440dpi) and again transformed (on the device) back to pixels (including a correction for the resolution, the dots-per-inch (dpi)). So a form with 240x240 pixels will have adifferent size on a 96dpi and a 102dpi display. This scaling is controlled by AutoScaleMode.
Related
I am trying to resize a window that covers entire screen.
I tried out following
win.Left = SystemParameters.VirtualScreenLeft;
win.Top = SystemParameters.VirtualScreenTop;
win.Width = SystemParameters.VirtualScreenWidth;
win.Height = SystemParameters.VirtualScreenHeight;
This works perfectly on a monitor of 1080p (Full HD monitor). It also works when I have two monitors attached and one of which is full HD where as the other is an HD monitor. I understand that in such case some of the part of the window will never become visible as it will go out of the bounds of total screen asset.
The problem starts with 4k monitor. On a 4k monitor, it consumes a smaller rectangle on screen and does not span to cover the entire screen. I understand that this is due to scaling (wpf automatically scales window) but not able to find a way to overcome this issue.
The issue is just with the 4k monitor. I assume that it has something to do with DPI as the 4k monitor has higher DPI.
My question is, how to make the application use entire screen asset irrespective of monitor resolution and DPI.
(Please note that setting window maximized will not work as it will not span it over multiple monitors.)
It turned out that the issue was not with resizing of window at all. Window was properly resizing after specifying the co-ordinates. However, there is one thing which might help those who want to do similar thing. Always make sure that you compare the values retrieved form API with the other values from API and WPF with WPF as WPF yields scaled values.
I would happily provide a screenshot of this, however the problem is the captured image, is much larger than my actual desktop.
I am completely frustrated with this as I have tried using BitBlt with the desktop hdc AND the new "Graphics" commands.
My actual desktop resolution is 1920x1080 - 1080p .
BitBlt and "Graphics" both return that my resolution is 1536x864 # 96 DPI.
A form (WinForm), Maximized, borderless, and irrelevant of scaling mode the form is set to, also shows 1536x864 # 96 DPI.
Now the image that is captured, is like it is being done from 1920x1080, but clipping the region 1536x864 as the screenshot.
If I do PrintScreen directly using Prtscn button, I get the entire image, but still it is about 1.5-2x larger than what I actually see.
What I am looking for -- is a resolution for how I can take a picture of what is on my screen in the scale/dpi/whatever is going on here that it visually looks like. I have written a screen capture program, and using a few different examples for the RubberBand form (overlay form to select a region of the screen by drawing a box), and as you can imagine, this scaling crap is causing those box captures to be offset, and the contents are zoomed.
This is very annoying -- even to explain, however I am positive that most of you are familiar with the terms I use, and also know what to expect from taking a screenshot, so my explanation above should be pretty clear as to what my problem is.
Example/Consideration
Imagine, taking a picture of a window that is 300x300, and getting the top left 150x150 of that zoomed to 300x300 completely skipping the remainder of the window. Resulting image is still 300x300, but it's not what you selected.
Now imagine, you grab a picture of your screen by the only dimensions you can get programmatically, and then put the image into a picturebox. Even though both your screen and the picturebox claim to be the same dimensions and dpi, the image in the picturebox requires scrolling even if the picturebox is maximized to fullscreen on a borderless with no borders / etc. -- again, the picture is zoomed, but how is it still reporting that it's the same size as the form XD (comparing Graphics or BitBlt dimensions with the actual form. also tried comparing picturebox contents, and still same effect)
This, is EXACTLY what the effect is that is happening. When I try to capture a region or segment of the screen. I am not sure why windows api/crl is lying about this seemingly trivial stuff, however there must be a way to accurately obtain screenshots/capture regions without this faux zoom effect -- across all resolutions.
Thank you Hans Passant for pointing me in the right direction.
To add "true" dpi scaling support to a winforms application, you can make it so by adding the following block to your manifest :
Project > Add New Item > Visual C# Items > Application Manifest File
One the file has been added, open it up and look for a line like
</asmv1:assembly>
Whatever the "asmv" number is, (in the example above it is 1), use that to format the code:
<asmv1:application>
<asmv1:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<dpiAware>true</dpiAware>
</asmv1:windowsSettings>
</asmv1:application>
Paste the above code (changing the asmv1 to whatever version the manifest is), just above the final closing line for the ""
Also, make sure your forms are set to AutoScale to dpi (and all sub-elements).
I have a WebBrowser control that is getting content via the NavigateToString() method. It looks fine in portrait mode, but when I change the orientation to landscape, the text becomes noticeably larger (I'd say about 2 times larger). I'm not sure what's going on. I'm not doing anything to the WebBrowser control on orientation changed. If I change the orientation back to portrait, it looks correct again. Does anyone know what could be going on here?
I'm guessing that you're using a fixed width for the viewport and this is causing the text to be enlarged as all the content is stretched to the wider screen size when in landscape mode.
If you can post an example of the HTML you're using we could probably say for sure.
My developer's box has a screen resolution of 1680 x 1050. I'm developing a full-screen Silverlight 3 application that I'm considering deploying to the Internet. So, I want to make sure the application looks good on a variety of screen resolutions. I just started testing on other boxes, the first one having a screen resolution of 1024 x 768. During the test I found some of the pages on the application were partially truncated. It seems the controls on the page didn't adjust for the lower screen resolution. So, I'm looking for some tips on how to make a Silverlight application, to the extent possible, adjust for screen resolution. For example, are there things one should or should not do on XAML to make adapting to screen resolution easier? Should I just optimize for a minimum screen resolution? Your thoughts and suggestions are welcomed.
You can easily enforce a minimum acceptable resolution by setting the MinHeight and MinWidth properties of your root visual. (Of course, this should be less than the minimum screen resolution to account for browser chrome.)
Try to specify absolute Width and Height only when necessary: for example, for images or icons of fixed dimensions, or for obvious cases like TextBoxes (whose width should reflect the average length of the data entered).
Grid panels are excellent for mixing scalable and fixed layout areas. The star sizing specification takes a bit of getting used to--it's not as simple as a percentage-based proportioning--but it's much more flexible, especially in combination with row/column min/max dimensions.
You don't really need to test on multiple resolutions unless you're interested in testing a range of dots per inch--just resize the browser to approximate different screens. Since there's always a bit of give and take depending on the user's browser configuration, you'll have to account for some variance anyway.
You can make your application scale with the Silverlight Toolkit ViewBox or make it strech with layout controls like the Grid, StackPanel, and WrapPanel. Make your main UserControl have a Width and Height of Auto (or remove the width and height entirely) and the size of the app will resize to the size of the parent div (the default HTML template uses 100%x100%). Then just resize the browser accordingly. IE8 has developer tools that can help you see your app resized to specific screen resolutions.
Testing on a variety of screen resolutions is always a good idea.
I covered the resizing of elements and making it resolution independent on another thread.
You can have a look here, there are multiple ways to sizing and resizing things automatically.
Can someone explain why everything in WPF is blurry? Is this something that can be fixed?
The reason for this is the anti-aliasing system which spreads the line over multiple pixels if it doesn't align with physical device pixels.
WPF is resoultion independent. This means you specify the size of an user interface element in inches, not in pixels. A logical unit in WPF is 1/96 of an inch. This scale is chosen, because most screens have a resolution of 96dpi. So in most cases 1 logical unit matches to 1 physical pixel. But if the screen resolution changes, this rule is no longer valid.
All WPF controls provide a property SnapsToDevicePixels. If set to true, the control ensures the all edges are drawn excactly on physical device pixels. But unfortunately this feature is only available on control level.
Source: Draw lines excactly on physical device pixels
Quick Fix:
Use these options on every Container from root to your blurry control
UseLayoutRounding="True"
RenderOptions.BitmapScalingMode="NearestNeighbor"
SnapsToDevicePixels="True"
RenderOptions.ClearTypeHint="Enabled"
Explanation:
UseLayoutRounding=true fixes subpixel layout problems. They often occur because e.g. Effects resize controls to be something between pixels.
RenderOptions.BitmapScalingMode=NearestNeighbor fixes blurry sampling of bitmaps. Bitmaps are used when effects or other techniques are used. When they are reapplied to the container or control they might end up inbetween pixels and therefore interpolate the pixels of the bitmap.
SnapsToDevicePixels="True" fixes vertical and horizontal polygons, lines and rectangles being rendered inbetween pixels
RenderOptions.ClearTypeHint="Enabled" reenables cleartype on text. It is disabled very easily by effects or whenever the renderer does not know the exact background of a text.
You should use it on every Container because sometimes, e.g. by data templates these options are defaulted again for the sub controls.
I spent a couple of hours trying to figure out the cause of the blurriness on custom panels. On these custom panels we are using a drop shadow border effect. The drop shadow was the culprit. It actually causes blurry text if the panels are placed side by side. I don't have a high enough reputation to make a comment so I am answering the question.
UseLayoutRounding="True"
was the fix for my problems as answered by ecreif. although I did not need the other lines of code in his answer, I added them anyways.
The following worked for us when facing similar issue:-
Right Click and open the Properties Window for the executable.
Under "Compatibility" tab, click on "Change High DPI Settings" button then check the "Override High DPI scaling behavior" checkbox at "Application" drop-down selection.
Click on Apply/Ok buttons to save the settings then relaunch app.
P.S.: These settings could be deployed to User system via Windows Registry entry.