My app has an option to disable aero by calling DwmEnableComposition(0) before capturing a screen image. As you know, disabling aero makes the screen go black then return to normal afterwards. On different PCs this might take 2 to 3 seconds depending on how fast the system is.
Is there a better way of determining if aero has fully disabled before screen capture instead of Thread.Sleep()?
You should be able to do this using the related API function DwmIsCompositionEnabled. The other option might be to listen for the WM_DWMCOMPOSITIONCHANGED event.
Your form's Paint event will run. That doesn't mean all windows will be fully painted, but you can sleep less. Listening for the notification message by overriding WndProc() may work, not sure when it is sent. WM_DWMCOMPOSITIONCHANGED is message 0x31e. I suspect it will be sent too soon, all windows probably have to repaint themselves next. The only way to be sure is to enumerate the windows with EnumWindows and call UpdateWindow. Visit pinvoke.net for the P/Invoke declarations you'll need. Sleep() will work too but there's no way to guess an amount that's guaranteed to work everywhere.
Have you looked into DwmIsCompositionEnabled? This page also says Applications can listen for composition state changes by handling the WM_DWMCOMPOSITIONCHANGED notification.
Related
I am writing an Alt+Tab replacement in C#, and have trouble with fullscreen applications.
Is there a way to detect if a SetForegroundWindow(hWnd) call is going to change the screen resolution? Or equivalently, if hWnd is a fullscreen application? I would like to wait until the resolution change is done, or if there is no change, proceed immediately.
The screen resolution change is done asynchronously, the function call returns well before it happens, so my code runs prematurely, and draws my application onto the surface of the fullscreen application, with wrong dimensions, then after the resolution change, it looks especially ugly.
Source of my application is at https://bitbucket.org/FrigoCoder/frigotab/src if anyone is interested.
To clarify, I would be more interested in knowing beforehand if a resolution change occurs than detecting it later. I already know a half-solution where I call SetForegroundWindow() on GetDesktopWindow() or some other window and watch SystemEvents.DisplaySettingsChanging and DisplaySettingsChanged. This however only gives me a late asynchronous notification if a resolution change occurs, and does not tell me if it does not.
I managed to solve the issue. Instead of trying to detect fullscreen applications, I simply send an inactivation message to the foreground application, which triggers an early resolution change:
SendMessage(GetForegroundWindow(), WM_ACTIVATEAPP, false, GetCurrentThreadId());
This exact same message is also sent during application switches, so I essentially emulate one before it actually happens. I have not encountered any side effects yet.
Mind you however, that this does not solve DWM issues. Windows 7 automatically disables DWM composition for compatibility launches, or when it detects direct access to the primary display surface. It does not allow you to re-enable, and I do not see an easy solution to this problem. Thankfully this issue will eventually go away since DWM composition is always enabled in Windows 8 and newer.
Perhaps the Winforms Event SizeChanged can help you.
You could use this event as a continuation of sorts for the rest of your code. In the case that the event doesn't fire due to no resizing, you could have a secondary continuation that will run after a specified timeout. It's not perfect, but may meet your needs.
I'm working on a kiosk style application where I need to control the shutdown/restart of the PC when the power button is pressed. Thanks to this post, I'm about 90% of the way there.
In control panel set the acpi power button press action to shutdown.
Listen for the WndProc message WM_QUERYENDSESSION
When received issue the completely undocumented:
[DllImport("user32.dll", SetLastError = true)]
static extern int CancelShutdown();
Return from the WndProc and bring up my own message box asking the user to Shutdown / Restart or Cancel, and respond to their action.
Everything works well if I do a start / shutdown from the task bar (I can issue theses as fast as I want). Everything also works well the first time I press the power button. On subsequent power button presses though I see a minute or so delay before I receive the WM_QUERYENDSESSION message.
Is there a setting or registry entry about how often windows will issue an ACPI event? I know it's not the hardware because under linux the same machine will fire the ACPI event as fast as I can press the button.
Thanks.
Calling in some favors at work, I was able to take this question directly to Microsoft support. On my third support engineer, I was essentially told this is not possible at an application level. It was his belief that calling the undocumented CancelShutdown() "confuses" the power manager or acpi driver which leads to the WM_QUERYENDSESSION message delay. Since the CancelShutdown() is undocumented, MS is not willing investigate further.
So, how do you hook power button presses? You need to write a device driver, specifically an ACPI Filter Driver. We are investigating this now.
I don't think it is possible unless you speak with your hardware manufacturer or hardwire the start-button so that it doesn't send a signal to the hardware which handles this.
You can only delay it but even that would not give you 100% guarantee I guess.
Windows 8.1 will (maybe) bring a Kiosk Mode. Maybe that is what you are looking for ;-)
I need help handling minimized programs when using a custom/self made explorer.exe file .. because unless properly handled, minimized programs will just shrink to something like 100x50px and stay on screen. I worked out a Timer in C# to check for "iconic" processes, list their mainWindowHandler, and move them outside the screen with "MoveWindow". To bring them back I use the handler and the "ShowWindow" function wich works AWESOME .. but as I said, it involves a constantly running Timer, so there must be a cleaner/easier way of achieving this.
Any ideas? Some way to hook and raise an event when a window is minimized?
*please note: show and movewindow are functions from user32.dll. I'm not trying to catch when MY forms are minimized, but when the OTHERS programs are.
You can create a hook to check when windows are being minimized.
I found a CodeProject article that uses hooks to check when the user opens a system menu (ALT+SPACE) on any window, and then appends an extra item to it. You can use that code to check when the user hits the minimize button, and run whatever code you need there.
The CodeProject article is written in C++, but you can adapt the same method for C# (or use P/Invoke).
How can I disable Print Screen functionality while my WPF application is running?
The use-case is that my client wants to avoid unnecessary replication of valuable patient-centric data from the outside world and they provide the physical security to keep people from taking data through non-digital means.
Okay, it is possible, and could indeed be useful if your application is deployed in an environment where a camera is not available to the user.
First of all, I used the RegisterHotKey and UnregisterHotKey API calls, documented here http://pinvoke.net/default.aspx/user32.RegisterHotKey as described in this rather old article here http://msdn.microsoft.com/en-us/magazine/cc163713.aspx.
I registered the IDHOT_SNAPDESKTOP hotkey in the Window_Load event and unregistered it in the Window_Closed. Trying to do this in the constructor gave me problems getting a consistent handle with the WindowInteropHelper(this) method.
If you'd like to do more than just ignore the keys you can set up a windows message handler, making a kind of WndProc using,
HwndSource source = HwndSource.FromHwnd(<handle>);
source.AddHook(<WndProc>);
making the handle as described above, and the WndProc implementation yourself.
As yet, I don't know how to "not" handle the hot key and get windows to perform its normal behaviour except, of course, by unregistering the hotkeys.
Its not very elegant or "WPF" but it worked for me.
As #ghord comments
The use of EnsureHandle() looks useful for getting a handler in the constructor.
It's not possible to disable printing, and even if it were possible, it would be easily circumvented by a cell phone camera. Many are in the megapixel resolution range, making it quite easy for someone to get the information they want.
If you want to disable the Print Screen Key on your keyboard, Jodrell's answer gives a way of doing that (understanding that it's not going to keep people from printing, and a determined user will find a way around that).
Really, it all comes down to trust. If an employer can't trust their employees not to remove data that is already protected by law in most jurisdictions (HIPAA in the USA), then there's a bigger issue at stake.
Easy:
Windows.UI.ViewManagement.ApplicationView.GetForCurrentView().IsScreenCaptureEnabled = false;
Simply speaking, you cannot. "Print screen" just copies the pixels on the screen to the clipboard, and is not part of your application.
Basically you can hook to the ClipBoard events and then set the image copied to null if someone does it. So they can copy the image but it will be reset:
Have a look at this:
Clipboard event C#
Alternatively in a timer, check the content of the clip board and clear it as soon as it is set to a picture.
No, No way to do that. Even if you capture the Print Screen key in your application user might set focus to some other application and then do the Print screen(having your application on side etc.).
Only way would be to create a dummy application in background which captures all keystrokes using Keyboard Hooks and filters Print Screen, but that will happen for all applications not just yours. And moreover as George said user can use cellphone camera too!
I think Microsoft Rights Management System can help. Give it a try. Following is the link:
Microsoft Rights Management System
The only way I can think of is to use the native Windows API (SetWindowsHookEx) to catch all keystrokes and filter out the PrintScreen key. However this would involve creating a native (i.e. unmanaged) DLL to actually do the keystroke processing.
I have a windows form application which needs to be the TopMost. I've set my form to be the TopMost and my application works as I'd like it to except for in one case.
There is a 3rd party application (referred to as player.exe) that displays SWF movie files on a portion of the screen that popup on top of my application.
Using Process Monitor I determined that player.exe application calls
flash.exe <PositionX> <PositionY> <Width> <Height> <MovieFile>
in my case:
flash.exe 901 96 379 261 somemovie.swf
Since flash.exe is being spawned in a new process after my form has been set to the TopMost it is appearing on top of my application.
First thing I did was make my application minimize the player.exe main application window hoping that this would prevent the Flash from appearing also. But, unfortunately it doesn't... even with the window minimized whenever the flash movie starts it shows up at the pixel location (901,96). I then tried creating a timer to keep setting the form.TopMost property to true every 10ms. This sort of works but you still see a very quick blip of the swf file.
Is there some type of Windows API call which can be used to temporarily prevent player.exe from spawning child processes which are visible? I admit it sounds a little far fetched. But, curious if anyone else has had a similar problem.
Addendum:
This addendum is to provide a reply to some of the suggestions layed out in Mathew's post below.
For the emergency situation described in the comments, I would look at possible solutions along these lines:
1) How does the third party application normally get started and
stopped? Am I permitted to close it
the same way? If it is a service, the
Service Control Manager can stop it.
If it is a regular application,
sending an escape keystroke (with
SendInput() perhaps) or WM_CLOSE
message to its main window may work.
Easiest way to close the app is to CTRL-ALT-DEL, then kill process. -OR-
The proper way is to Hold ESC while clicking the left mouse button... then input your username and password, navigate some menu's to stop the player.
There is no PAUSE command... believe it or not.
I don't think using WM_CLOSE will help since minimizing the application doesn't. Would that kill the process also? If not, how do you reopen it.
2) If I can't close it nicely, am I permitted to kill it? If so,
TerminateProcess() should work.
I can't kill the process for two reasons. 1) Upon relaunch you need to supply username/password credentials... There may be a way to get around this since it doesn't prompt when the machine is rebooted but... 2) Whenever I kill the process in task manager it doesn't die gracefully and asks if you want to send an error report.
3) If I absolutely have to leave the other process running, I would try
to see if I can programmatically
invoke fast user switching to take me
to a different session (in which there
will be no competing topmost windows).
I don't know where in the API to start
with this one. (Peter Ruderman
suggests SwitchDesktop() for this
purpose in his answer.)
I got really excited by this idea... I found this article on CodeProject which provides a lot of the API Wrapper methods. I stopped implementing it because I think that in order for desktop's to work you must have explorer.exe running (which I do not).
EDIT2: On second thought... maybe explorer.exe isn't needed. I'll give it a try and report back.
Edit3: Was unable to get the code in that article working. Will have to put this on hold for a moment.
Answer Summary
As one might have expected, there is no simple answer to this problem. The best solution would be to problematically switch to a different desktop when you need to guarantee nothing will appear over it. I was unable to find a simple C# implementation of desktop switching that worked and I had a looming doubt that I would just be opening a whole new set of worms once it was implemented. Therefore, I decided not to implement the desktop switching. I did find a C++ Implementation that works well. Please post working C# virtual desktop implementations for others.
Setting the TopMost property (or adding the WS_EX_TOPMOST style to a window) does not make it unique in the system. Any number of topmost windows may be created by any number of applications; the only guarantee is that all topmost windows will be drawn 'above' all non-topmost windows. If there are two or more topmost windows, the Z-order still applies. From your description, I suspect that flash.exe is also creating a topmost window.
Aside from periodically forcing your window to the top of the Z-order, I think there is little you can do. Be warned, however, that this approach is dangerous: if two or more windows are simultaneously trying to force themselves to the top of the Z-order, the result will be a flickering mess that the user will likely have to use the task manager to escape.
I recommend that your program not attempt to meddle with other processes on the computer (unless that is its explicit purpose, e.g. a task manager clone). The computer belongs to the user, and he may not value your program more highly than all others.
Addendum:
For the emergency situation described in the comments, I would look at possible solutions along these lines:
How does the third party application normally get started and stopped? Am I permitted to close it the same way? If it is a service, the Service Control Manager can stop it. If it is a regular application, sending an escape keystroke (with SendInput() perhaps) or WM_CLOSE message to its main window may work.
If I can't close it nicely, am I permitted to kill it? If so, TerminateProcess() should work.
If I absolutely have to leave the other process running, I would try to see if I can programmatically invoke fast user switching to take me to a different session (in which there will be no competing topmost windows). I don't know where in the API to start with this one. (Peter Ruderman suggests SwitchDesktop() for this purpose in his answer.)
You can use the Process class to start flash.exe directly - and use an appropriate ProcessStartInfo settings to show the window in a hidden state - or with a WindowStyle of hidden or minimized.
You could also consider using the SetWindowsHookEx API to intercept the process start API calls, and when the process is flash.exe run some code to restore you window to top-most status.
Matthew's answer is excellent, but I suspect you may be asking the wrong question. Why does your application need to be topmost? If you're trying to create a kiosk or some such, then topmost is not the way to go.
Edit: After reading your response to Matthew's comment, I'd suggest creating a new desktop and switching to it before displaying your alert. (See CreateDesktop and SwitchDesktop in MSDN.)