WndProc中WM_KEYDOWN事件不触发的原因及替代处理方案问询

• Windows系统的键盘消息默认会发送给当前获得输入焦点的窗口，如果你的窗体上存在编辑框、按钮等可获得焦点的子控件，只要焦点落在子控件上，WM_KEYDOWN消息会直接派发给子控件的消息处理函数，不会流转到父窗体的WndProc中，这是Windows消息机制的原生规则。
• KeyPreview=true是VCL框架提供的事件层面的封装逻辑：VCL内部处理子控件的键盘消息时，会提前检查父窗体的KeyPreview属性，如果为真就先触发窗体的OnKeyDown/OnKeyPress等事件，但这个逻辑不会把原始的WM_KEYDOWN消息转发到窗体的WndProc，因此你在窗体的WndProc中无法捕获到该消息。

方法1：使用VCL自带的ProcessDlgKey虚方法 #

重写窗体的ProcessDlgKey方法即可，VCL的键盘路由逻辑会优先调用该方法，优先级高于子控件的消息处理，完全可以替代WndProc做统一的键盘事件拦截：

bool __fastcall TForm1::ProcessDlgKey(TMessage& Msg)
{
    if (Msg.Msg == WM_KEYDOWN)
    {
        TWMKeyDown KDMsg = reinterpret_cast<TWMKeyDown&>(Msg);
        TShiftState KDSs = KeyDataToShiftState(KDMsg.KeyData); 
        if (KDMsg.CharCode == 'C' && KDSs == TShiftState() << ssCtrl)
        {
            // 处理CTRL+C按键
            return true; // 返回true表示消息已处理，不再向下分发
        }
    }
    return TForm::ProcessDlgKey(Msg);
}

该方案无需修改消息映射，也不需要额外处理子控件的消息转发，是VCL场景下的最优解。

方法2：子控件子类化转发消息 #

如果一定要在窗体的WndProc中处理WM_KEYDOWN，可以给窗体上所有可获得焦点的子控件做子类化，拦截子控件收到的WM_KEYDOWN消息，手动转发给窗体：

// 自定义子控件窗口过程
LRESULT CALLBACK SubControlProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam, UINT_PTR uIdSubclass, DWORD_PTR dwRefData)
{
    if (uMsg == WM_KEYDOWN)
    {
        // 转发到窗体的WndProc
        SendMessage(Form1->Handle, uMsg, wParam, lParam);
    }
    return DefSubclassProc(hWnd, uMsg, wParam, lParam);
}
// 窗体初始化时给需要拦截的控件设置子类化
SetWindowSubclass(Edit1->Handle, SubControlProc, 0, 0);

该方案适合窗体上可控控件数量较少的场景。

方法3：使用OnKeyDown事件统一处理 #

开启KeyPreview=true后，直接将所有键盘处理逻辑放到窗体的OnKeyDown事件中即可，该方案是VCL官方推荐的简化处理方式，逻辑清晰且维护成本低，完全可以满足统一处理的需求。

你当前的WndProc实现中，处理完WM_KEYDOWN后直接return跳过了父类的WndProc调用，如果没有特殊需求不需要这么做，只要标记fMessage.Result=1即可，避免影响VCL内部的其他消息处理逻辑。

内容的提问来源于stack exchange，提问作者Coder12345