C# global hotkey (without the usually used global hook) - c#

I'm creating a program for my personal use that must react to some hotkeys. For example, when I press ctrl+win+z it must perform a certain action. At present, I can use GetKeyState() from user32.dll to detect the keypresses, however I am unable to stop them being passed to the active application. In the case of ctrl+win+z, the action I want to happen occurs, but if I am using explorer, for example, explorer will also read that as an 'undo'.
The obvious solution would be to use "SetWindowsHookEx()" (also from user32.dll), however each time I try a solution involving it (anything similar to this site's example code) I get a massive slow down the first time I use the hotkey. This is not acceptable.
I hope someone can help. I can provide more information if required.

Have you tried the RegisterHotKey function? It's definitely easier to use than a windows hook.

Related

How to send direct input to another program on windows?

If you have used GameRanger, you will better understand this question.
I want to send a direct input, like keystrokes and mouse clicks, to another program (given that I know its executable) on Windows.
So far, I've been using .NET's SendKeys class, according to this MSDN article.
The program that I'm targeting is another .NET application, but I was having a lot of trouble, as it opens a large number of windows, with random handles every time (and names). Thus, I couldn't figure out a way to reliably verify that the particular window that I wanted was open. My solution was relying on the user to have it open, and having focused the correct input control, then my application sending alt+tab and writing its thing with SendWait*.
It does work fine most of the time, but it's the very antithesis of robustness. GameRanger does a similar thing, but much better. How can I achieve the same reliability? Any method/library that can run on windows is ok, if it's in C#, the better.
*Sometimes, a SendWait call might get lost; I haven't forced the new implementation as instructed in the msdn article, I will try it if nothing better exists.

Getting all the pressed keys everywhere

So is there possible to intersect all keys pressed everywhere, where everywhere is at any application? More or so like a keylogger. I was wondering if that is possible in C++ or C#.
Regards
What you're looking for is a Keyboard Hook. This is possible using some P/Invoke. See sample here:
http://www.codeproject.com/KB/cs/CSLLKeyboardHook.aspx
If you want to use winapi thaen function you are looking for is SetWindowsHookEx with flag WH_KEYBOARD. If you want to get really all kes you might use low-lewel flag instead WH_KEYBOARD_LL, but this will not translate keystrokes, so it's more difficult to work with.
I never used this flag, but i know that some flags need registered hook function to be in separate module (eg. dll) as they will be loaded and executed executed in context of application that actually recieves keyboard input. If it is so you must also think of a mechanism of returning colected data back to your application, cause global variables will not work.

how to disable "PRINT SCREEN" button while running my Application in WPF?

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.

Is it possible to programmatically check when a .NET control will set off UAC?

I'm trying to use reflection to have a program look at itself and determine whether a certain control triggers UAC. I'd either like to be able to see that the event handler on the button creates a privileged process or to check whether a given button has the UAC shield enabled on it. Is this possible?
It should be possible to write something like what you are asking for using cciast.codeplex.com.
CCIAST lets you decompile methods. That way you can find out if the method runs a potentially priviliged process.
But depending on your software it might not produce the results you are hoping for.
Best, if possible, would probably be to refactor to only launch priviliged processes from a small and known set of methods and then use refactoring tools to find how uses them.
I think this will only be possible by running the control's function and seeing if you get access denied. This is based on consider a control that creates a file in a location defined by its container. Changing the path gives a different answer to the "UAC needed?" question, and the paths than require UAC will also depend on the current user.
If you know what the control does (what system resources it tries to access) and the manifest of the containing application it should be possible to work it out on a case by case basis, but this might end up simply repeating the logic of the OS in cases of the registry, service management and filesystem where different objects have different access.

How to write my own Global Snippets program with .NET?

I want to write my own global snippets tool for Windows XP and higher. This would be an always running in the background tool that would pop-up on a globally-defined hotkey, allow me to select a snippet with substitution arguments, and then paste the expanded snippet into the text input of whatever control I had been in when activated it, and finally, return me to that previous app/input box.
I know how to do most of the algorithmic aspects, but I do not know how to accomplish these windows-based features:
1 - Global Hotkey: how do I define a key-sequence in windows (from .net?) that will work, even when entering data in another apps textbox? (Usually this will be a browser window)
2 - Pasting Into Another App: I could use the paste-buffer and Ctrl-C, but I want to avoid the extra keystrokes.
3 - Return Control to Original Window: Seamlessly return back into my input stream: how do I do that? In fact, how does my tool even know where I was before it popped up?
The reasons that I want to write this myself is first to learn how (because there are other tools like this I would like to make) and secondly, I don't know of any snippets tools that have the argument substitution that I want.
So, the two (2)questions are A) What should be my general approach? and B) how best can I accomplish items 1 to 3 above?
You'll need to use global system keyboard hooks to capture your hotkey. There is a CodeProject article showing how to do this from within .NET.
Once you've "trapped" your keystroke, you can use the Windows API to get the current windows handle. However, I'd try to avoid activating your application. You should be able to just paste your new text, and allow the application to handle it.
The disadvantage of using the Windows API is that it doesn't work in all cases, and the "broken" cases are getting more and more common. For example, WPF applications do not provide a HWND for each element within a window, so getting the current "control"s handle will just give you the window, not the appropriate element.
Edit: Another reference source is this article in MSDN Magazine. It shows how to do this via C# using P/Invoke.

Categories

Resources