I think I'm missing something fundamental. Please tell me what it is, if you can.
I have developed a little C++ WinForms app using VS2008. So it is built using .NET 3.5 SP1.
My development box is Win7, if that matters.
The default value of UseCompatibleTextRendering property in WinForms controls is false in this version of VStudio. And this should not matter to me, I don't think. I don't have any custom-drawn
text or controls.
The app looks good running on my Win7 box.
If I package it up (dragging along .NET 3.5) and install it on one of our WinXP desktops, the buttons and labels don't look good; the text is chopped off in them.
If I set UseCompatibleTextRendering to true and then run it on the XP boxes, the text fits into the
buttons and labels.
My question is: Why? The installation puts .Net 3.5 on the XP boxes, so the app should be able to find and use the right version of WinForms, right?
I should note that before I put my app + .NET 3.5 on these boxes, they have no .NET at all. They do not get automatic Microsoft updates; our IT guy gates the patches and upgrades.
[ This sort of thing has happened before with apps I create.. they look/work great on the Engineering machines, because we maintain those and they mostly have up-to-date stuff. When they are run on the corporate boxes, they usually don't run and need the VCredist installed. ]
Back to the question at hand: The text looks better with the UseCompatibleTextRendering set to false, so I'd rather keep it that way, if I can. I'd like to understand what might be missing on those XP boxes that is making the text not fit.
Thanks
S
It is probably a scaling problem, the XP machine may have a different video adapter DPI setting or a different system font size. Scaling is affected by the form's AutoScaleMode and whether or not they "inherit" the container control's Font property. Which it does if the Font property isn't bold in the Properties window.
One quick way to check if scaling works property in your Form:
protected:
virtual void OnLoad(EventArgs^ e) override {
this->Font = gcnew System::Drawing::Font(this->Font->FontFamily,
this->Font->SizeInPoints * 125 / 96);
}
That scales it up. It probably gets scaled down on the XP machine, use 96/125.
Related
We have a Windows Forms application used for testing our products that has had pretty much the same forms and dialogs for nearly 10 years now. AutoScaleMode in the designer is set to Font for both forms, and that hasn't changed since the original design. AutoSize is set to false and just for good measure (I guess) AutoSizeMode is set to GrowOnly. The following source lines are in Program.cs:
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Remember, this has been working flawlessly for years...
One of the recent updates to VS2017 included AutoScale support for monitors with different DPI. I have a relatively high DPI monitor, so when I made some changes to a Settings dialog (adding controls, etc) I started getting bright yellow banners cross the top of the designer surface telling me that AutoScaling was set to 125%, and would I like to change that? I tried going back and forth, and when in 100% mode (Autoscaling off) I was warned that XAML forms might not display correctly. Fine, I am working with Forms so I went back to "normal" scaling and the form looked fine.
Until I tried running the program. Now when I start the program the main form looks like this (details deleted to protect the guilty):
...but when I open the settings dialog it looks like this:
Yikes! It looks worse in practice, the relative images here don't do justice to the difference in size and scale.
I have no idea what got changed or how / why this is happening, but there's no way I can put this into production. I've tried changing the AutoScale settings, to no avail. Can somebody point me in the right direction here?
Thanks in advance!
EDIT: It seems the rescaling only happens on my machine when I run the app in Debug. Whatever is messing up the display of the forms on my machine doesn't do that on my associates' machines and isn't replicated to the executable produced by the build server.
On another note, I tried every DPI-related setting I could find, added those that weren't there due to the program's age, all to no avail. Nothing I have tried has had any effect on the program's display weirdness on my machine. Ugh.
I tried all the tricks I could find, short of disabling AutoScale completely, and nothing worked. I finally merged our develop branch in to my feature branch and inspected all 270 edits, choosing the oldest settings I could find for all size parameters, all controls. Ugh.
Along the way I stumbled across the following line in the Designer.cs file for the form:
this.AutoScaleDimensions = new System.Drawing.SizeF(6F, 13F);
This setting is NOT accessible from Visual Studio's designer, as far as I can tell, nor can I find anything about how or why it gets set. What I did find was that in the earlier version that did work as expected, the values were (8F, 17F) -- so I manually edited the line to match the older, working version. Success!
I also checked my Windows display settings, and the Custom Scaling value was at 100%, so I used the registry hack mentioned in one of the articles I found following the first link from the comment above (thanks, #Jimi) to disable auto-scaling in Visual Studio, then turned off the notification. Now I'm (finally) back in business.
Registry hack is here:
https://learn.microsoft.com/en-us/dotnet/framework/winforms/disable-dpi-awareness-visual-studio
If one uses the registry hack mentioned in the answer from DaveN59, and there is already entry for your ...\devenv.exe (mine was previously set to run as admin) then add the DPIUNAWARE string to the end of the "Data". Make sure to use a space as a separator.
Example: ^ RUNASADMIN DPIUNAWARE
I'm not sure what the ^ is for, but it was there and I just added DPIUNAWARE string. Also, if you just add this string, it will come up unscaled, but you will still see the yellow banner. To turn that off you'll need to select that option from with in Visual Studio. The instructions are in the link for the registry hack, also provided above. For conveinece here's the menu navigation path.
To disable notifications, choose Tools > Options to open the Options
dialog. Then, choose Windows Forms Designer > General, and set DPI
Scaling Notifications to False.
I am developing a Windows Forms application using VS2008 on Windows Vista. I tried to run my application on Windows XP the other day, and everything on GUI was messed up. I realized that I developed the application using 120 Dpi setting on Windows Vista and my XP was set to 96 dpi.
My application has several UserControls and all of them shrinks even in the Visual Studio itself if I change my DPI to 96. I am sure a lot of people are using Visual Studio in high DPIs these days. So how can make sure that my GUI does not get messed up both in Visual Studio and runtime?
EDIT: I have read couple articles on this issue and I learned that I should be setting AutoScaleMode to None. However, this still does not prevent my labels to adapt new DPI settings enforced by the operating system. I need a way to prevent my labels to grow/shrink because other GUI elements have fix sizes.
It has been a while since I worked on this issue, but try setting AutoSize = False. In addition, UseCompatibleTextRendering = True might help.
This is a rather old question, but I want to share my solution/opinion. I ran into a similar problem recently. Actually, I want Visual Studio to keep my WinForms as they are, but them to scale at runtime. I found no consistent summary on how to correctly do that. After some reading and experimenting I came to this solution:
Keep the Form’s AutoScaleMode = Font.
Set in your Forms Designer: Font = MS Sans; 11px
In the Forms Ctor, after InitializeComponent, set: Font = SystemFonts.DefaultFont
Enable DPI-Awareness, either through a manifest or by API function SetProcessDPIAwareness
Since AutoScaleMode remains active, all DPI-changing magic works, even per-monitor DPI awareness. What remains, is designing Forms in a way scaling works nicely.
I wrote the details on my Blog: http://www.sgrottel.de/?p=1581&lang=en
I have developed a GUI for a random application using WPF. I have a bunch of out of box WPF controls laid on the application window. I haven't customized anything, didn't use bitmaps, etc.
When running my application and zooming using Magnifier application in Windows 7 (Win key + Plus key, the magnified GUI is showing pixels.I am probably wrong, because I can't explain it otherwise, but isn't WPF supposed to provide vector like control rendering?
Thanks for participating in the discussion.
Bonus Reading
Tim Sneath: Magnifier: An Interesting Discovery (archive)
WPF Vector based interface *(screenshot of WPF being vector scaled by Magnifier)
MSDN Blogs: Greg Schechter explains why it longer happens (archive)
Back when Vista first shipped, and when WPF was on version 3.0, zooming with the built-in magnifier would actually do vector-based scaling.
This stopped working when WPF 3.5 service pack 1 shipped. (It worked in 3.5 before sp1.) The reason it worked before then is that the DWM (Desktop Window Manager) - the part of Windows responsible for presenting everything you see on screen - uses MILCORE.DLL to do its rendering. Version 3.0 and 3.5 of WPF also used this same component to render - this meant that all WPF content was native content, so to speak. (In fact, on Windows XP, which doesn't have the DWM, MILCORE.DLL is something that WPF puts on your system for its own benefit. But it's built into Vista and Windows 7.) When WPF was using MILCORE.DLL to render on Vista, any effects applied by the DWM such as scaling would also apply in the way you want to WPF - it really did scale without pixelating.
Unfortunately, this is no longer the case. And the reason is that WPF started adding new rendering features. In 3.5 sp1, the new feature in question was support for custom pixel shaders. To enable that, Microsoft had to release an update to the MIL. (The Media Integration Layer - the bit that does the actual rendering.) However, they weren't really in a position to update MILCORE.DLL, because that's part of Windows - it's how everything you see on screen gets to be on screen. Releasing a new version of MILCORE.DLL effectively means pushing out an update to Windows. The release schedule for Windows is independent of that for .NET, and so the only way the WPF team could reasonably add new features was to ship a new MIL. (In theory they could have done it via Windows Update, but since WPF is now owned by a different division of Microsoft than Windows, that sort of thing doesn't seem to happen in practice.)
As of .NET 3.5 sp1, the MIL is in a different DLL called wpf_gfx_vXXXX.dll where vXXXX is the version number. In .NET 4.0, it's wpf_gfx_v0400.dll.
The upside is that WPF gets to add new rendering features with each new version, without needing Windows itself to be updated. The downside is that WPF's rendering is no longer as tightly integrated with Windows as it was briefly back when Vista shipped. And the upshot is, as you've seen, that magnifying is not as much fun as it used to be.
The magnifier application implements its own zoomed image rendering, so that's why you are seeing pixels. WPF does use vector graphics, but in this situation it's not the WPF application itself that is rendering the zoomed image.
If you use something like Snoop you can see zoomed and scaled WPF vector graphics rendering in action.
I suppose, Windows 7 magnifier takes a snapshot of actual application on-screen UI, and then magnifies it itself (not making a special case for WPF applications). Of course what it can access is just the pixels, not the vector graphics which works behind the scene.
The Windows-7-Magnifier is pixel based, but there is a difference in magnifier mode depending on wether an Aero-theme is active or not.
with Areo theme the zoom is pixelated.
without Areo theme the zoom is smoothed (blurry).
Only with Areo theme other Views (except "Docked") are selectable.
I'm having problems with the rendering of a WPF app over a remote desktop connection.
The applications chrome is rendering, but none of the content is coming through, as if the window is not drawing. Instead the previous content of the screen is showing in it's place.
This has been a problem with the application running on both Vista & Win 7, with remote control being taken from XP and Win7.
The problem is not application specific, if I create a new WPF app, with just a textblock on the window, it will also not run. (Neather will the windows preview in VS2008 display.)
Is there some trick to getting WPF running under RDP?
I read on Kevin Dente's blog (from a twitter post) that he was having trouble with WPF apps in virtual machines. While not the same as Remote Desktop, it's possible the problem could be the same. Kevin was able to fix his problem by disabling hardware accelleration by creating a DWORD registry value at
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Avalon.Graphics\DisableHWAcceleration
and then setting it to 1.
His original blog post is here: http://weblogs.asp.net/kdente/archive/2009/10/19/visual-studio-2010-beta-2-editor-performance-fix-running-on-a-virtual-machine.aspx
That may not be your exact solution, but maybe it points you in the right direction.
WPF should render over RDP; it's smart enough to know when it can render in hardware, and when it can't it reverts to its own GDI+ based software rendering. I would make sure you're running .NET Framework 3.5 SP1 on the remote machine, since there were changes to remoting that might pose issues. (See link below.)
I've been developing a WPF app for the past 6 months and it works just fine over RDP. (From Vista and Win7 to XP, Vista and Server 2003.) One important caveat, however, is that it renders using the Classic theme. So if you're using controls that don't have a classic theme, they won't render. If you're just dropping a TextBox on a Window, then obviously that's not your problem.
Check out this question for some links that may be helpful: Are there problems with rendering WPF over Remote Desktop under Windows XP?
I just had this problem with the ribbonwindow not displaying correctly when testing for the first time via RDP - the transparent background was white, the close minimize/maximize buttons were missing, the rounded corners on the bottom of the window were square, and the top row of ribbon buttons were almost impossible to select.
Turns out there was a simple fix for me. Right-click the RDP connection icon (I have it saved on my desktop), select "Edit", then the "experience" tab, and change "detect connection quality automatically" to "LAN (10 Mbps or higher)".
This fixed it for me.
Ade
Did you also try Win7 latest RDP - Win7 connection? The thing is WPF doesn't use GDI to draw elements.
VNC clients (like UltraVNC) probably will do the trick for you as they using much simplier algorithms more like of sending bitmaps.
I have the same problem than the asker. The standard, out-of-the-box Checkbox is not rendering correctly. I can only see if it is checked when hoovering the checkbox. Otherwhise, no difference between checked and unchecked. Important note : It occurs when setting the foreground to white (see here : https://social.msdn.microsoft.com/Forums/vstudio/en-US/1c03db49-7e53-4cbb-9dd1-b328017c4453/wpf-checkbox-and-radiobutton-check-mark-not-showing-under-xp-windows-classic-theme-and-remote?forum=wpf)
Our application used to have this problem with a custom progress bar.
We fixed this by setting the background color of the Border control to White. This leads me to think there is an issue with transparent backgrounds
There is no special trick needed to get WPF content to show across remote desktop. Our WPF-based app renders just fine over RDP (tried from numerous machines) with no problems. We're even using animations, gradients, WriteableBitmap, etc. w/ no problems.
Under Windows XP WPF true 3D content (which is usually displayed using the Viewport3D control) looks extremely ugly because it is by default not antialiased as the rest of the WPF graphics are. Especially at lower resolution the experience is so bad that it can not be used in production code.
I have managed to force antialiasing on some Nvidia graphics cards using the settings of the driver. Unfortunately, this sometimes yields ugly artifacts and only works with specific cards and driver versions. The official word from Microsoft on this regard is that antialiased 3D is generally not supported under Windows XP and the artifact I see result from the fact that WPF already does its own antialiasing (on XP only for 2D).
So I was wondering if there is maybe some other secret trick that lets me force antialiasing on WPF 3D content under Windows XP.
Have you tried this (from your thread on MSDN forums)?
Well, it seems the reference in the MSDN link above incorrectly specify the affected registry root key. In MSDN it is specified as HKEY_CURRENT_USER, while the correct root key should be HKEY_LOCAL_MACHINE. I've tried setting up the HKEY_LOCAL_MACHINE\Software\Microsoft\Avalon.Graphics\MaxMultiplesampleType to '4' and I can get antialiasing for my WPF Application on XP.
The feeling I get from Matthew MacDonald's Pro WPF Windows Presentation Foundation in .NET 3.0 is that it's not possible:
There's one exception to WPF's software support. Due to poor driver support, WPF only performs antialiasing for 3-D drawings if you're running your application on Windows Vista (and you have a native Windows Vista driver for your video card).
I've never seen anything to suggest that you can enable AA in WPF 3D on anything but Vista, but if there is a way it's new to me and I'd love to know as well!
Does your video card support Shader 2.0? You can refer to this wiki page to see if it does...