Win32 自绘图片按钮：BS_OWNERDRAW、GDI+ 与高 DPI 实战

前段时间被一位朋友拉去看他写的一个小工具界面里有个“开始扫描”的按钮他想把按钮做成带图标的样子结果折腾了一下午按钮上的图要么不显示要么显示出来是一团黑要么点了没反应。他用的就是最朴素的 Win32 API 加 C 语言没有任何界面库。这个问题在 Win32 里其实非常典型——系统根本没有给你一个叫“图片按钮”的现成控件一切都要自己拼出来。这篇就把这套东西从头到尾拆一遍怎么把一张指定图片加载进内存、怎么把它画到一个真正的 BUTTON 控件上、怎么让它在悬停和按下时有反馈、怎么处理高 DPI 下的缩放以及我在这条路上踩过的几个坑。无论你是刚接触 Win32 想练手还是在维护一个十几年前的老界面需要加个图标按钮下面的内容都能直接抄去用。1. Win32 里为什么找不到一个叫“图片按钮”的现成控件刚接触 Win32 的人常有一个误解觉得CreateWindowEx的第一个参数填个BUTTON就应该万事大吉剩下的属性靠样式位堆上去就行。结果翻遍winuser.h里的BS_开头的宏能找到BS_BITMAP、BS_ICON兴冲冲试一把发现图标和文字挤在一起位置还调不动尺寸一改就变形。这不是你姿势不对而是这套控件的设计年代决定的——它出生的时候界面上的按钮就是灰色方块加一行字图片按钮根本不在设计目标里。BS_BITMAP的语义是“按钮表面显示一张位图”它会用位图去替换整个按钮的绘制但按钮的边框、焦点框、按下时的凹陷效果全部不生效你得到的就是一张贴上去的图看起来完全不像按钮。更麻烦的是它只认HBITMAP而且尺寸跟随按钮一旦按钮尺寸和图片尺寸不匹配就直接裁剪。所以真正做图片按钮的人基本都绕开了这个样式位。1.1 三条能做出来的路线以及它们各自的天花板把 Win32 里所有能实现“图片按钮”的路子捋一遍其实就三条它们的能力边界差别很大值得先摆在桌面上对比。路线核心做法优点天花板静态控件伪装STATICSS_BITMAP/SS_ICONSS_NOTIFY处理STN_CLICKED代码最少十几行能跑没有按下态、没有焦点框、键盘不可达、切图要手动STM_SETIMAGE自绘按钮BUTTONBS_OWNERDRAW父窗口处理WM_DRAWITEM键盘、焦点、BN_CLICKED通知全部免费只能画在自己的矩形里超出部分会被裁完全自绘窗口注册自己的窗口类WM_PAINT全权处理想怎么画怎么画圆角、阴影、动画都行键盘导航、无障碍、Tab 顺序全部要自己实现第一条路线最容易被新手选中因为搜出来的示例代码大多是这个。它确实能跑但做出来的东西本质是个“会响应点击的图片”不是按钮。你按 Tab 键跳不到它上面按空格不会触发鼠标按下时它没有任何视觉反馈用户点下去心里是没底的。放在工具类软件里勉强能接受放在稍微正式一点的界面上就显得很粗糙。第三条路线是给做自定义皮肤框架的人准备的代价是你得自己接管WM_KEYDOWN、自己维护焦点链、自己处理WM_TABSTOP的语义还要考虑屏幕阅读器能不能识别。为一个按钮付这个代价不划算。1.2 我最后选了 BS_OWNERDRAW 的三个理由中间那条路是我这些年一直用的。BS_OWNERDRAW的本质是按钮的行为还是系统的按钮的长相归你。系统负责接收鼠标消息、维护按下状态、处理键盘空格、在状态变化时发BN_CLICKED给父窗口你只需要在WM_DRAWITEM里把像素画上去。第一个理由是状态位现成。WM_DRAWITEM送来的DRAWITEMSTRUCT里有个itemState字段按下、获得焦点、被禁用这些状态系统已经帮你算好了你不用自己追踪一堆布尔变量。这一点在后面第 3 章会详细展开它省掉的心智负担比想象中大。第二个理由是和现有布局不冲突。BS_OWNERDRAW的按钮依然是个普通子窗口MoveWindow、SetWindowPos、放在WS_EX_CLIENTEDGE的容器里行为和其他控件完全一致。老项目里做局部改造时这一点很关键——你不需要动外围的布局代码。第三个理由是绘制时机可控。按钮什么时候需要重画由系统通过WM_DRAWITEM通知你你想主动重画一个InvalidateRect就够。悬停高亮这类效果靠的就是这个机制。提示BS_OWNERDRAW只能和BUTTON类一起用。如果你在STATIC上写这个样式它不会报错但什么也不会发生这个坑我见人踩过不止一次。2. 图片进内存BMP、PNG 与“C 语言到底能不能用 GDI”这件事选好了绘制路线下一个问题就是图片怎么进内存。这一步是整个流程里最容易卡住的地方因为答案取决于你的图片是什么格式。标题里写的是“显示指定图片”实际工程里这个“指定”可能是 BMP也可能是带透明通道的 PNG两者的处理方式完全不在一个量级上。2.1 LoadImage 只能搞定 BMPPNG 得换工具LoadImage是 Win32 里最直接的图片加载函数签名里那个fuLoad参数可以填LR_LOADFROMFILE从磁盘读也可以填MAKEINTRESOURCE从资源里读。但它内部走的是OleLoadPicture的老路径实际支持的格式只有 BMP、ICO、CUR 这几种。你给它一个 PNG 文件路径返回值是NULLGetLastError()给你一个ERROR_BAD_FORMAT之类的错误码然后就没了。我见过不少人试图靠改文件扩展名骗过去把logo.png改名成logo.bmp当然不会成功——格式判断看的是文件头不是后缀名。所以只要你的图片是 PNG、JPG、GIF 中的任何一种就必须引入额外的解码器。Win32 平台上能用的就两套GDI 和 WICWindows Imaging Component。2.2 GDI 的类封装是 C所以 .c 要改名 .cppGDI 是最省事的选择。它的解码器覆盖了常见格式接口也简单Image::FromFile一行就能把 PNG 读进来透明通道完整保留。但这里有一个绕不过去的坎GDI 的头文件用 C 类做了封装Gdiplus::Image、Gdiplus::Graphics这些全是类纯 C 编译器根本过不了。所以项目标题里虽然说“C 语言”实际落地时几乎所有人的做法都是把源文件后缀从.c改成.cpp但代码风格依然保持纯 C 的过程式写法——全局静态函数、switch-case的消息循环、不使用任何 STL 和类继承。编译出来的东西和 C 没有任何区别只是借用了 C 的语法来通过头文件检查。这个取舍我认为完全合理。硬要用纯 C 调 GDI 的 C 接口层GdipCreateImageFromFile那一套Gdip*前缀的扁平 API代码会变得非常难读而且官方文档和示例几乎全是 C 风格出问题时很难找到参考。2.3 坚持纯 C 的话WIC 这条路怎么走如果项目有硬性约束必须保持.c后缀那就只能走 WIC。WIC 是一套 COM 接口纯 C 完全可用流程大致是这样CoInitializeEx初始化 COM注意线程模型要和你的窗口线程一致UI 线程用COINIT_APARTMENTTHREADED。CoCreateInstance创建CLSID_WICImagingFactory。CreateDecoderFromFilename拿到解码器GetFrame拿到帧。CreateFormatConverter把帧统一转成GUID_WICPixelFormat32bppBGRA这一步骤解决不同 PNG 的位深差异。CopyPixels把像素数据拷进你自己申请的一块缓冲区。用CreateDIBSection建一个 32 位的 DIB把缓冲区memcpy进去得到一个可以直接BitBlt的HBITMAP。这条路代码量大概是 GDI 方案的三到四倍但它有个额外好处你拿到的是原始像素想做什么处理比如按状态染色、生成灰色禁用态都比 GDI 方便。取舍看你的项目约束如果只是做个演示我建议还是改后缀用 GDI。2.4 图片从文件读还是打进资源两种方式都能用但适用场景不一样。从文件读LR_LOADFROMFILE或Image::FromFile的好处是换图不用重新编译适合图标皮肤这类需要用户自定义的东西。代价是你得处理路径问题相对路径是相对于当前工作目录不是 exe 所在目录。用户从桌面快捷方式启动、或者从别的程序里ShellExecute调用工作目录都可能不是你预期的那个结果就是图片莫名其妙加载失败。稳妥做法是用GetModuleFileName拿到 exe 的完整路径截掉文件名部分再拼上图片的相对路径。打进资源的好处是单文件分发不会出现“少了个 png 就白屏”的尴尬。做法是在.rc文件里写一行IDB_BTN_NORMAL PNG res\\btn_normal.png然后在代码里用FindResourceLoadResourceLockResource拿到内存指针再配合IStreamSHCreateMemStream或CreateStreamOnHGlobal喂给Gdiplus::Image的构造函数。LoadImage走资源那条路只支持 BMPPNG 不行这个限制要知道。我自己的习惯是正式发布的工具用资源开发调试阶段用文件这样可以边改图边看效果不用反复编译。3. 自绘一次按钮WM_DRAWITEM 里的状态位与双缓冲图片加载进来之后真正的工作才开始。WM_DRAWITEM这个通知消息是自绘按钮的全部入口它送来的DRAWITEMSTRUCT结构体里有几样东西你必须吃透否则画出来的东西要么位置不对要么状态不同步。3.1 itemState 那几个位到底代表什么itemState是一个位掩码常用的几个位含义如下位值含义实际用途ODS_SELECTED0x0001按钮处于按下状态切换到按下态贴图ODS_DISABLED0x0004按钮被禁用画灰色版本或降低不透明度ODS_FOCUS0x0010按钮拥有键盘焦点画焦点虚线框ODS_DEFAULT0x0020是默认按钮加一圈高亮边框ODS_NOFOCUSRECT0x0200系统要求不要画焦点框尊重它跳过焦点框绘制这里有个细节值得单独说ODS_SELECTED在两种情况下都会置位一是鼠标左键在按钮范围内按下二是按钮获得焦点时按下空格键。这意味着你的绘制代码不需要区分输入来源键盘和鼠标会自动共用同一套视觉反馈。这是BS_OWNERDRAW相对自绘窗口最大的优势之一。另一个细节是ODS_FOCUS和ODS_NOFOCUSRECT的组合。系统在用户用鼠标点击时会主动置上ODS_NOFOCUSRECT意思是“这次别画焦点框因为用户是用鼠标操作的焦点框会显得很吵”。如果你无视这个位、硬要每次都画界面上就会出现那种点一下冒一个虚线框的廉价感。判断顺序应该是先看ODS_FOCUS再看有没有ODS_NOFOCUSRECT两个条件都满足才画。3.2 为什么必须双缓冲内存DC怎么建直接往DRAWITEMSTRUCT::hDC上画会闪。原因很直白这个 DC 是直接对应屏幕的你的每一次DrawImage、FillRect都会立刻反映到屏幕上用户能看到绘制过程被一帧一帧地刷出来尤其是图片较大的时候那种从上往下“拉窗帘”的效果非常明显。解决办法是经典的双缓冲在内存里建一块和按钮等大的画布所有绘制先在内存画布上完成最后一次性BitBlt到屏幕。这样用户看到的永远是一个完整的、已经画好的结果。建内存画布有两种写法CreateCompatibleBitmap和CreateDIBSection。我强烈推荐后者原因在于像素格式可控。CreateCompatibleBitmap创建出来的位图格式由目标 DC 决定可能是 16 位色可能是 24 位你没法预知而CreateDIBSection可以强制指定 32 位BI_RGB配合 GDI 绘制时抗锯齿效果稳定得多。创建 DIB 的关键参数是biHeight填负数表示这是一个自上而下的位图第一行像素在缓冲区开头。这一点很重要因为 GDI 的坐标系是自上而下的如果你填正数自下而上DrawImage画出来的图会是上下颠倒的。这个坑我在早期项目里踩过当时排查了半天以为是图片本身的问题。3.3 等比缩放与居中留白按钮的尺寸和图片的尺寸几乎不可能刚好一致。直接拉伸会导致图片变形所以正确做法是算出等比缩放系数取宽高两个方向上的较小值缩放后居中放置。int iw (int)pImg-GetWidth(); int ih (int)pImg-GetHeight(); float fx (float)w / (float)iw; float fy (float)h / (float)ih; float fs fx fy ? fx : fy; /* 取小的那个保证不越界 */ int dw (int)(iw * fs); int dh (int)(ih * fs); int dx (w - dw) / 2; int dy (h - dh) / 2; gfx.DrawImage(pImg, Rect(dx, dy, dw, dh));这里fx fy ? fx : fy用三元不用min是因为windows.h里定义了min/max宏和 C 标准库的同名函数打架是 Win32 项目里的老问题绕开最省事。缩放质量靠两个设置保证SetInterpolationMode(InterpolationModeHighQualityBicubic)处理缩放插值SetPixelOffsetMode(PixelOffsetModeHighQuality)处理像素对齐。少了后面这一句缩小后的图片边缘会出现半像素偏移看起来像被轻微模糊了一层。这两个设置是配套的只开一个效果会打折扣。4. 让按钮“活”起来悬停、按下、焦点与出界判定静态的图贴上去了接下来是交互反馈。这块内容看着琐碎但它决定了用户觉得这个按钮是“活的”还是“死的”。4.1 悬停状态GWLP_WNDPROC 子类化 TrackMouseEventBS_OWNERDRAW按钮的默认窗口过程只关心按下和弹起它压根不告诉你鼠标什么时候移进来了。想知道悬停状态只能自己截获按钮的WM_MOUSEMOVE。标准做法是子类化在创建按钮之后用SetWindowLongPtr把按钮的窗口过程换成自己的在里面处理完需要的消息剩下的转发给原来的过程。g_pOldBtnProc (WNDPROC)SetWindowLongPtrW(hButton, GWLP_WNDPROC, (LONG_PTR)BtnSubclassProc);我不建议用SetWindowSubclasscomctl32 那套因为它依赖 comctl32 v6 的 side-by-side 装配如果项目没有配置 manifest运行时会找不到符号。SetWindowLongPtr是老办法但胜在兼容性无死角。拿到 WM_M