I've got a C# 3.0 Windows Forms app built with VS2008 (previously ported from C# 1.1) that looks fine on a WinXP 32bit PC but has jacked proportions on Win7 64bit laptop.
I'm finding references to the lack of support on Win7 for Tahoma 8, which the app uses. Do I need to redesign my dialog using Tahoma 9 to get it to display well on all 3 OSes?
Here are my initial measurements (cm) of a group box containing radio buttons and a button:
OS, Resolution, GroupBox HxW, RadioButton HxW
XP, 1024 x 768, 7.5 x 6.75, 0.75 x 4.4
7, 1024 x 768, 6.8 x 6.3, 0.8 x 5.0
7, 1680 x 1050, 4.9 x 4.5, 0.55 x 3.5
The problem is basically that on the different OS's, the group box has its proportions changed differently than the radios it contains, such that radios and labels that fit fine in the group box in XP run out of bounds (both x & y axis) on 7. Similarly, the text on the button grew more than the button. This happens even when I dial down the 7 box's resolution to match the XP box. The GroupBox's font is larger than that of the radios, but even when I made them equal I saw no improvement.
I think it has something to do with the fact that the application was originally created with an older version of C# and then ported. I say this because I just created a new (empty) Windows forms project using VS2008, and for every control in my app that isn't displaying correctly on win7, when I copy that control to the new app and run it on win7 it resizes correctly. There must be some high level property in the app that the controls are inheriting.
What causes this and what can I do about it?
Thanks in advance.
The main form's 'AutoScaleMode' was set to 'Font'. Setting it to 'DPI' fixed it (although that created other problems due to the code not anticipating being resized on startup...null refs, but I can deal with those).
Tergiver gets double credit for pointing me to the form's property sheet and for me taking this long to notice the obvious property :)
Related
I'm trying to make a DirectX8 application (Game Maker) chroma keyed using layered windows (WS_EX_LAYERED extended style flags, and LWA_COLORKEY method) for transparency and correct hit testing on a borderless window. However, out of all platforms I've tested it on, Windows 7 fails but specifically only when Aero Glass is turned on. The effect works for apparently one frame, and then stops working - the chroma key then comes out to the screen and the window is a full rectangle, including mouse hit testing. Turning off Aero Glass in advanced appearance, or changing to a Basic or Classic theme fixes the issue, but that's undesirable.
__declspec(dllexport) double __cdecl __gm82core_setchromakey(double enable, double color) {
if (enable>=0.5) {
SetWindowLong(window_handle,GWL_EXSTYLE,GetWindowLong(window_handle,GWL_EXSTYLE) | WS_EX_LAYERED);
SetLayeredWindowAttributes(window_handle,((DWORD)color)&0x00ffffff,0xff,LWA_COLORKEY);
} else {
SetWindowLong(window_handle,GWL_EXSTYLE,GetWindowLong(window_handle,GWL_EXSTYLE) & ~WS_EX_LAYERED);
}
return 0;
}
broken effect in Win7 with Aero Glass enabled
(The variable types are all double because the develoment platform (Game Maker) only allows for doubles to be passed to native code)
I've read that there are issues using colors that have the same value on multiple channels like white or yellow for chroma key, and tried using colors such as rgb (253,254,255) or (201,202,203), to similar results.
I've read that chroma keying apparently broke in Windows 7 RC1, and we can just assume that wasn't fixed for RTM due to the experienced behavior.
I've read that in Win 7 and earlier, child windows cannot be chroma keyed, and I've attempted to remove the window's parent using SetParent(), to similar results (and introducing other issues in the process), despite the window's parent being disabled and invisible when the application is launched in borderless mode.
The effect works fine until the window is updated, and then never again, which is an issue as the program has animated controls.
Was verified to work in various versions of Win 10 dated as far back as 1903:
effect working as intended in Win10
I've used an alternate method using DWM direct compositing using a 32 bit ARGB surface format, which allows per-pixel alpha transparency in all platforms, however does not allow for mouse hit testing, which is undesirable for this application due to its free-form window.
Even though the effect works properly in Win10, I'd like to support Win7 as well since that's a common target for the extension package this code is from.
A picture is worth a thousand words, so:
I use DwmExtendFrameIntoClientArea(this.Handle, AeroMargins); Where AeroMargins is a structure with Left, Right, Top, and Bottom properties. It works fine on Vista, Windows 7, and Windows 8 and 8.1.
However on Windows 10, there is a change in the window background where Left and Right margins end. It's exactly the same code that produces different results on Windows 10. Some colors (that you can pick in Settings, Personalization, Colors) are less obvious than others, but all show this defect. Has anything changed in Windows 10 that the old DWM code is not valid anymore?
I'm using the classic DrawString method to output text in a WinForms app. A typical call look like this:
g.DrawString(text, font, brush, new Rectangle(x, y, width, height), stringFormat);
If stringFormat.Trimming equals StringTrimming.EllipsisCharacter, the text suddenly "jumps" 1 pixel up if it is clipped and the rectangle of the same left/top/height is used:
This happens for many standards fonts like MS Sans Serif or Courier New, but does not happen for others like Segoe UI. And what is more strange, we can avoid this effect if we specify StringFormatFlags.DirectionRightToLeft for stringFormat.FormatFlags.
Is it a known issue of GDI+, and is there a workaround for that?
P.S. Tested all this in Win 8.1 Pro 64-bit, in an app compiled for .NET 4.0.
I made my first WPF app and brought it to work to use. My work computer's monitor is a maximum of 1680 x 1050, 96 dpi, Win 7 system, whereas my home computer is 1920 x 1080p, 96 dpi, Win 7.
The app doesn't display correctly on the work computer. Text is cluttered and 'doesn't fit' where it should, etc (the problem seems to be with the font sizing, only). I'm reading that I did just about everything wrong in regards to making the app support multiple resolutions, so I certainly have some reworking to do.
The odd thing is the work computer appears incorrectly at all lower resolutions, whereas my home computer appears correctly at all lower resolutions, including 1680 x 1050 - meaning I can't duplicate the problem on the computer I am working on the app on.
Here is the font I am using since that seems to be where the problem may lie:
<Setter Property="FontFamily" Value="Linux Libertine G"/>
What other factors could be affecting the appearance of my app besides resolution?
Why does WPF render differently on Windows XP vs Windows 7?
I'm using .NET SP1 on both computers..
My layout is like this window that has no toolbar and is set to maximize so it fits the whole screen.
Under that, I have a Viewbox set to use Stretch: Uniform, and under that I have my LayoutRoot.
This way I hoped to get the same layout on all computers, but it seems it doesn't render exactly the same on Windows XP. Some items are a bit smaller and the layout doesn't look that great.
I have tried to change my resoulution on my Windows 7 computer to the same as the Windows XP computer, and it keeps the layout like it is supposed to.
And both computers use 96 DPI.
Windows XP
Windows 7
Took me about three hours to finally figure this out - after much detective work, but now it is pixel perfect!
It appears that WPF on Windows XP and WPF on Windows 7 not only have different default font faces as well as a default font sizes.
I had a problem where fonts were rendering differently on Windows XP from how they were on Windows 7. It was quite critical since the final output was to the printer, and they needed to be identical. It appeared initially that the problem was a difference in line spacing.
Yes - I had the same exact font installed on Windows XP as I was using on Windows 7
Yes - I tried a very generic font (Arial) and still had the same problems.
Yes - Same DPI on both machines.
Yes - Same result whether in a VM (Windows XP Mode) or on a real Windows XP machine.
Eventually I discovered that the fonts where I was specifying an explicit size looked identical on Windows XP, and only the ones where I didn't specify an explicit size were they different.
So here's how I fixed it in my MainWindow.xaml - with a ContentControl to set a default size:
<Grid x:Name="LayoutRoot" Background="#FFDEDEDE" UseLayoutRounding="True">
<ContentControl FontFamily="Segoe UI" FontSize="12">
... window contents ...
</ContentControl>
</Grid>
Note: If you're using Blend you may need to enter FontSize="12" by hand. If you select it from the properties designer it will delete it, because it thinks 12 is already the default!
Like I said my destination was the printer - so I had to do the same for the control being printed.
Where else can I set this default font size? Anyhow, I now have pixel perfect rendering on Windows XP and Windows 7, and they differ only by the cleartype anti-aliasing differences.
Note: UseLayoutRounding is not part of my solution - but I always use it on my root control also.
The default fonts are different
Make a WPF button
<Button x:Name="button" Width="100" Height="25" Content="Button" Click="Button_Click"/>
and code behind:
private void Button_Click(object sender, RoutedEventArgs e)
{
string msg = string.Format("Number of fonts: {1}{0}Font Family: {2}{0}Font Size: {3}",
Environment.NewLine,
button.FontFamily.FamilyNames.Values.Count.ToString(),
button.FontFamily.FamilyNames.Values.First().ToString(),
button.FontSize.ToString());
MessageBox.Show(msg);
}
Run this on each operating system and you will see that the default fonts for XP and Windows7 are different.
Default font for XP is “Tahoma” size 11
Default font for Windows 7 is “Segoe UI” size 12
My experience:
I'm not sure if it is the issue, I noticed Windows 7 uses hardware acceleration to draw the WPF application. Windows XP doesn't.
You can check if this is the case by using something like this:
public partial class App
{
public static int Tier { get { return RenderCapability.Tier >> 16; } }
static App()
{
Console.Out.WriteLine("Render Tier: {0}", Tier);
}
}
Your rendering tier should return 2 if it used full hardware accelerated drawing. 0 = software, 1 = something in the middle if guess
Different versions of Windows have different default fonts (also different versions of the same fonts) and different font rendering engines - as a result the text size is different between systems.
You can try to set the font to the same font and see how it works, maybe try several fonts to check where the difference is smallest.