Using Global Keyboard Hook (Wh_Keyboard_Ll) in Wpf/C#

Using global keyboard hook (WH_KEYBOARD_LL) in WPF / C#

You're creating your callback delegate inline in the SetHook method call. That delegate will eventually get garbage collected, since you're not keeping a reference to it anywhere. And once the delegate is garbage collected, you will not get any more callbacks.

To prevent that, you need to keep a reference to the delegate alive as long as the hook is in place (until you call UnhookWindowsHookEx).

High level global keyboard hook for C# and WPF for reading a keyboard wedge card scanner

Not sure what's going on, but getting a character like % out of a keyboard hook is very untrivial. The hook only notifies you of virtual keys. But % is a typing key, produced by pressing Shift + 5 on my keyboard (a US layout). Windows normally produces these characters by processing the WM_KEYDOWN/UP messages, generating a WM_CHAR message for the typing key. That's not happening in your case. The low-level Windows function that does this is ToUnicodeEx().

Keyboard hook get key combination (WPF)

Store the value of the key that is pressed and the next time your method is called check if this stored value and the actual value are your key combination.

    var lastKey;
void KListener_KeyDown(object sender, RawKeyEventArgs args)
        {

            Console.WriteLine(args.Key.ToString());
            if (lastKey == Key.LeftCtrl && args.Key == Key.C)
            {
                MessageBox.Show(args.Key.ToString());
            }
           lastKey = args.Key;
        }

Global Keyboard intercept input

EDIT - I was looking at the wrong message it seems so I remove the entirety of the old answer.

This seems to be correct callback function LowLevelKeyboardProc callback function. This is what it says for the return value:

If nCode is less than zero, the hook procedure must return the value returned by CallNextHookEx.

If nCode is greater than or equal to zero, and the hook procedure did not process the message, it is highly recommended that you call CallNextHookEx and return the value it returns; otherwise, other applications that have installed WH_KEYBOARD_LL hooks will not receive hook notifications and may behave incorrectly as a result. If the hook procedure processed the message, it may return a nonzero value to prevent the system from passing the message to the rest of the hook chain or the target window procedure.

So returning anything but zero should work.

Set keyboard hook to TextBox

PrintScreen is a key that triggers a system function, e.g. Copy screen to clipboard. The key needs to work no matter what UI control has the keyboard focus and is getting the rest of the keystrokes, e.g. your text box. The way to capture this key is with a keyboard hook. See this answer. I believe the code works in both Winforms and WPF.

How to make a global keyboard hook in C#

Electron has a way to create global shortcuts built-in, you just have to adapt the syntax a little to work with Electron.Net, you can search the repo to figure out function names (usually names are the same, just in PascalCase).

Registering a shortcut:

Electron.GlobalShortcut.Register("CommandOrControl+X", () =>
{
    Console.WriteLine("CommandOrControl+X pressed");
});

Unregistering a shortcut:

// Unregister specific shortcut
Electron.GlobalShortcut.Unregister("CommandOrControl+X");

// Unregister all shortcuts
Electron.GlobalShortcut.UnregisterAll();

ExecutionEngineException on LowLevel Keyboard Hook

As pointed out by the comments, you should not pass a lambda or delegate directly into a Win32 Api call (or any C api call for that matter). The fix is either to make a static variable containing a reference to the function

private static LowLevelKeyboardProc _handler = Handler;
[...]
_hook = SetWindowsHookEx(WH_KEYBOARD_LL, _handler, modPtr, 0);

or to pin the delegate, so the CLR won't move it around, which is what I opted for.

private LowLevelKeyboardProc _handler;
private GCHandle _gcHandler;

public KeyboardHook() {
    _handler = Handler;
    _gcHandler = GCHandle.Alloc(_handler);
}

[...]

_hook = SetWindowsHookEx(WH_KEYBOARD_LL, _handler, modPtr, 0);

For the low level hooks, you seem to be able to set modPtr to either LoadLibrary("user32.dll"), GetModuleHandle(null) or IntPtr.Zero. Seems to work with all of them.

Global Keyboard hook for (Excel) automation addin (not VSTO)

You should be able to solve your calculation chain problem since it sounds like a discrete set of sequential steps.
If using C++/XLL you would make the function arguments type P which would ensure they were calculated by Excel before being passed to the UDF. I think Ex cel DNA/addin Express should have the same effect if the parameters are defined as anything other than Object.

Excel calculates cells in a LIFO sequence which is set by the previous final calculation sequence and any cells that have been entered/changed: so the last formula changed gets calculated first.
So you should enter the formulae in your DATE_RANGE chain in reverse sequence (last one in the chain first)
Presumably you are already switching to Manual calculation mode at the start of this process. So it might be as simple as writing out the setup sheet and dates, then forcing a calculation (Application.calculate) then updating the MODEL_ID, then forcing another calculation.

And of course using Excel DNA the overhead per function call would be much lower anyway.
see http://fastexcel.wordpress.com/2011/07/07/excel-udf-technology-choices-snakes-ladders-with-vba-vb6-net-c-com-xll-interop/

---

Related Topics