Win32：如何自定义绘制编辑控件？

Question

我需要实现 EM_SETCUEBANNER 的功能，其中出现文本提示在编辑控件内：

问题是我无法使用通用控件的版本 6，这是获得 Microsoft 提供的提示横幅实现所需的内容。

我研究过简单地更改编辑控件的文本和字体格式，

Dark Gray Italic Text

但它会抛出 Change 事件（由更高组件库提供的组件包装）我找不到办法避免。

因此，我打算自定义绘制文本，在控件未聚焦且为空时绘制提示横幅文本，否则依赖默认绘制。

编辑控件不能很好地公开自定义绘图机制，例如 ListView、TreeView 和其他人提供。

其他人已经研究过，但似乎这是一项几乎不可能完成的任务：

从目前的情况来看，我会 必须处理以下事项 消息：

• WM_ERASEBKGND、WM_PAINT（出于显而易见的原因）
• WM_SETFOCUS、WM_KILLFOCUS（防止 白色条不再显示—— 如上所述）
• WM_CHAR（处理和更新 控件中的文本）

我还需要找到一种方法 在控件中显示插入符号， 因为我还没有找到一种方法允许 Windows 也可以为我做到这一点 画我提到的白色条。

这会很有趣。 ：翻白眼：

鉴于 Windows 编辑控件从来都不是自定义绘制的：有谁知道如何自定义绘制 Windows 编辑控件吗？

---

注意：我也会接受解决我的问题的答案，而不是回答我的问题。但是任何其他想要自定义绘制编辑控件的人，遇到这个问题时，可能会想要一个答案。

Answer 1

自定义绘制编辑控件基本上是不可能的。有一些特殊情况，您做得很少，可以逃脱惩罚，但您可能会在 Windows 的下一个版本中严重破坏（或者当有人在旧版本上或通过终端服务运行您的应用程序时）。

仅仅接管 WM_PAINT 和 WM_ERASEBKGROUND 还不够好，因为该控件有时也会在其他消息上绘制。

您最好只编写自己的编辑控件。我知道这是一项巨大的工作量，但从长远来看，这比试图破解所有编辑控件的绘图代码要少。

我记得在过去的美好时光，当时每个人都使用子类化按钮控件来添加颜色和图形等。事情是，有一天我坐下来编写了自己的按钮窗口类。与我们在源代码树中子类化和自定义绘制 Windows 按钮相比，它的代码更少。

Answer 2

创建一个您自己的窗口类，它看起来像空的编辑控件，它绘制提示文本并显示插入符号并具有焦点。还创建编辑控件，但将其放置在窗口后面。 （或将其隐藏）

然后当您收到第一个 WM_CHAR 消息（或 WM_KEYDOWN？）时。您将窗口放在编辑控件后面，将焦点放在编辑上，然后传递 WM_CHAR 消息。从那时起，编辑控件将接管。

如果您需要在编辑变空时返回显示提示文本，您可以收听编辑控件中的 EN_CHANGE 通知。但我认为只有当编辑失去焦点并且为空时才返回提示文本就可以了。

Answer 3

子类化 EDIT 控件对我来说效果很好 - 需要在编辑对象属性时向用户显示一些格式信息（某些属性可能是多行）。正如 Adrian 在他的回答中所说，重要的是在您自己的绘图之前调用 EDIT 控件的过程。之后调用它或发出您自己的 BeginPaint/EndPaint （返回 0 或 DefWindowProc）给我带来了一些问题，从根本不显示文本，到仅在调整大小时显示但在编辑后不显示，到留下剩余插入符的屏幕垃圾。这样，无论 EDIT 控件的其他重绘时间如何，我都没有遇到任何问题。

一些设置：

SetWindowSubclass(attributeValuesEdit, &AttributeValueEditProcedure, 0, reinterpret_cast<DWORD_PTR>(this));

// Not only do multiline edit controls fail to display the cue banner text,
// but they also ignore the Edit_SetCueBannerText call, meaning we can't
// just call GetCueBannerText in the subclassed function. So store it as
// a window property instead.
SetProp(attributeValuesEdit, L"CueBannerText", L"<attribute value>");

回调：

