Develop Reference

How to get WH_KEYBOARD_LL to work in a Universal Windows Platform Builds

Background: I have a library which requires keyboard scancodes (Not KeyCodes from the enum) which I am trying to get working with Unity for the HoloLens.
The only way to obtain scancodes from C# I have found so far is to use the Windows Hook system through PInvoke by registering a hook for WH_KEYBOARD_LL through SetWindowsHookEx
[DllImport("user32.dll", CharSet = CharSet.Unicode, SetLastError = true)]
static extern IntPtr SetWindowsHookEx(int idHook,
LowLevelKeyboardProc lpfn, IntPtr hMod, uint dwThreadId);
Documentation https://msdn.microsoft.com/en-us/library/windows/desktop/ms644990(v=vs.85).aspx
The suggested way is to call it like this
IntPtr hHook;
using (Process process = Process.GetCurrentProcess())
using (ProcessModule module = process.MainModule)
{
IntPtr hModule = GetModuleHandle(module.ModuleName);
hHook = SetWindowsHookEx(HookType.WH_KEYBOARD_LL, hook, hModule, 0);
}
see http://www.pinvoke.net/default.aspx/user32.setwindowshookex
This works well on PC builds, but the Remark for UWP in the documentation for SetWindowsHookEx is confusing me:
Windows Store app development If dwThreadId is zero, then window hook
DLLs are not loaded in-process for the Windows Store app processes and
the Windows Runtime broker process unless they are installed by either
UIAccess processes (accessibility tools). The notification is
delivered on the installer's thread for these hooks:
WH_JOURNALPLAYBACK WH_JOURNALRECORD WH_KEYBOARD WH_KEYBOARD_LL
WH_MOUSE WH_MOUSE_LL This behavior is similar to what happens when
there is an architecture mismatch between the hook DLL and the target
application process, for example, when the hook DLL is 32-bit and the
application process 64-bit.
As I understand I have to specify dwThreadId on UWP, otherwise it will not work. But if I do so using GetCurrentThreadId() (again through pinvoke), I get an error code:
ERROR_GLOBAL_ONLY_HOOK
1429 (0x595)
This hook procedure can only be set globally.
Setting hMod from GetModuleHandle(NULL) and dwThreadId to NULL creates a valid hookID but again no events arrive.
Since then I tried to search for ways to obtain a module handle, but did not find any way that works on UWP:
Process.GetCurrentProcess does not compile, missing
Marshal.GetHINSTANCE missing
GetType().Module.Name missing (for GetModuleHandle)
What else can I try?

The only way to obtain scancodes from C# I have found so far is to use the Windows Hook system through PInvoke by registering a hook for WH_KEYBOARD_LL through SetWindowsHookEx.
Unfortunately, the solution that you have mentioned is not applicable for UWP. For your requirement, you could use the AcceleratorKeyActivatedevent, and the AcceleratorKeyEventArgs provides the ScanCode value directly.
public MainPage()
{
this.InitializeComponent();
Window.Current.Dispatcher.AcceleratorKeyActivated += Dispatcher_AcceleratorKeyActivated;
}
private void Dispatcher_AcceleratorKeyActivated(Windows.UI.Core.CoreDispatcher sender, Windows.UI.Core.AcceleratorKeyEventArgs args)
{
var scanCode = args.KeyStatus.ScanCode;
}

SendKeys.SendWait doesn't work on Stella Emulator

