Develop Reference

How can a screensaver continue to draw over the desktop in Windows 8?

I’m developing a screen saver in C# .NET4.0 on VS2010 which needs to do a fair bit of processing before it actually shows screens (fairly complex database access). This is fine because the user is unaware that this processing is going on and then the full screen forms kick in when everything is ready. That is, unless we are running on Windows 8.
Searching on the Microsoft Community (http://answers.microsoft.com/en-us/windows/forum/windows_8-desktop/bubbles-screensaver-has-black-background/e0807324-5ca6-4abe-b6ba-716848b41ff5?page=4) reveals that a design change was made in Windows 8 that prevents screensavers from drawing over an image of the desktop. Any screensaver that previously drew over the desktop will instead draw over a plain background using your chosen “metro” background colour. Experimenting reveals that this background kicks in immediately the .scr file launches i.e. before any forms can be displayed. Hence tricks like displaying forms minimised or with 0% opacity don’t work because this simply reveals the plain background underneath.
The best I’ve been able to come up with is to display full screen plain black forms as first action when my code starts i.e. before any database processing or other screen construction takes place. Why try to replace a plain screen with another plain screen? Well, because the default Windows background colour seems to be blue. That’s blue as in BSOD blue which looks kind of alarming when it kicks in. So the best I can do for a Windows 8 user experience is a quick flicker of blue followed by 3-4 seconds of plain black before screens are populated with something meaningful.
This new behaviour from Microsoft is apparently “by design”. The fact that it doesn’t manifest itself in Preview mode is apparently an error which one supposes MS will tidy up later.
So my question is does anyone know any way around this so that I can continue to have the desktop showing until screensaver forms are ready to kick in?

I struggled quite a lot with a similar problem regarding this awkward design decision in win8.
I the end had to compromise but my search continues for a a bullet proof solution, when I have time.
Now what I ended up with is running a batch file after the monitoring system starts and have thread detect idle time and run that batch again.
#start /wait Bubbles.scr /s & rundll32 user32.dll,LockWorkStation
What this does is:
starts screensaver preview in fullscreen (this works in win8) and waits
on user action lock screen is show and user prompted for password
As I said it's a compromise until a find something better. Hope it helps

Updated to win10; try to use that cool scr and found same issue;
Try to trick ms restriction and found only one very long solution:
enable logging of screensaver invoked events;
here instruction via gpedit: https://superuser.com/questions/538146/run-a-batch-cmd-upon-screensaver
now you will able to start other comand or app when screensaver starting;
goto C:\Windows\System32
copy Bubbles.scr and rename to Bubbles.exe
then config task to run C:\Windows\System32\Bubbles.exe with argument /s (administration->taskcheduler)
use some windows screensaver and config to use 1 min or more; (or use 'runsarver' with empty options from upper link or create your own empty.exe and rename to .scr and install with right menu, etc)
Found cool app to customize hidden screensaver features: http://winaero.com/download.php?view.8
(work with small bugs but work as needed under win10)
All work fine one cons checkbox to lock PC must be unchecked;
If needed create own app to run Bubbles and on exit lock PC or bat file as above, etc;
hope people will have fun with my solution :)

Windows Form Appbar Desktop Resizing

Okay. Just when you think you've figured it all out, you haven't.
I have coded and tested a functional appbar class. When I use a simple Windows Form to extend and test the class, it works without issue in both XP (SP 3, 32 bit) and Windows 7 (64 bit). Other windows are accessible, and they all maximize appropriately. However, when I take my "complex" Windows Form (i.e. it is an application) and derive it from the appbar class, the desktop seems to "kick" it out. By this I mean that everything sizes appropriately initially, but then the desktop resizes itself back to its former size. Sometimes this happens rather quickly after putting the form into appbar mode, other times it happens when I click outside the form (to open a browser, for instance), and other times it happens when the form calls a MessageBox. I have put all of the Forms functions in a background worker thinking that may be the issue, but the result is the same. I've posted three images below. The first one shows the application as its initial WinForm. The second shows the appbar "functioning." The last shows the appbar not "functioning." If you're having issues seeing the problem, pay attention to the Recycle Bin. Any ideas?
Edit:
I found these calls via logging. They appear to fire off each time the desktop resizes to "normal." Now I'm trying to see if there is or is not a similar pattern in the "simple" version.
msg=0x6 (WM_ACTIVATE) hwnd=0x1e03ea wparam=0x0 lparam=0x0 result=0x0
msg=0x1c (WM_ACTIVATEAPP) hwnd=0x1e03ea wparam=0x0 lparam=0x1a90 result=0x0
msg=0x1a (WM_WININICHANGE) hwnd=0x1e03ea wparam=0x2f lparam=0x9fe048 result=0x0
msg=0x1a (WM_WININICHANGE) hwnd=0x1e03ea wparam=0x18 lparam=0x9fe038 result=0x0

