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.
Related
I'm trying to access the names and positions of desktop icons under win10 with no luck. I posted a similar question and solution (SO#58126669) when I was using Win7. Now I find the solution (which worked perfectly under Win7) doesn't work anymore under Win10.
Here's What I Know
Under Win7, the desktop icons are stored in a SysListView32 child of the desktop. Info about each can be obtained using LVM_* messages and associated structures.
Here's What I Don't Know
Under Win10, the view hierachy appears to have changed. The SysList view no longer contains the items, but rather it has a single child of class SysHeader32. The LVM messages did not work on it. I tried using comparable HDM_* messages and structures with no luck there either.
Does anybody know how to access the desktop icons under win10?
Windows 10 uses a different approach to the desktop vs. Windows 7 as commented on by #Raymond Chen. You must use COM objects like IShellWindows, IFolderView, etc. Rather than duplicate the code here, please see the answer SO #58126669 (Window 10 Addendum).
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.
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:
In the current project, I'm making an icon overlay. The actual implementation is completed.
And I made sure that it worked well in WindowsXP and Windows7.
But I want to appear to overlay icon immediately without restarting the explorer process.
So I found a way that SHLoadNonloadedIconOverlayIdentifiers function signals the shell and then load the nonloaded Shell Extension dll.
I make sure in the MSDN that minimum supported clinet of this function is Windows 2000 Professional.
In Windows7, this function worked fine, but it did not work in WindowsXP.
I would like to know why.
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.