Windows 7 中 I-Beam 光标的热点不正确？

Question

问题

在 Windows 上，对于 I-Beam 光标，“鼠标按钮按下”事件返回的坐标似乎略有错误。基本上，x 坐标始终比应在的位置左两个像素。

我编写了一个非常简单的 win32 程序来演示该问题。它所做的就是将光标变成 IBeam 并在上次鼠标按下事件所在的位置渲染一条垂直红线。我希望红线与工字梁的垂直部分完全匹配，但事实并非如此。

这是所发生情况的屏幕截图。

正如您所看到的，红线距离其应有位置左侧有两个像素（对于标准箭头指针而言，该行为是正确的），因此看来 I-Beam 光标的热点是错误的。

我让其他运行 Windows 7 64 位的人确认他们遇到了同样的问题，但另一位运行 Vista 的测试人员没有遇到这个问题。

---

有关我的环境的一些信息

• Windows 7 64 位。完全默认配置（即没有 DPI 缩放、没有奇怪的主题等）
• Visual Studio Express 2010
• NVidia 显卡以及最新驱动程序 (v270.61)
• 打开或关闭 aero 没有任何区别。在显示首选项中选择不同的光标没有什么区别

---

相关代码

我的测试项目基本上是 Visual C++ 2010 中的“Win32 项目”模板，其更改概述如下。

下面是我注册窗口类并将光标设置为 I Beam 的代码

ATOM MyRegisterClass(HINSTANCE hInstance)
{
    WNDCLASSEX wcex;

    wcex.cbSize = sizeof(WNDCLASSEX);

    wcex.style          = CS_HREDRAW | CS_VREDRAW;
    wcex.lpfnWndProc    = WndProc;
    wcex.cbClsExtra     = 0;
    wcex.cbWndExtra     = 0;
    wcex.hInstance      = hInstance;
    wcex.hIcon          = LoadIcon(hInstance, MAKEINTRESOURCE(IDI_CURSOR_TEST));
    wcex.hCursor        = LoadCursor(NULL, IDC_IBEAM); // this is the only line I changed in this function
    wcex.hbrBackground  = (HBRUSH)(COLOR_WINDOW+1);
    wcex.lpszMenuName   = MAKEINTRESOURCE(IDC_CURSOR_TEST);
    wcex.lpszClassName  = szWindowClass;
    wcex.hIconSm        = LoadIcon(wcex.hInstance, MAKEINTRESOURCE(IDI_SMALL));

    return RegisterClassEx(&wcex);
}

以下是我的主消息循环中的相关部分：

case WM_LBUTTONDOWN:
    // record position of mouse down. 
    // xPos and yPos are just declared as
    // global ints for the purpose of this test
    xPos = GET_X_LPARAM(lParam); 
    yPos = GET_Y_LPARAM(lParam);
    // cause redraw
    InvalidateRect(hWnd, NULL, TRUE);
    UpdateWindow(hWnd);
    break;      

case WM_PAINT:
    // paint vertical red line at position of last click
    hdc = BeginPaint(hWnd, &ps);
    RECT rcClient;
    GetClientRect(hWnd, &rcClient);
    hPen = CreatePen(PS_SOLID, 1, RGB(255, 0, 0));
    SelectObject(hdc, hPen);
    MoveToEx(hdc, xPos, 0, NULL);
    LineTo(hdc, xPos, rcClient.bottom);
    DeleteObject(hPen);
    EndPaint(hWnd, &ps);
    break;

摘要

我已经在谷歌上搜索了大量答案，但可以'找不到任何相关的东西。我处理传入光标坐标的方式是否有问题？

谢谢！

---

编辑：评论中提出富有洞察力的问题后的更多信息

按照评论中@Mark Ransom的指导，我使用了GetIconInfo函数来获取有关I-Beam的更多信息光标。光标的 ICONINFO 结构表明光标热点的 x 坐标位于 x=8。但是，当我转储光标的位图（ICONINFO 结构的 hbmMask 成员，因为它是单色光标）时，垂直条距左侧 10 像素图像的大小，而不是 8 个像素。正如马克指出的那样，这可能是造成视觉差异的原因，但为什么会发生这种情况，我该如何解决呢？

（我还注意到另一个问题的答案 有一些关于 I-Beam 光标处理方式的有趣信息，我想知道这是否相关）。

Answer 1

这个问题困扰了我很多年，显然还有很多其他 Windows 用户？您是否曾经只在两个字符之间单击，但文本插入符号最终距离左侧太远？您的光标显然位于另外两个之间！

如果打开记事本，然后将光标移动到底部边缘，移出文本区域，并观察工字梁和指针之间的变化，您可以看到指针从工字梁左侧两个像素开始。 OP 已经彻底观察到了这一点，甚至编写了一个程序来测试行为不当的 I 型光标点击的位置。肯定是热点设置错误。 （从来没有想过我会成为那些用手机截图的人之一，但在这种情况下，这实际上是我想到的捕获鼠标光标的最简单方法。）

好吧，那么我们该如何修复它呢？
好吧，任何理智的 Windows 用户都会在控制面板中打开鼠标设置，然后非常简单地将 I 形光标更改为具有正确热点的不同版本。我可以发誓我以前已经这样做过，从某个地方下载了校正后的工字形光标（看起来完全一样），但我似乎找不到我所在的链接得到它——但是，是的，这种方法肯定会给你一个正确的文本选择热点。