So this was one wild goose chase. In the event my last comment sounded absurd, it was. While I am still not 100% certain as to this theory (someone please prove/disprove at your leisure), the two different handles came from (1) instantiation of the Form and (2) the actual handle when the Form is loaded. I presume the API follows the same concept of QUERY_POS and SET_POS, that being it initially checks for and assigns a valid handle. Then, prior to the Form being shown, it double checks the handle value.
Long story short, one line of code to verify the handle value in the Load event solved the entire problem.
EDIT:
Better yet, the HandleCreated event is irreplaceable.

Detecting raised-event at OS-level (OS Appearance)

I have what seems to be a common problem. I am running Windows 7 Home Premium on one of the most awesomest computers (when it was bought last year) and certain visual effects just automatically turn themselves off.
My average user experience rating is high, so it doesn't explain why this happens. The only feature that ever gets turned off is the 'Show window contents while dragging' option. And it really annoys me.
There are currently no working solutions to this problem online. Other than to "there must be a conflict with another app installed on your machine."
And yes, I do know what app is causing this conflict. It's my bloody Internet Provider's software - you know... that app that you absolutely MUST have open at all times when you're connected to the net.
So, I had a thought. What if I could subscribe to an event so that my app that runs in the background will detect when this 'show window contents while dragging' option is turned off - and then my app will simply turn it back on again.
When I do this manually, it seems to stay in effect for about an hour or two, then it gets switched off again.
Is it possible to handle these types of events, and re-start certain visual effect features? If so, are there any resources on this?
I have not been able to find anything on this sibject yet.

Yes the WM_SETTINGSCHANGE message is sent to all windows when a system setting is changed. Then you can call SystemParametersInfo with SPI_GETDRAGFULLWINDOWS to determine if the "Show window contents while dragging" is disabled and use SPI_SETDRAGFULLWINDOWS to enable it.
So all that you will need to do is create an application with a form (that can even stay hidden) and override the forms WndProc and handle the WM_SETTINGSCHANGE message and call SystemParametersInfo using p/Invoke. The p/Invoke definition for SystemParamtersInfo is available at pinvoke.net
Altough what may be easier is change security on the HKCU\Control Panel\Desktop\DragFullWindows registry value so that it can't be changed.

Silverlight - First time going to Full Screen opens in background (FF, Chrome, not IE)

I have not found an answer to this, not here or when I have googled for it.
The case is that we have a silverlight with a video-stream. If we have enabled fullscreen with the code : Application.Current.Host.Content.IsFullScreen first time the application is taken to fullscreen it opens in the background (and for the customer it seems like nothing happens).
It seems it will remember it to the next time.
The alternative for our sake is to not enable it to disable this so that when the window loses focus it is taken out of fullscreen.
Is there a way to get around this, as we would both like to open it in fullscreen on top of the screen (not hidden), and have the possibility to make it pinned there. (Since many of our users would like to have it on another monitor and use the computer at the same time)
I have been thinking about storing it in application storage, as it seems it rememebers the first time a user move it in front. But dont know how this can be done, and also seems a bit hackish.
In IE this works, but of course this is not good enough.

To have your application stay fullscreen even when not focused, you have to add the following to your Application:
Host.Content.FullScreenOptions = System.Windows.Interop.FullScreenOptions.StaysFullScreenWhenUnfocused;
This will generate a prompt for permission when you switch to full screen mode, similar to IsolatedStorage quota prompts.
For the app showing in background, I only have experienced this using Safari on MacOS, I never had this issue on Windows IE, FF or Chrome. Maybe the line above will help matters though.

Are physical and programmatic keypresses handled differently by either .NET or the OS

Firstly some background information...
I have a C# .NET application that runs on a slate pc i.e. no physical keyboard. We are using the on-screen keyboard built into Windows XP Tablet edition to populate TextBox controls on a form. There is no special key press handling for the form (although other components of the UI do handle key presses).
Occasionally the on-screen keyboard will stop registering some key presses. The form still has focus and the cursor remains in the text box. Repeatedly tapping a key will eventually cause the character to be displayed. Our application uses a number of busy processing threads however it is far from 100% CPU utilisation.
When this behaviour occurs it remains that way until our application is restarted, after which the keyboard behaves normally. The problem does not occur at all when a USB keyboard is attached and used for input.
I'm interested in what differences there are between physical and programmatic key presses? Do programmatic key presses generate hardware interrupts as a physical keyboard would? Could .NET be handling each type differently?
Any suggestions that could help debug the problem would be much appreciated!

I've never worked with the tablet version of the XP OSK, but I have used the XP Embedded version. As far as I could tell the Windows API was sending key presses to .NET and MFC applications the same way. In fact, if I recall correctly, there was no way for us to tell the difference between the two programatically. As far as I know an OSK will not cause a hardware interrupt, however the virtual-key code will be sent to application-level programs in the exact same manner as a physical one.
Unless you are running a custom driver or something (that has access to the hardware layer), it sounds like it may not be your application that is causing the problem.
If you haven't already, I would check that the touchscreen has the latest drivers and is properly calibrated. I'd also check that the OSK has all the latest updates from Microsoft.