Have tried a couple of days without any sucess.
I'm just trying to send keystrokes to a process, which is an Atari video game emulator (Stella).
My app is a Console Application in C# made with VS 2013, running in 64 bit Windows 7.
Method Sendkeys.Wait works fine with almost any app, e.g. calc, excel, notepad, etc.
Tried some approachs, such as:
[DllImport("USER32.DLL", CharSet = CharSet.Unicode)]
public static extern IntPtr FindWindow(string lpClassName, string lpWindowName);
[DllImport("USER32.DLL")]
public static extern bool SetForegroundWindow(IntPtr hWnd);
static private void Teste(string key)
{
IntPtr stellaHandle = FindWindow("SDL_app", "Stella 4.6.7: \"River Raid (1982) (Activision)\"");
SetForegroundWindow(stellaHandle);
SendKeys.SendWait(key);
}
I compiled in Any CPU, x86 and x64, used 32 and 64 bit versions of Stella, tried also with an other emulator (Z26), even tried with a javascript emulator running in Firefox (http://www.virtualatari.org).
None of my approachs worked. Get the window is ok. Set the window as foreground also ok.
Any idea? Someone faced such a problem before?
Thanks in advance.

can´t connect using dll from windows service

I have a windows form application which is working fine. I created now a windows service with FileSystemWatcher, it went ok.But when I copied the code from the windows form I had before it doesn´t work. (It is working on the windows form)Is there anything I need to take care working with windows services?.The application (windows forms) is to receive a file, make some operations with that information and then using an dll, comms with a scale.
[DllImport("mydll.dll")]
public static extern int OPENETHNET();
[DllImport("mydll.dll")]
public static extern int ETHWRITE(string in1);
[DllImport("mydll.dll")]
public static extern int ETHREAD(StringBuilder in2);
[DllImport("mydll.dll")]
public static extern int CLOSEETHNET();
and then I use it like this:
string inputStatus = "050";
StringBuilder resultStatus = new StringBuilder(1024);
openRest = OPENETHNET();
if (ETHWRITE(inputStatus) == 1)
{
ETHREAD(resultStatus);
}
CLOSEETHNET();
It doesn´t even opens the conection..
I tried to change the account to LocalService and the other options but, still the same.. Any ideias?
EDIT:
I saw the post Call to native DLL fails from a .NET Windows service ANd It seems to be the same problem
I tried the other solutions but it didn´t worked So I´ll try the last option, that it will be to to "wrap the dll in a web service that will run on start up and then call through to that web service from the web service."
Can anyone explain me how to do that?

After a lot of tests I realised that problem was in the dll file, so I drop the windows services and implement a winform ( where I know that the dll file works) and use the winform like a service, I now this solution is not the best one but, well is working..

ShowWindow Function Doesn't Work When Target Application Is Run As Administrator

I am writing a program that shows/hides the window of some target application. I was testing it out earlier and noticed something strange. If I run the target application as Administrator (right-click->Properties, "Compatability" tab, "Run this program as administrator") it doesn't work.
To demonstrate I wrote a simple GUI app called "TargetApplication" and then I wrote the following code to test showing/hiding this application:
class Program
{
static void Main(string[] args)
{
IntPtr windowPtr = FindWindow(null, "TargetApplication");
ShowWindow(windowPtr, 0); // 0 = Hide
Console.WriteLine("The window is now hidden. Press Enter to restore");
Console.ReadLine();
ShowWindow(windowPtr, 9); // 9 = Restore
Console.WriteLine("The window is now restored. Press Enter to exit.");
Console.ReadLine();
}
[DllImport("user32.dll", EntryPoint = "FindWindow", SetLastError = true)]
static extern IntPtr FindWindow(string lpClassName, string lpWindowName);
[DllImport("user32.dll")]
static extern bool ShowWindow(IntPtr hWnd, int nCmdShow);
}
If I start the windowed application without Administrator rights it doesn't work.
Would anyone mind testing this for me? I have uploaded the .exe's for both applications here:
TestShowWindow Download
All you have to do is download them and run TestApplication.exe then run TestShowWindow.exe. You will find that by changing TestApplication.exe to run as Administrator causes ShowWindow to no longer work.
Of course if you don't trust downloading my stuff you can always compile my code and test it on any target application in Windows that you are able to change compatability mode of.
P.S. I am not sure if it makes a difference but I am running Windows 8 Pro. 64-bit.

This is by design. It is the lesser known twin of UAC, called UIPI or User Interface Privilege Isolation. An un-elevated program cannot commandeer an elevated one. Given the capabilities of UI Automation, this is an obvious counter-measure to stop programs from hijacking the capabilities of an elevated process. A security violation called a shatter attack.
Workarounds are to provide a manifest with uiAccess = true for a program stored in c:\windows or c:\program files and provided with a certificate. And for the target program to call ChangeWindowMessageFilter to allow certain messages to be sent. In your case that ought to be WM_SHOWWINDOW.

If you don't mind the window acting like you minimized it to the taskbar; You can, generally, show and hide windows from elevated processes by posting WM_SYSCOMMAND with a wParam of SC_RESTORE or SC_MINIMIZE.

C# - Application fullscreen and block Windows native keyboard command

We are currently working on a Fullscreen application in C#.
It is a quiz application which is going to be used in a school to evaluate students.
We presently can put application to a fullscreen state without topbar and border. The thing is the student can still switch between windows and use Windows native commands such as CTRL-ALT-DELETE and CTRL-SHIFT-ESC. Oh and ALT-TAB.
We were wondering if there was a way to block these commands without anti-viruses reporting the app as a threat. Well, first of all if there was a way to simply block the commands. We doupt it is but you guys often come up with some astonishing solutions to nearly unsolvable problems so we thought we might ask anyway.
Thanks for your concern, hopefully someone will come up with something good.
EDIT :
We want to do this so that students can't kill the app with Taskmanager and so that they can't open any other app like an internet browser or chat utility. Maybe there's a more secure way to do things?

You actually can't do this from code in windows xp and windows 7.
Here is a way to do this via the registry: Securing Windows For Use As A Kiosk

Can't you just set the forms TopMost property to TRUE and hide all form controls.
All ctrl-alt-del etc. allows you to do is shut down the process/app. If this what you are trying to avoid then ignore this answer.
The other answer is to use a global keyboard hook:
[DllImport("user32.dll", CharSet = CharSet.Auto, SetLastError = true)]
private static extern IntPtr SetWindowsHookEx(int idHook,
LowLevelKeyboardProc lpfn, IntPtr hMod, uint dwThreadId);
[DllImport("user32.dll", CharSet = CharSet.Auto, SetLastError = true)]
[return: MarshalAs(UnmanagedType.Bool)]
public static extern bool UnhookWindowsHookEx(IntPtr hhk);
[DllImport("user32.dll", CharSet = CharSet.Auto, SetLastError = true)]
private static extern IntPtr CallNextHookEx(IntPtr hhk, int nCode,
IntPtr wParam, IntPtr lParam);

Why not build your app in asp.net to run in the browser and set the computer into "kiosk" mode via group policies? You can run IE in fullscreen that way.