I have a WPF application that fits into my computer screen having screen resolution 1920 * 1080. But the same WPF application doesn't fit into my Microsoft Surface screen having same resolution 1920 * 1080. The exact issue is, it doesn't show the scroll bar in that little laptop. The issue is in the XAML for the page I am having trouble with and the window that hosts it. Any suggestion would be appreciated. Thanks.
The code is something like this right now.
<Page x:Class="form_Dock" Background="#FF19191E" MouseEnter="Page_MouseEnter"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:local="clr-namespace:ABC.UI" SnapsToDevicePixels="True">
This could be a scaling issue caused by WPF using device independent pixels to determine the size of the application. The Surface screen is pretty small, so there may be some scaling done in Windows to compensate, which is throwing the size of your window out.
You might be able to fix your problem by setting SnapsToDevicePixels on the window element to true:
https://msdn.microsoft.com/en-us/library/system.windows.uielement.snapstodevicepixels(v=vs.110).aspx
Also, this explains device independent pixels quite well:
https://wpf.2000things.com/2013/02/19/759-device-independent-units-dips/
Related
If the auto-hide of Windows 10 TaskBar is ON then when the app is running will cover it and there is no way to get to the TaskBar with the mouse cursor. Any way to solve this?
mc:Ignorable="d" WindowState="Maximized" WindowStyle="None" ResizeMode="NoResize" WindowStartupLocation="CenterScreen">
This is one of the biggest problems with the WindowChrome/WindowStyle="None" functionality in WPF. I don't know a 100% full proof way of handling it. The best way I've been able to find online is to use some interop to manually handle the Window's WndProc function and intercept the WM_GETMINMAXINFO message. This message controls the dimensions for a maximized window. Using this method, you can subtract a pixel or two from the maximized dimensions so that the taskbar can poke through.
Since the taskbar can be positioned in different corners of the screen, you can use some more interop to detect the current location of the taskbar. Like I said, this method doesn't work perfectly. Sometimes the taskbar gets stuck behind the window. Until someone posts a better method, it's the best I've been able to find. Here's a code sample (not mine) that I found on GitHub:
https://gist.github.com/MortenChristiansen/6463580
I have WPF application work with 1024x768 screen resolution, now I want to run this application on Microsoft Surface with wide resolution, I had make new windows with resolution 1366x768, but unfortunately I can't make it work fine on Surface, I tested it on my laptop, it's work 100%, but I don't understand why it would't work in the same way on Surface.
If there is anyone that has experience with Surface can you please help?
Update
When I run the WPF windows with resolution 1920x1080 work full screen on my laptop, but the problem is when run application on Surface with the same resolution don't fit the full screen, see this screenshot to more clarity:
Maybe your surface and laptop have different DPI settings. See here how to handle that problem.
From the information provided it may be that your WPF window layout doesn't sufficiently take into account differences in Display text and item sizing on different devices.
On both your Surface Pro and your laptop:
Select "Screen Resolution" from the Desktop context menu.
Select "Make text and other items larger or smaller" from the Screen
Resolution window.
Check the position of the "Change the size of all items" slider.
By default the Surface Pro is set to Larger. A new Windows 8 install will be set to Smaller.
In WPF you should not be setting a constant window size, instead you should:
Make the window's content react to the window size by using auto sizes and grids instead of constant sizes and panels
You can use WindowState="Maximized" to make the window full screen
You can prevent your window from being reduced too much with minwidth and minheight.
We are doing UI screens for WPF application on Laptop But we are planing to give demo on 22"inch Monitor. Here Dimensions are getting changed when we see UI screens on 22"inch Monitor. How can I make same UI screen apperance on both Laptop and 22" inch Monitor? please help me here....
Are you using an absolute layout, where specific X/Y/Height/Width is being defined for every control? If you use other types of layouts, they are more relative to window height/width and automatically handle these issues.
Wrap your entire application in the Viewbox control. As long as you don't have rasterized images, nothing will look stretched.
Im beginning in my journey of learning WPF. After a few days of coding I see that whenever I resize any WPF form I get a black border on the bottom and right while resizing, like an artifact, as if the screen is too slow. When working with winforms I never noticed this.
Like so :
Is this a known problem? any simple workaround?
EDIT 1:
Seems its related to the graphics driver, I only work on laptops with weakish gfx cards, so does anyone else have this issue? (Im also using Win7 SP1)
It's a known problem, and it's unlikely that it will be fixed. There is a work-around that reduces the impact of this problem if your background is sufficiently uniform: https://stackoverflow.com/a/14309002/33080
My understanding of the underlying cause is that WPF controls lag behind on resizes: WPF draws them in the "wrong" location briefly. See the linked question for a demonstration.
If you resize a window it has to redraw. This takes some time and also it occurs after the window manager already resized your window and shows it; in that case you'll get a black border in WPF and one with the normal window background (grey, usually) in Windows Forms.
Usually all you can hope for there is that the computer is fast enough with the redraw to not show it.
I created a simple web browser WPF test application with pictures and text within a canvas, with windows set at 96dpi.
Then I switched to 120 dpi and :-((( Display is messy, image size changed and part of the canvas is out of view...
When I used Winforms, I set the AutoScaleMode property to None and the windows keeps its size, the controls as well, the controls which have inherited font are properly displayed, not blurry and not too big...
What can I do to mimic this (good) behavior in W¨F?
I'm not clear on what you mean by "web browser WPF ... application". WPF doesn't run in a Web browser, unless you're talking about an XBAP. Or are you doing Silverlight? Or is it just a WPF navigation application and not browser-based at all? You'll need to clarify.
WPF automatically scales your content when you run in high-DPI modes. This is intended behavior: if the user explicitly says they want everything to be bigger on the screen, then WPF will respect the user's wishes. The old WinForms hacks of "pretend high-DPI doesn't exist, just show everything at the normal small size and hope it doesn't piss the user off too much" aren't available in WPF; you could probably emulate them if you worked at it, but you're steered very strongly toward doing the Right Thing.
WPF scales everything, so your statement that "part of the canvas is out of view" doesn't make sense. It should be scaling the canvas, its parent window, and its child elements all by the same amount, so if everything fits at 96dpi, it should also fit at 120dpi and 144dpi. If not, then you're doing something strange and you'll have to provide a code sample that reproduces the problem.
You seem to be claiming that fonts are blurry when you run in a high-DPI mode, which sounds very strange. Fonts are rendered as vectors, so they should scale cleanly, and render crisply even in high-DPI modes. I've never seen the blurry fonts you describe, so again, you'll have to provide a repro case.
The only thing that I would expect to be blurry are images. If you're using raster (bitmap) images (BMP / GIF / JPG / PNG) in your UI -- for example, for the icons on a toolbar -- then yes, those will look pretty bad when they're scaled. It pretty much always looks bad when you take a small bitmap and make it larger. You might try working around this by using larger images and sizing them down for display -- for example, if you want your toolbar images to be 16x16 (when in standard 96-dpi mode), then you could try putting a 32x32 bitmap in your project, setting the Image element's Width="16" and Height="16" in your XAML, and seeing if that looks any better. It would actually be 20x20 physical pixels in 120dpi mode, and 24x24 in 144dpi mode, both of which would still be scaled down from the 32x32 resource and would therefore have a better shot of looking good than a 16x16 source image that's had to be scaled up. (I haven't tried this technique in a WPF toolbar, though, so I don't know how well it would really work in practice with typical toolbar images.)
The very best way to get around the problems with scaling images would be to use vector images instead of raster. Unfortunately, it's hard to find libraries of vector images. They're few, far between, typically less comprehensive than what you can find for bitmap images, and often expensive.
Presumably you use fixed length units (px). Try re-layouting your project keeping the WPF layout rules in mind. This page has some best practices for that.
I just found a bug using MaxHeight under WPF in .NET 4, set in a Style that gets inherited by another Style and that is used as a StaticResource, which didn't get influenced by the DPI set by the user. I set it from MaxHeight to Height, then it got influenced by the DPI. I suspect a bug in the .NET 4 (and possibly other frameworks) here.