I'm using the theme library to draw some text which works absolutely fine on Windows Vista - however, on Windows XP the returned HTHEME is NULL. This is the code I'm using:
HTHEME hTheme = ::OpenThemeData(pParent, L"TEXTSTYLE");
hTheme is valid on Vista, but NULL on Windows XP.
I've read the documentation for OpenThemeData and Parts and States on MSDN, but nothing mentions that TEXTSTYLE isn't supported on XP (even Google doesn't throw up any good suggestions).
The theme Luna (i.e. the Microsoft-made theme distributed with XP) defines only subset of classes and parts of Aero (Windows Vista and 7).
If you have access to machines with Windows XP and Vista (or 7) you may preview what's defined by Theme Explorer utility:
http://sourceforge.net/projects/mctrl/files/theme-explorer/
I presume that on XP you still have theming turned on? If you have turned off "bubblegum" mode - i.e. reverted to the classic look, then the Theming APIs all fail and youre expected to use the legacy APIs to draw the frame elements. DrawFrameControl etc.
Related
Hi I got a lil problem with a mobile handheld computer (Motorola MC9200) running Windows CE 7.0.
Within the browser (Internet Explorer + software like Naurtech CETerm) there is some font-smoothing or cleartype. Problem about that is that , and font with a css style of font-weight 900 for example look exactly the same as normal font. So you can't tell the difference.
Another problem would be the panning. I'm running a fullscreen web application and the user shouldn't be able to pan the whole screen 1 cm out. Funny thing is while the user is panning the whole picture the font-smoothing/cleartype is disabled and you can tell the difference between font-weights.
Anyone no a solution to that? I already searched the registry for cleartype and font but didn't find anything helpful. I don't have other WinCE 7.0 devices so I don't know if that problem is WinCE 7.0 related or related to the device.
I don't have a device at hand, but WEC 7.0 offers the SystemParametersInfo function that sounds a bit like what you're after.
Call it with uiAction set to SPI_SETFONTSMOOTHING to disable ClearType on a system-wide basis:
SystemParametersInfo(SPI_SETFONTSMOOTHING, FALSE, NULL, SPIF_SENDCHANGE);
Earlier versions of Windows CE had a registry setting to allow OEM's to disable ClearType, but I've been unable to locate this setting in WEC 7.0, so my guess is it's no longer supported and ClearType is always enabled by default.
Via qApp->setStyle you can change the style of your application. What I found is when I run on Windows 7 with windows 7 theme I can switch between:
qApp->setStyle(QStyleFactory::create("Windows"));
qApp->setStyle(QStyleFactory::create("WindowsVista"));
qApp->setStyle(QStyleFactory::create("WindowsXP));
But if I have my windows 7 setup with windows classic theme, I cannot switch between those 3. They all look the same.
How can I force my application to look like Windows Vista on Windows Classic theme PC?
Note: my system returns for QStyleFacory::keys():
Windows
WindowsXP
WindowsVista
Fusion
That's correct. On Windows, the "Vista" and "XP" themes are only active if you're using the same or higher theme on the user account. That's not due to Qt, but due to the behavior of the theming APIs on Windows.
According to Enable and Control DWM Composition:
Note As of Windows 8, the information in this section is no longer
valid. DWM can no longer be programmatically disabled, nor is it
disabled when an application attempts to draw to the primary display
surface. The following information applies to only Windows 7 and
earlier systems.
OK. So we can no longer programmatically disable DWM. But can it still be disabled? Will pfEnabled of DwmIsCompositionEnabled always be set to TRUE on Windows 8?
If composition can be disabled somehow, is DwmIsCompositionEnabled still somewhat useful in any manner?
According to Desktop Window Manager is always on (Windows) on MSDN:
In Windows 8, Desktop Window Manager (DWM) is always ON and cannot be
disabled by end users and apps.
In Windows 8, DWM desktop composition is a core operating system
component and cannot be disabled. With a few exceptions, desktop
composition is always on; it’s started before the user logon and
remains active for the duration of a session.
All of the options for disabling desktop composition that exist in
Window 7 are removed
Apps cannot use DwmEnableComposition to disable desktop composition.
In order to maintain backward compatibility, a call to this API will
return success; however, desktop composition is not disabled
Well, there's a pretty definitive answer. I'm somewhat curious what the "with a few exceptions" refers to, though... please add a comment if you happen to know. :)
Contrary to what people mention ("they removed the code", "the Basic theme is no longer there", etc.) the old visual style is alive and well in Windows 8.
The only problem is that it's not so clear how to use it for normal applications!
This isn't disabling DWM per se, but it is certainly disabling composition: just download the PowerToy Calculator for Windows XP and try running it in compatibility mode in Windows 8, and you'll see the old theme is still there:
I've been working on updating an old (Windows 95-era C API) application. While it works fine on Windows XP, on Vista and newer it always displays in a tiny 240x160 window with no menus or borders. What are the differences between Vista and XP that could cause this behavior?
On Windows 7, it looks like this (actual size):
This is what it should look like, and what it does look like in Windows XP:
We have SWT apps which use the setForeground method on windows XP, and they work fine. However, running the most recent stable SWT jars and dlls on Win7 seems to show the setForeground method being ignored. I know that the javadoc says it's a hint, but I wanted to know if this is because something changed between XP and 7, or if it's possible it's a system setting on my new Win7 install.
I had found this post: How to set SWT button foreground color?, but the main answer definitively says that setForeground is ignored on Windows, which isn't true in XP. Also, our problem doesn't seem to be limited to Buttons. Same issues happen with Groups as well.
Apparently, a hacky work-around exists by adding a paint listener that manipulates the GC directly to redraw the text with the appropriate color, besides being hacky, this is not practical, because it would mean we had to add this listener to the thousands places where we use Buttons.
Thanks for any help.
This doesn't have anything to do with your system settings. It's just that, as you have guessed, something has changed between XP and 7. Actually, it changed between XP and Vista. Unfortunately there is not much you can do about this, except for the hack that you have mentioned.
For more information, see this bug report.
Further investigation reveals that this is not a difference between XP and Windows 7, but rather the Classic theme vs the Aero or XP theme. If we use the XP theme in XP, Button foreground also cannot be set.