LRESULT CALLBACK AttributeValueEditProcedure(
    HWND hwnd,
    UINT message,
    WPARAM wParam,
    LPARAM lParam,
    UINT_PTR subclassId,
    DWORD_PTR data
    )
{

...

case WM_PRINTCLIENT:
case WM_PAINT:
    {
        auto textLength = GetWindowTextLength(hwnd);
        if (textLength == 0 && GetFocus() != hwnd)
        {
            // Get the needed DC with DCX_INTERSECTUPDATE before the EDIT
            // control's WM_PAINT handler calls BeginPaint/EndPaint, which
            // validates the update rect and would otherwise lead to drawing
            // nothing later because the region is empty. Also, grab it from
            // the cache so we don't mess with the EDIT's DC.
            HDC hdc = (message == WM_PRINTCLIENT)
                ? reinterpret_cast<HDC>(wParam)
                : GetDCEx(hwnd, nullptr, DCX_INTERSECTUPDATE|DCX_CACHE|DCX_CLIPCHILDREN | DCX_CLIPSIBLINGS);

            // Call the EDIT control so that the caret is properly handled,
            // no caret litter left on the screen after tabbing away.
            auto result = DefSubclassProc(hwnd, message, wParam, lParam);

            // Get the font and margin so the cue banner text has a
            // consistent appearance and placement with existing text.
            HFONT font = GetWindowFont(hwnd);
            RECT editRect;
            Edit_GetRect(hwnd, OUT &editRect);

            // Ideally we would call Edit_GetCueBannerText, but since that message
            // returns nothing when ES_MULTILINE, use a window property instead.
            auto* cueBannerText = reinterpret_cast<wchar_t*>(GetProp(hwnd, L"CueBannerText"));

            HFONT previousFont = SelectFont(hdc, font);
            SetTextColor(hdc, GetSysColor(COLOR_GRAYTEXT));
            SetBkMode(hdc, TRANSPARENT);
            DrawText(hdc, cueBannerText, int(wcslen(cueBannerText)), &editRect, DT_TOP|DT_LEFT|DT_NOPREFIX|DT_NOCLIP);
            SelectFont(hdc, previousFont);

            ReleaseDC(hwnd, hdc);

            // Return the EDIT's result (could probably safely just return zero here,
            // but seems safer to relay whatever value came from the edit).
            return result;
        }
    }
    break;

如果您只做最低限度的工作（也许只使用英语），那么编写您自己的 EDIT 控件（实际上我已经不止一次地完成了，与内置控件相比，达到了部分完整性）并没有太多工作。基本插入符号支持），但如果您希望在具有可变大小簇的复杂脚本上进行插入符号导航、范围选择、IME 支持、具有复制和粘贴功能的上下文菜单、高对比度模式以及辅助功能（例如文本到语音。因此，与许多其他答案不同，我建议不要仅针对提示横幅文本实现您自己的编辑控件。

Answer 4

对编辑控件进行子类化。通过首先调用原始窗口过程来处理WM_PAINT，然后，如果它是空的并且不在焦点中，则绘制提示文本。将所有其他消息传递给原始窗口过程。

我已经这样做了——它有效。 CodeGuru 人遇到的问题似乎不适用于您的情况。我相信他正在努力在外表上做更多的事情。出于性能考虑，编辑控件似乎正在 WM_PAINT 处理之外进行一些更新（可能是为了性能）。这将使得几乎不可能完全控制外观。但你可以画出cue提示。

Answer 5

而且我还需要找到一种在控件中显示插入符号的方法，
因为我还没有找到一种方法可以让 Windows 为我做到这一点
还画了我提到的白色条。

如果你想自己处理 WM_PAINT 而不将消息转发到你的超类的原始 windowproc，你不应该忘记调用 DefWindowProc。这样插入符号就会被绘制出来。
为了避免出现白条，您应该使用 SetClassLongPtr 删除类画笔。
并以某种方式保持 DC 的剪辑区域来剪辑编辑控件的 ExtTextOut 输出。
白条可能是编辑控件传递给 ExtTextOut 的 OPAQUE 选项的结果。

结论：编写自己的控件。没有痛苦，就没有收获。