How can I add Black theme to MFC dialogue based application? [duplicate] - mfc

Starting with October 2018 Update (version 1809) Win10 has support for Dark theme in Windows Explorer.
It can be configured here:
UI: Desktop | Context Menu | Personalize | Colors | Choose your default app mode = Dark
Registry : HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Themes\Personalize\AppsUseLightTheme = DWORD:0
While this setting exists for a while now, it only affected UWP applications. However, with this Windows 10 release, it also affects Windows Explorer, which is a Desktop application. This means that Windows now have internal support for it. Still, Desktop applications other then Windows Explorer are not affected at the moment.
I'd like to use it in my application. How is it implemented under the hood? Is there some way (manifest, WINAPI, etc) to subscribe for new dark theme?
Update 1:
I noticed that Windows Explorer Control Panel is partially light and partially dark, so it should be a per-window setting, rather then per-process setting.
One other example: Open File dialogs become dark in all Desktop applications, while the application itself remains in old light theme.
Update 2:
I tried SetWindowTheme(hwnd, L"Explorer", NULL); for TreeView and ListView. This visibly changes TreeView style (+ expand button becomes V), but the window remains white.

See https://github.com/ysc3839/win32-darkmode
This guy has it all laid out in some nice reusable code (MIT license).
It seems that Dark Mode is still an area of development in Windows 10, but I believe that Microsoft will eventually properly document and expose it to desktop apps.
Until then, we are stuck with undocumented ordinal-only imports, then custom draw and WM_CTLCOLOR* messages to dictate how controls that don't yet have native Dark Mode support are painted.
The most fundamental of the new Windows APIs are SetPreferredAppMode (uxtheme#135), to be called prior to any window creation, and AllowDarkModeForWindow (uxtheme#133), to be called on any Window that intends to use native Windows 10 dark mode support.
Here is the full list ordinal-only imports from that project:
using fnRtlGetNtVersionNumbers = void (WINAPI *)(LPDWORD major, LPDWORD minor, LPDWORD build);
// 1809 17763
using fnShouldAppsUseDarkMode = bool (WINAPI *)(); // ordinal 132
using fnAllowDarkModeForWindow = bool (WINAPI *)(HWND hWnd, bool allow); // ordinal 133
using fnAllowDarkModeForApp = bool (WINAPI *)(bool allow); // ordinal 135, removed since 18334
using fnFlushMenuThemes = void (WINAPI *)(); // ordinal 136
using fnRefreshImmersiveColorPolicyState = void (WINAPI *)(); // ordinal 104
using fnIsDarkModeAllowedForWindow = bool (WINAPI *)(HWND hWnd); // ordinal 137
using fnGetIsImmersiveColorUsingHighContrast = bool (WINAPI *)(IMMERSIVE_HC_CACHE_MODE mode); // ordinal 106
using fnOpenNcThemeData = HTHEME(WINAPI *)(HWND hWnd, LPCWSTR pszClassList); // ordinal 49
// Insider 18290
using fnShouldSystemUseDarkMode = bool (WINAPI *)(); // ordinal 138
// Insider 18334
using fnSetPreferredAppMode = PreferredAppMode (WINAPI *)(PreferredAppMode appMode); // ordinal 135, since 18334
using fnIsDarkModeAllowedForApp = bool (WINAPI *)(); // ordinal 139
InitDarkMode imports and initializes dark mode, in a safe manner, carefully checking for min and max supported Windows 10 builds:
void InitDarkMode()
{
fnRtlGetNtVersionNumbers RtlGetNtVersionNumbers = reinterpret_cast<fnRtlGetNtVersionNumbers>(GetProcAddress(GetModuleHandleW(L"ntdll.dll"), "RtlGetNtVersionNumbers"));
if (RtlGetNtVersionNumbers)
{
DWORD major, minor;
RtlGetNtVersionNumbers(&major, &minor, &g_buildNumber);
g_buildNumber &= ~0xF0000000;
if (major == 10 && minor == 0 && 17763 <= g_buildNumber && g_buildNumber <= 18363) // Windows 10 1809 10.0.17763 - 1909 10.0.18363
{
HMODULE hUxtheme = LoadLibraryExW(L"uxtheme.dll", nullptr, LOAD_LIBRARY_SEARCH_SYSTEM32);
if (hUxtheme)
{
_OpenNcThemeData = reinterpret_cast<fnOpenNcThemeData>(GetProcAddress(hUxtheme, MAKEINTRESOURCEA(49)));
_RefreshImmersiveColorPolicyState = reinterpret_cast<fnRefreshImmersiveColorPolicyState>(GetProcAddress(hUxtheme, MAKEINTRESOURCEA(104)));
_GetIsImmersiveColorUsingHighContrast = reinterpret_cast<fnGetIsImmersiveColorUsingHighContrast>(GetProcAddress(hUxtheme, MAKEINTRESOURCEA(106)));
_ShouldAppsUseDarkMode = reinterpret_cast<fnShouldAppsUseDarkMode>(GetProcAddress(hUxtheme, MAKEINTRESOURCEA(132)));
_AllowDarkModeForWindow = reinterpret_cast<fnAllowDarkModeForWindow>(GetProcAddress(hUxtheme, MAKEINTRESOURCEA(133)));
auto ord135 = GetProcAddress(hUxtheme, MAKEINTRESOURCEA(135));
if (g_buildNumber < 18334)
_AllowDarkModeForApp = reinterpret_cast<fnAllowDarkModeForApp>(ord135);
else
_SetPreferredAppMode = reinterpret_cast<fnSetPreferredAppMode>(ord135);
//_FlushMenuThemes = reinterpret_cast<fnFlushMenuThemes>(GetProcAddress(hUxtheme, MAKEINTRESOURCEA(136)));
_IsDarkModeAllowedForWindow = reinterpret_cast<fnIsDarkModeAllowedForWindow>(GetProcAddress(hUxtheme, MAKEINTRESOURCEA(137)));
if (_OpenNcThemeData &&
_RefreshImmersiveColorPolicyState &&
_ShouldAppsUseDarkMode &&
_AllowDarkModeForWindow &&
(_AllowDarkModeForApp || _SetPreferredAppMode) &&
//_FlushMenuThemes &&
_IsDarkModeAllowedForWindow)
{
g_darkModeSupported = true;
AllowDarkModeForApp(true);
_RefreshImmersiveColorPolicyState();
g_darkModeEnabled = _ShouldAppsUseDarkMode() && !IsHighContrast();
FixDarkScrollBar();
}
}
}
}
}
Elsewhere, he takes advantage of WM_CTLCOLOR* messages and custom draw notifications to paint dark where Windows doesn't (yet) do it for us.
Note the FixDarkScrollBar. That is an IAT hook on OpenNcThemeData to over-ride the scrollbar theme selection by the listview class in comctl32. That is the part that bothers me most and I'm looking to axe it. I'm sure he is too.
I've adapted this code to my own application and it works well. I am, however, uncomfortable using these undocumented ordinal-only APIs (even as safely as possible), and fully expect Microsoft to eventually announce and document dark mode for Win32 apps and make this work redundant.

After some digging, I was able to find these two approaches. Both are undocumented and may change without notice.
1
SetWindowTheme(hwnd, L"DarkMode_Explorer", NULL);
2
using TYPE_AllowDarkModeForWindow = bool (WINAPI *)(HWND a_HWND, bool a_Allow);
static const TYPE_AllowDarkModeForWindow AllowDarkModeForWindow = (TYPE_AllowDarkModeForWindow)GetProcAddress(hUxtheme, MAKEINTRESOURCEA(133));
AllowDarkModeForWindow(a_HWND, true);
SetWindowTheme(hwnd, L"Explorer", NULL);
WARNING: Ordinal 133 may have completely different API behind it on other versions of Windows, including newer/older Win10 builds.
Both approaches apply some effects, but not everything.
For example, TreeView gets dark scrollbars and dark background for selected item, but the rest of background stays default.
Unfortunately, so far it's not like "call a function and that's it". It seems that even with correct theme applied, some background colors need to be handled manually.

Related

Window with SysMonthCal32 class doesn't respond to WM_SETFONT

I'm not sure what am I doing wrong. I have a functionality in my CDialog-based MFC app to increase the font in some common controls. It is done by sending them WM_SETFONT message with a larger font:
//No error checks for brevity
HFONT hFnt = (HFONT)::SendMessage(hCtrlWnd, WM_GETFONT, 0, 0);
LOGFONT lfFont;
::GetObject(hFnt, sizeof(lfFont), &lfFont);
BOOL bPositive = lfFont.lfHeight >= 0;
long nFontSz = abs(lfFont.lfHeight);
nFontSz += nFontDelta;
lfFont.lfHeight = bPositive ? nFontSz : -nFontSz;
HFONT hNewFont = ::CreateFontIndirect(&lfFont);
::SendMessage(hCtrlWnd, WM_SETFONT, (WPARAM)hNewFont, TRUE);
//Need to DeleteObject hNewFont when control gets a new font or is destroyed
This works for most controls except the DateTime picker (or to be more precise, its month-calendar, SysMonthCal32 window class.)
Here's a screenshot on Windows XP, where it works as expected:
Normal magnification:
Enlarged:
But here's what I get on Windows 10, normal magnification:
And (supposed to be) enlarged, but isn't:
So why is it working on XP and stops, starting from Vista onward?
You are probably using ComCtl32.dll version 6 which uses the Visual Styles API.
This means that most text is drawn by either DrawThemeText or DrawThemeTextEx.
Both of these functions use the font specified by the HTHEME argument.
To change the font you could either change the window's theme using SetWindowTheme or use a version of ComCtl32.dll prior to version 6.
The handling of WM_SETFONT and WM_GETFONT seems to be for keeping compatibility with programs that use these messages to store their font. They are not actually used for drawing.

Name of process for active window in Windows 8/10

The following sample has reliably returned the name of the process that is associated with the active window, but does not work with the newer modern/universal apps because it returns the name of a helper process WWAHost.exe on Windows 8 and ApplicationFrameHost.exe on Windows 10 rather than the name of the app.
HWND active_window = GetForegroundWindow();
GetWindowThreadProcessId(active_window, &active_process_id);
HANDLE active_process = OpenProcess(PROCESS_QUERY_INFORMATION | PROCESS_VM_READ, FALSE, active_process_id);
GetProcessImageFileName(active_process, image_name, 512);
With Windows 10 the ApplicationFrameHost.exe is the process that creates the window handles and is what gets returned by GetWindowThreadProcessId(), is there another Win32 API that can be used to get the active process of universal app that is active?
Also tried using GetApplicationUserModelId() and GetPackageFullName() with no success as they return APPMODEL_ERROR_NO_APPLICATION and APPMODEL_ERROR_NO_PACKAGE respectively because the active_process handle is just the helper process and not the process of the active application.
Any other APIs to use to get the process name of a Modern/Universal application given the hwnd of the window, or otherwise figure out the process name of the universal app is active.
Thanks in advance!
Be sure to use the Spy++ utility when you want to reverse-engineer something like this. Included with Visual Studio, you need the 64-bit version in Common7\Tools\spyxx_amd64.exe. Use Search > Find Window and drag the bullseye to a UWP app, like Weather.
You'll see the window you'll find with GetForegroundWindow(), it has at least 3 child windows:
ApplicationFrameTitleBarWindow
ApplicationFrameInputSinkWindow
Windows.Core.UI.CoreWindow, that's the host window for the UWP app and the one you are interested in. Right-click it and select Properties, Process tab, click the Process ID. That takes you to the real owner process you want to know.
So you just need to make an extra step from the code you already have, you just have to enumerate the child windows and look for one with a different owner process. Some C code, trying to make it as universal as possible without making too many assumptions and not enough error checking:
#include <stdio.h>
#include <Windows.h>
typedef struct {
DWORD ownerpid;
DWORD childpid;
} windowinfo;
BOOL CALLBACK EnumChildWindowsCallback(HWND hWnd, LPARAM lp) {
windowinfo* info = (windowinfo*)lp;
DWORD pid = 0;
GetWindowThreadProcessId(hWnd, &pid);
if (pid != info->ownerpid) info->childpid = pid;
return TRUE;
}
int main()
{
Sleep(2000);
HWND active_window = GetForegroundWindow();
windowinfo info = { 0 };
GetWindowThreadProcessId(active_window, &info.ownerpid);
info.childpid = info.ownerpid;
EnumChildWindows(active_window, EnumChildWindowsCallback, (LPARAM)&info);
HANDLE active_process = OpenProcess(PROCESS_QUERY_INFORMATION, FALSE, info.childpid);
WCHAR image_name[MAX_PATH] = { 0 };
DWORD bufsize = MAX_PATH;
QueryFullProcessImageName(active_process, 0, image_name, &bufsize);
wprintf(L"%s\n", image_name);
CloseHandle(active_process);
return 0;
}
Output on the Weather program:
C:\Program Files\WindowsApps\Microsoft.BingWeather_4.5.168.0_x86__8wekyb3d8bbwe\
Microsoft.Msn.Weather.exe
Here is a small console app application that continuously (so you can test it easily selecting different windows on your desktop) display information about the current foreground window process and store process, if any.
Apps can have a window hierarchy that can span multiple processes. What I do here is search the first sub window that has the 'Windows.UI.Core.CoreWindow' class name.
This app uses the UIAutomation API (and also smart pointers, smart BSTRs and smart VARIANTs provided by the #import directive). I suppose you can do the same with standard Windows SDK, but I find the UIAutomation used this way quite elegant.
#include "stdafx.h"
#import "UIAutomationCore.dll"
using namespace UIAutomationClient;
int main()
{
// initialize COM, needed for UIA
CoInitialize(NULL);
// initialize main UIA class
IUIAutomationPtr pUIA(__uuidof(CUIAutomation));
do
{
// get the Automation element for the foreground window
IUIAutomationElementPtr foregroundWindow = pUIA->ElementFromHandle(GetForegroundWindow());
wprintf(L"pid:%i\n", foregroundWindow->CurrentProcessId);
// prepare a [class name = 'Windows.UI.Core.CoreWindow'] condition
_variant_t prop = L"Windows.UI.Core.CoreWindow";
IUIAutomationConditionPtr condition = pUIA->CreatePropertyCondition(UIA_ClassNamePropertyId, prop);
// get the first element (window hopefully) that satisfies this condition
IUIAutomationElementPtr coreWindow = foregroundWindow->FindFirst(TreeScope::TreeScope_Children, condition);
if (coreWindow)
{
// get the process id property for that window
wprintf(L"store pid:%i\n", coreWindow->CurrentProcessId);
}
Sleep(1000);
} while (TRUE);
cleanup:
CoUninitialize();
return 0;
}
Does taking snapshot of running processes and pulling the name out of it by comparing process id not work?
Full reference here:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms686837(v=vs.85).aspx
But you fix the snapshot with CreateToolhelp32Snapshot().
Or from WTSEnumerateProcesses() and surrounding API?
Pretty sure it worked in Win 8. Is it broken in 10?
Starting from Win10 Anniversary Update ApplicationFrameHost child window return anything but UWP application. It worked only in Tablet mode after relogon.

C++ Windows System Tray wont display message

I have been stuck here for 4 days. I made a function that puts a program in the system tray but the problem here is that it wont show balloon title and message. What Am I doing Wrong? I even made a separate function to determine what windows os we are running on and initialize cbSize based on the Os detected. Any help will be appreciated. Bellow is the function.
EDIT: I am using Windows 7 and the Icon shows up in the system tray but wont show the message or title. I am also doing this Console Application right now as this will be used as a plugin in Unity3D. I want a solution that uses windows api but not windows form as I don't want any new window to open from this.
void createSystemTray()
{
HWND wHandler = GetDesktopWindow();
NOTIFYICONDATA iData;
ZeroMemory(&iData,sizeof(iData));
if(getOsVersion()=="Windows Vista" || getOsVersion()=="Windows 7" || getOsVersion()=="Windows 8" || getOsVersion()=="Windows 8.1")
{
iData.cbSize = sizeof(NOTIFYICONDATA);
}
else if (getOsVersion()=="Windows XP"||getOsVersion()=="Windows XP Professional x64 Edition")
{
iData.cbSize = NOTIFYICONDATA_V3_SIZE;
}
else if (getOsVersion()=="Windows 2000")
{
iData.cbSize = NOTIFYICONDATA_V2_SIZE;
}
else if (getOsVersion()=="UNKNOWN OS")
{
//Assume we have old Windows Os such as Me,95....
iData.cbSize = NOTIFYICONDATA_V1_SIZE;
}
iData.hWnd = wHandler;
iData.uID = 100;
iData.uVersion = NOTIFYICON_VERSION_4;
iData.uCallbackMessage = WM_MESSAGE;
iData.hIcon = LoadIcon(NULL,(LPCTSTR)IDI_WARNING);
lstrcpy(iData.szTip,"My First Tray Icon");
lstrcpy(iData.szInfo,"My App Info");
lstrcpy(iData.szInfoTitle,"My Info Title");
iData.uFlags = NIF_MESSAGE|NIF_ICON|NIF_TIP;
Shell_NotifyIcon(NIM_SETVERSION,&iData); //called only when usingNIM_ADD
Shell_NotifyIcon(NIM_ADD,&iData);
}
I added NIF_INFO to the uFlags and the problem is gone. Now it displays everything including text, title and info title.
The code below is what solved it.
iData.uFlags = NIF_MESSAGE|NIF_ICON|NIF_TIP|NIF_SHOWTIP|NIF_INFO;
Your biggest problem with the code in the question is that you pass the wrong window handle. You have to pass one of your window handles. But instead you pass the window handle of the desktop.
You will need to create a window and use its handle. The window does not need to be visible. I believe that you can use a message only window.
You must also call NIM_SETVERSION after NIM_ADD.
I'm very sceptical of your version switching being based on string equality testing. Your code will break on Windows 9 for instance. Use the version helper functions.
You also perform no error checking. This isn't the easiest function to call but your failure to check for errors makes things even harder than they need to be. Please read the documentation and add error checking code.

Setting Icon of Windows Issues (WinXP and Win7)

I'm making a Firefox addon with js-ctypes and was using user32.dll functions to set the icons of all windows of a profile.
I plan to do this for Mac OS and Linux but trying to knock out Windows first.
So I'm setting the icons like this: GitHub - Gist :: Noitidart / _ff-addon-snippet-ChangeWindowIcon.js - Rev2
That code is simplified. This code I use to apply to all windows:
Cu.import('resource://gre/modules/ctypes.jsm');
var user32 = ctypes.open('user32.dll');
var SendMessage = user32.declare('SendMessageW', ctypes.winapi_abi, ctypes.uintptr_t,
ctypes.int32_t,
ctypes.unsigned_int,
ctypes.int32_t,
ctypes.voidptr_t
);
var LoadImage = user32.declare('LoadImageA', ctypes.winapi_abi, ctypes.voidptr_t,
ctypes.int,
ctypes.char.ptr,
ctypes.unsigned_int,
ctypes.int,
ctypes.int,
ctypes.unsigned_int
);
var IMAGE_BITMAP = 0;
var IMAGE_ICON = 1;
var LR_LOADFROMFILE = 16;
// RUNNING STUFF BELOW - ABVOE WAS JUST DEFINING STUFF
var DOMWindows = Services.wm.getEnumerator(null);
while (DOMWindows.hasMoreElements()) {
var aDOMWindow = DOMWindows.getNext();
var basewindow = aDOMWindow.QueryInterface(Ci.nsIInterfaceRequestor)
.getInterface(Ci.nsIWebNavigation)
.QueryInterface(Ci.nsIDocShellTreeItem)
.treeOwner
.QueryInterface(Ci.nsIInterfaceRequestor)
.nsIBaseWindow;
var nativeHandle = basewindow.nativeHandle;
var targetWindow_handle = parseInt(nativeHandle);
var hIconBig = LoadImage(targetWindow_handle, 'C:\\Documents and Settings\\SONY VAIO\\My Documents\\Downloads\\puzzle.ico', IMAGE_ICON, 256, 256, LR_LOADFROMFILE); //MUST BE A FILEPATH TO A ICO!!!
var hIconSmall = LoadImage(targetWindow_handle, 'C:\\Documents and Settings\\SONY VAIO\\My Documents\\Downloads\\puzzle.ico', IMAGE_ICON, 16, 16, LR_LOADFROMFILE); //MUST BE A FILEPATH TO A ICO!!!
var successSmall = SendMessage(targetWindow_handle, 0x0080 /** WM_SETICON **/ , 0 /** ICON_SMALL **/ , hIconSmall); //if it was success it will return 0? im not sure. on first time running it, and it was succesful it returns 0 for some reason
var successBig = SendMessage(targetWindow_handle, 0x0080 /** WM_SETICON **/ , 1 /** ICON_BIG **/ , hIconBig); //if it was success it will return 0? im not sure. on first time running it, and it was succesful it returns 0 for some reason
}
user32.close();
The issues are as follows:
Issues On WinXP
When press Alt + Tab the icon is the normal one
If windows are lumped into one group (because of taskbar overflow) and ALL icons are changed, the lumped group icon is still not the changed one. As seen in image here:
Issues On Win7
If the application IS PINNED and even if all windows icons are changed to be the same, it still does not changed the pin icon
If the application is NOT PINNED then if change the icon for all windows it will change the icon on the taskbar HOWEVER if you right click on the icon in the taskbar it reverts to what it was normally and running the snippet above again won't set it back, to get it back to icon you set you have to pin and unpin
You really shouldn't put so much questions into a single question...
When press Alt + Tab the icon is the normal one
You're trying to load and set 256x256 icons. XP does not support such icons. You should really add some error checking ;)
IIRC you should set 32x32 icons for the big one. Or more precisely SM_CXICON and/or SM_CXSMICON
If windows are lumped into one group (because of taskbar overflow) and ALL icons are changed, the lumped group icon is still not the changed one. As seen in image here:
I think you're out of luck for this one. XP will take whatever icon is the main resource icon in the .exe IIRC.
XP is dead anyway...
Issues On Win 7
IIRC you'll have to work with System.AppUserModel.RelaunchIcon...
Edit
Actually I might be wrong regarding the XP grouping stuff. Last messed around with icons on win32 quite a while ago. GCLP_HICON/GCLP_HICONSM might work.

Disable CONTROL + ALT + DELETE and Windows(win) Key in Windows 7 using Win32 application [duplicate]

This question already has answers here:
Disable Ctrl+Alt+Del on Windows 7
(3 answers)
Closed 5 years ago.
I am writing an application which runs like a kiosk and should allow user to go out of the application. In Windows 7 , when he presses the Win key or CTRL + ALT+ DELETE , it comes out of program. I need to disable the Ctrl+ ALT + DELETE combination key and Win key in Windows 7 programmatically.
Pressing Alt+Tab will switch out of the application, also. Ctrl+Esc is an alternate shortcut for opening the Start menu. Alt+Esc flips between running applications. There a number of different key sequences that can do this; a natural consequence of Windows being a multitasking operating system.
To work around this, you're going to have to install a low-level keyboard hook that can trap these task keys. The hook will watch for any of the common key sequences used to switch tasks. Whenever it detects one of those sequences, it will ignore the input by not passing it down the hook chain. Paul DiLascia wrote an article that addresses this very question in the September 2002 edition of MSDN Magazine. The part you care about starts about halfway down the page, but I've reprinted it here for convenience and to get the pleasures of syntax highlighting:
TaskKeyHook.h:
////////////////////////////////////////////////////////////////
// MSDN Magazine — September 2002
// If this code works, it was written by Paul DiLascia.
// If not, I don't know who wrote it.
// Compiles with Visual Studio 6.0 and Visual Studio .NET on Windows XP.
//
#define DLLIMPORT __declspec(dllimport)
DLLIMPORT BOOL DisableTaskKeys(BOOL bEnable, BOOL bBeep);
DLLIMPORT BOOL AreTaskKeysDisabled();
TaskKeyHook.cpp
////////////////////////////////////////////////////////////////
// MSDN Magazine — September 2002
// If this code works, it was written by Paul DiLascia.
// If not, I don't know who wrote it.
// Compiles with Visual Studio 6.0 and Visual Studio .NET on Windows XP.
//
// This file implements the low-level keyboard hook that traps the task
// keys.
//
#define _WIN32_WINNT 0x0500 // for KBDLLHOOKSTRUCT
#include <afxwin.h> // MFC core and standard components
#define DLLEXPORT __declspec(dllexport)
//////////////////
// App (DLL) object
//
class CTaskKeyHookDll : public CWinApp {
public:
CTaskKeyHookDll() { }
~CTaskKeyHookDll() { }
} MyDll;
////////////////
// The section is SHARED among all instances of this DLL.
// A low-level keyboard hook is always a system-wide hook.
//
#pragma data_seg (".mydata")
HHOOK g_hHookKbdLL = NULL; // hook handle
BOOL g_bBeep = FALSE; // beep on illegal key
#pragma data_seg ()
#pragma comment(linker, "/SECTION:.mydata,RWS") // tell linker: make it
// shared
/////////////////
// Low-level keyboard hook:
// Trap task-switching keys by returning without passing along.
//
LRESULT CALLBACK MyTaskKeyHookLL(int nCode, WPARAM wp, LPARAM lp)
{
KBDLLHOOKSTRUCT *pkh = (KBDLLHOOKSTRUCT *) lp;
if (nCode==HC_ACTION) {
BOOL bCtrlKeyDown =
GetAsyncKeyState(VK_CONTROL)>>((sizeof(SHORT) * 8) - 1);
if ((pkh->vkCode==VK_ESCAPE && bCtrlKeyDown) || // Ctrl+Esc
// Alt+TAB
(pkh->vkCode==VK_TAB && pkh->flags & LLKHF_ALTDOWN) ||
// Alt+Esc
(pkh->vkCode==VK_ESCAPE && pkh->flags & LLKHF_ALTDOWN)||
(pkh->vkCode==VK_LWIN || pkh->vkCode==VK_RWIN)) { // Start Menu
if (g_bBeep && (wp==WM_SYSKEYDOWN||wp==WM_KEYDOWN))
MessageBeep(0); // only beep on downstroke if requested
return 1; // gobble it: go directly to jail, do not pass go
}
}
return CallNextHookEx(g_hHookKbdLL, nCode, wp, lp);
}
//////////////////
// Are task keys disabled—ie, is hook installed?
// Note: This assumes there's no other hook that does the same thing!
//
DLLEXPORT BOOL AreTaskKeysDisabled()
{
return g_hHookKbdLL != NULL;
}
//////////////////
// Disable task keys: install low-level kbd hook.
// Return whether currently disabled or not.
//
DLLEXPORT BOOL DisableTaskKeys(BOOL bDisable, BOOL bBeep)
{
if (bDisable) {
if (!g_hHookKbdLL) {
g_hHookKbdLL = SetWindowsHookEx(WH_KEYBOARD_LL,
MyTaskKeyHookLL, MyDll.m_hInstance, 0);
}
} else if (g_hHookKbdLL != NULL) {
UnhookWindowsHookEx(g_hHookKbdLL);
g_hHookKbdLL = NULL;
}
g_bBeep = bBeep;
return AreTaskKeysDisabled();
}
He also provides sample code to disable the taskbar (thus preventing the Windows key from showing the Start menu) and a complete sample application that uses these libraries.
As far as preventing Ctrl+Alt+Del (the secure attention sequence, or SAS), the above approach is not going to work. The reason is that the OS traps the hardware interrupt generated by the SAS separately from other keys, specifically to prevent programs from hooking the sequence and spoofing a login prompt. You aren't going to be able to disable this feature with a keyboard hook. The article I linked to above does cover this requirement in great detail at the top portion, but those strategies are only tested and more than likely will only work on Windows XP. Another approach suggested by the article is to disable the Task Manager, but note that that won't stop the user from shutting down the system, etc. The right way to do this is to write a keyboard driver.
AFAIK, you can't catch the CTRL + ALT + DELETE key combo in win32. There are ways to circumvent the problem if you are willing though.
I think this would be possible by replacing main Windows keyboard driver, kbdclass.sys. It should be possible inside it to handle the Delete key pressing and, for example, avoid transfering it further when the Ctrl and Alt keys are already down.