Develop Reference

WPF on Windows 7 with touch: hide touch cursor

I have a WPF application that, due to hardware constraints, has to run on Windows 7 Standard Embedded. The device is touch enabled and I am taking advantage of that in the way that I am building the application.
One of the problems that I have is that whenever the user touches the screen, a small "pointer" appears showing where the user has touched. This can apparently be turned on and off at a system level (http://windows.microsoft.com/en-US/windows-vista/Turn-the-touch-pointer-on-or-off) however ideally I want to turn it off at a WPF application/form level so that the user is not having to disable and enable the cursor each time they go in and out of the application.
Does anybody have any ideas as to how this can be achieved? I have tried searching various combinations of Windows 7, Touch, Pointer etc. but bar the above article I only ever seem to come back with how to enable touch events.
I should also point out that the hardware constraints currently rule out any option of upgrading to Windows 8, 8.1 or 10 so please do not consider this in any answer you may have.
Thanks.

Set the following properties of the Window to false...
Stylus.IsTapFeedbackEnabled
Stylus.IsTouchFeedbackEnabled
Stylus.IsPressAndHoldEnabled
Stylus.IsFlicksEnabled
They are probably not all required; but this worked for me.

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 :)

C# - Transparent Window to defeat Keyloggers

How can I create a window which is fully apparent to the user but is not visible in screenshots. I know that this is possible since Neo SafeKeys (an onscreen keyboard to defeat keyloggers) does not appear in the screenshots taken by keylogging software I installed.
To give you an idea, the window is fully visible to the user, however when a screenshot is taken, the Neo SafeKeys window does not appear at all (as if it does not even exist).
Neo SafeKeys states that it uses an invisible protection layer above the window to protect against screenshots. I have searched all over the internet to see how can I reproduce this, to no avail. Does anybody know how this can be performed (windows which is visible to user but invisible in screenshots)?

What you can do is you can prevent the PrtScn key from doing anything when pressed. Take a look at this article while shows you how to do this.
What this article is doing is clearing out the clipboard. What you can do instead is capture the screen image and digitally remove your application, then put the revised image on the clipboard, thus giving the "Effect" of making your window transparent.
Also, you might want to look at this SO question which gives an alternative way to make your window just appear "blue", though its not easy to do.

Does anybody know how this can be performed (windows which is visible to user but invisible in screenshots)?
Use DirectX to render directly to the device.

In your C# application you can set up a global hook to monitor keyboard events. Then your application becomes the global handler for print screens. Now if another application managed screen prints natively, can't stop that, but anything running through windows, you can get at.
The WM_KEYBOARD_LL hook is one of the few global hooks that can be used in managed code because it doesn't require a DLL to be injected into every target.
For some code you can visit here:
Adam's Blog
Keep in mind that these are global hooks so you want to make sure nothing else (other applications) are effected. I've used these in the past as we hosted showing a power point in an application we worked on. Basically we didn't want the user to invoke any powerpoint menus or keyboard short cuts so we used a global hook. We always checked to see whether the users was in a certain area (screen) and in our application, otherwise we would effect other applications functionality (including our own!)
Microsoft Information:
Hooks Overview

There's this.....
visual cryptography
live example here
But this could be easily coded against by taking multiple screenshots and laying them overeachother and such...

If you are using Windows, and you can avoid that screenlogging happens, you can implement a nice solution like a virtual desktop to embed your process into it. When a process is running inside a virtual desktop it is possible to bypass an screenlogger tool that runs over win32 Api.
Check out this article so you can sneak a peek how to implement a nice solution to scape from screen and keyboard monitoring.
http://www.codeproject.com/Articles/7392/Lock-Windows-Desktop?fid=62485&select=3139662&fr=101#xx0xx

remote desktop application with wrongly displayed buttons

I have a winform within a remote desktop application that is built dynamically with a container panel for a toolbar with large (regular) buttons. The application is writen in C# and .NET 4.0. The application is viewed as it should only if I do not maximize the window (meaning restored view is fine).
Now, after RDP login - within most client computers - the application looks fine (even when we maximize and restoring). Within low resolution client computers (800x600), the buttons on the toolbar are not displayed in the right position (such as in the 1024x768 clients).
I used double buffering and it didn't help... the problem may or may not be depended on the screen resolution (it can be memory issue or something). It is not a problem of localization layout.
The following image shows the Fine and Bad states: http://imgur.com/gO4UJ,v7O9K
What can I do to resolve this issue?

OK, so in case anybody gets to this kind of case, this is the thing that made the issue:
In the form, there was an empty repaint override. The programmer that created the form was overriding the repaint with an empty method (don't know why, I guess I'll ask my team for the business logic).
How did I reproduce it in the development environment? Following Albin Sunnanbo's note, I ran the RDP application in minimized version during initialization, and I noticed that it occurs with large resolution clients also in this use case... So, I know repaint occurs while performing a window resize - and this made me suspicious about the method...
==> On a side note, I guess this is why inheritance is so bad, and going on to WPF is better. It took me 3 days to understand why this issue occurred.

WPF application unable to handle remote desktop resolution change

I'm working on a .NET 4 WPF application, and just the other day, came across a very peculiar bug. I have three Windows 7 Pro machines involved: laptop (1366x768), desktop (1680x1050, multi-monitor), and the remote machine (resolution unknown). Our application is installed on the remote machine.
Consider the following events: I remote desktop into the remote machine from my laptop, start our application, and launch a particular feature (an mdi child) within the application. If I connect to the same remote session from my desktop (thus closing the session on my laptop), this feature within my application becomes completely unusable. By unusable, I mean combo box drop downs are showing in the top/left corner (much like what's described here), other controls aren't laid out correctly, and some controls don't even show at all. Mouse coordinates appear to be off in that clicking certain controls no longer invokes the appropriate actions. It's the strangest thing I've ever seen.
If I close the application and launch a new instance on my desktop, things work great. Also, it only seems to happen when I launch the feature on my laptop, then move to the desktop. Never the other way around.
I wish I could show some code, but I don't really even know where to start or what to show. I can say that it only happens on certain features. Some features handle the resolution change perfectly.
Has anyone else seen these types of symptoms? Or know what could cause them or how they could be fixed?

This is a little embarrassing. After a few hours of "process of elimination", I found that another developer had added some unmanaged code to automatically maximize the window. The approach they followed is documented here. This approach does not work through remote desktop sessions. Lol.