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?
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.
I am facing display issues with winforms in window 10 OS. The fonts used for forms is 'Estrangelo Edessa’. In windows 10, this font doesn't come installed by default and hence text/content looks ugly (cutoff/improperly sized). So i am thinking to change the font that looks closer to 'Estrangelo Edessa' and will be native to windows 7, 8 and 10. Please suggest one such font.
I suggest trying Verdana or Lucida Sans Unicode as they have similar proportions to Estrangelo Edessa. Alternatively, Calibri is narrower but otherwise similar and nicer to read.
You may also want to look into having your forms size the controls so text is never cut off, just in case. For example, all WinForms controls have a PreferredSize property.
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'm not interested in the hex code of the color, but its system name, to use in a Form and match the colors in different versions of windows
That pane is called the "Details Pane", as evident by the menu to show/hide it under Organize > Layout. I don't believe it has a system color since the background is actually an image, which was more obvious in Windows Vista:
In Windows 7, they just replaced it with a quieter image, leaving only the subtle shadow effect under the top border of the pane. In this thread they discuss changing the image in Windows 7, which further confirms that it is probably an image and not a color.
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 :)