但它能真正解决问题吗？或者它会让你失眠，想知道 - 知道 - 你掩盖了它......

看起来很难真正解决，无论如何......对吗？我们只需去调整原始光标文件即可。因此，我在控制面板中打开鼠标设置，然后单击浏览...，在Windows/Cursors 中搜索列表，但是...它不在那里？我看了两遍，然后又看了三次——肯定不见了。没有任何类似于我正在使用的东西。

因此，我通过 regedit 查看 Windows 注册表 - 我想我可以在那里找到它的文件路径。通过 Google 查找按键位置非常简单：HKEY_CURRENT_USER/Control Panel/Cursors。但是等等——它也不在那里？！我看到箭头、手形和其他光标，但在任何地方都没有“Ibeam”或“TextSelection”条目！

你们这些聪明人可能会嘲笑我的困惑，因为他们完全知道 Windows 将秘密光标保存在哪里，但唉，我的无知折磨着我。我继续毫无结果地挖掘其他键试图找到它 - 也许文本选择是特殊的并且在相关键下的其他地方有光标信息？

很快我就得出了合理的假设，即 Windows 使用默认的光标文件如果密钥没有设置——但是那会在哪里呢？幸运的是，我有一点 Windows 编程经验，并且知道事物可以来自嵌入式资源而不是独立的 .cur 文件。经过更深入的挖掘，一个名叫赫比的人给了我答案：

它们位于 user32.dll [%WinDir%/system32] 中。

（通过 https://www.neowin.net/forum/ topic/374461-default-xp-cursor-location/)

隧道尽头有光。由于某种原因，我的计算机上已经安装了 Resource Hacker，可能是因为我之前做了一些疯狂的事情，但我查看了 user32.dll 内部，果然找到了默认的光标资源。资源 ID 73 下有工字梁。

我将其导出并使用十六进制编辑器查看，同时引用 ICO 文件格式。字节偏移 10 具有热点的水平像素坐标，即 8。我可以将该字节从 0x08 更改为 0x0A，然后将修改后的文件导入回 user32。 dll与Resource Hacker，我的问题就可以解决（除了权限问题）。

这很简单，但是我们真的想要简单吗？我们已经走了这么远，不妨浪费一天剩下的时间。让我们编写一个 C++ 程序来完成它！当然，作为完全优秀的工程师，我们必须找到一种方法来安全且正确地执行此操作...

从而开始了我进入程序员地狱最深处的旅程，忍受着昔日描述晦涩的 WinAPI 方法的文档，例如那些与更新 DLL 资源有关。这里的第一个大障碍是那个神奇的数字，我们要修改的光标资源的 ID，“73”。这意味着什么？它从哪里来？

嗯，对我来说，很明显它是一个生成的 ID，不能被信任为代表 I 型光标的实际常量。因此，我们需要找到某种方法来可靠地找到那个神奇的数字。纸面上看起来很简单，不是吗？嗯，事实并非如此。

我最接近追踪到的难以捉摸的神奇数字是来自 GetIconInfoEx 的标识模块的字符串“USER32”。没有什么真正有用的东西。 （哦，顺便说一句，对任何想要弄清楚 .cur 文件及其被屠杀的 BMP 格式的人，这是一个公平的警告。）如果您能找到一种方法，将 IDC_IBEAM 转换为 user32 中的键名.dll 资源，向你致敬，但在这个项目的大部分时间里我把头撞到墙上后，我决定采用一种更愚蠢的方法。

我只是复制了原始数据，直接从游标资源中导出来用作签名。然后我可以 LoadLibrary user32.dll，枚举游标，然后检查它们是否与签名文件完全匹配。如果找到匹配项，我就找到了要修改的 ID。我还了解到，我在 Resource Hacker 中看到的第二个神奇数字是语言代码 - “1033”（美国英语）。我还不得不烦人地进行另一次枚举才能找到该数字。

一切都很好，几个小时后，通过深入研究文档，我有了我的解决方案。 Windows API中有一些函数可以更新DLL文件中的资源。我所要做的就是更改签名文件的第一个字节（这是水平热点偏移量），并更新资源。

当然

是经过许可的在这个项目进行到一半的时候，我提醒自己修改系统文件是一个可怕的想法（特别是如果它让系统认为有些东西是错误的/过时的），更不用说系统会采取什么措施来阻止你这样做，但如果没有知道我完成了解决方案的甜蜜满足感，我就无法生活。它确实起作用了——我复制了 user32.dll，运行代码，果然，光标热点得到了纠正。

结果： https://github.com/mukunda-/IBeamFix

系统文件是系统文件，并且即使具有管理员访问权限，系统也不会让您打扰它们。我不会费心去思考如何规避这个问题。

更好的方法可能是简单地（简单地说，我的意思是处理 CUR/BMP 地狱）从 user32.dll 导出光标，检查其特征以确保它仍然存在热点缺陷，修改热点坐标，然后然后更新注册表以使用该光标。

或者，更好的是，甚至不用担心任何这种彻底的疯狂，而只是使用替换光标。我应该在第四段停下来。看，我做了一个。 https://mukunda.com/stuff/IBeamFixed.cur 问题已解决。