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:
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.
I need to place a link on the Windows home screen (before a user is logged in)
When this link is clicked, I want to launch a browser pointed at a specific web app.
This would be used to enable self-service password resets.
Is this possible? How would it be done?
EDIT: This must work on Windows 7 (and above) and Windows Server 2008 (and above)
In earlier versions of Windows, you could write a GINA DLL, which could completely replace the interface that was displayed to users during the logon process.
However, beginning with Windows Vista, GINA was removed and support was added for Credential Providers. While they provide improvements over the GINA model used previously, they also limit the flexibility afforded to developers with GINA - gone are the days when you could display a custom interface.
This isn't to say that it's not possible to have a custom provider display some UI elements. But launching a full-blown web browser is a horrible idea, plain and simple, and just asking for trouble.
You may want to check out the article Custom Login Experiences: Credential Providers in Windows Vista which is not fully up to date but is a good place to start from nonetheless.
I've used the following code on Windows Phone 7 and 8 to disable user idle detection when my App is displaying data to the user and they are unlikely to interact with the screen e.g. A recipe App where the screen needs to stay on:
http://msdn.microsoft.com/en-us/library/microsoft.phone.shell.phoneapplicationservice.useridledetectionmode(v=vs.92).aspx
Does anyone know if there is an analogue of this available for Windows 8 applications? My tablet app has the same requirement to disable the screen turning off. I haven't managed to find anything :-(
Many thanks,
Jon
You should use the DisplayRequest class, specifically DisplayRequest.RequestActive for this purpose. You must also remember to call DisplayRequest.RequestRelease once you are done to allow the display to sleep, for example, if you are not viewing a recipe, or you are in a menu screen, etc.
I have an app that runs on Windows 7 using Microsoft's Layered Window http://msdn.microsoft.com/en-us/library/ms997507.aspx. This app is setup to have a 30% opacity, it's always on top, and it is transparent to events (ie: it forwards all events to windows underneath it). You can think of it as a "screen" you are looking at your desktop through. It is currently being used to be an omnipresent feedback layer for our users.
We've tried running the same app on Windows 8, and notice it works as expected in desktop mode, but nothing overlays the start menu and other metro apps.
Does anyone know if there is an equivalent always on top window mode that works across metro apps and the start menu in Windows 8?
Yes, it is possible. Please take a look at this page:
http://blogs.microsoft.co.il/blogs/pavely/archive/2012/05/16/windows-8-topmost-vs-topmost.aspx
Specifically the second post in the comments section:
The topmost window is also affected by the accessibility settings. If you want a window on top of Metro, you need it to declare accessibility. Here are the key points:
The application must demand uiAccess (app.manifest)
The application must assert “topmost” window positioning (either in Win32/SetWindowPos or WinForms/WPF’s Topmost property, programmatically or otherwise)
Without making changes to the group policy setting, it must be installed to some trusted location [C:\Windows, C:\Program Files, C:\Program Files (x86)].
If you want to be able to run it out of an arbitrary location, you must disable the security setting: “User Account Control: Only elevate UIAccess applications that are installed in secure locations”.
This is the same as setting HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\ValidateAdminCodeSignatures to 0
Said application cannot be run in the debugger
If it’s a .NET application:
The manifest must be embedded in a post-build step
The application must have “delayed signing” (meaning it cannot be ran from the built-in debugger, although you can build and attach – this is what Microsoft does)
The application must be signed with a trusted certificate.
Said trusted certificate must be installed to the Trusted Root Certificate Authority (this is important! It must not just simply installed)
Run the windows speech recognition. Its a top most window which floats over start menu, desktop etc. So its possible for sure. I am working on a touch simulator for Windows 8 and needed to implement this feature.
Here are the steps to achieve this:
http://www.pixytech.com/rajnish/2013/05/windows-8-topmost-window/
I am almost positive that you can't have any other app overlaying a Metro app. The new Metro environment is meant to run single, full-screen apps (or two, but only if snapped to the side). Further, allowing something to act as a man-in-the-middle is a bit dangerous, since they could capture all sorts of sensitive user data.
That being said, if you can set the "always on top" property of a window, it might stay put over the Start menu and various Metro apps. I know it works with Task Manager, but I have never tried with an arbitrary app. I do not know that it would work well for Metro apps, however, due to their events being different than old-timey winform apps. You'd have to see if your "screen" allows touch events to pass through.
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.