ImGui中TableGetHoveredRow()函数返回错误行的问题解析

在ImGui项目的最新版本1.90.4 WIP中，开发者发现了一个关于表格行悬停检测的重要问题。当使用TableGetHoveredRow()函数获取当前鼠标悬停的表格行时，在某些特定情况下会返回错误的行索引。

问题现象

这个问题主要出现在以下场景中：

1. 当表格包含冻结行（通常是表头行）
2. 表格内容可滚动
3. 表格使用了列表裁剪器(ListClipper)

具体表现为：当用户将表格滚动到使第一行数据部分或完全被冻结行遮挡时，鼠标悬停在冻结行上却返回了被遮挡行的索引，而不是预期的冻结行索引。

技术分析

问题的根源在于ImGui表格系统的内部实现机制。在TableEndRow()函数中，系统通过比较鼠标Y坐标与行的边界坐标来确定悬停的行。当前实现存在一个逻辑缺陷：当多个行在垂直位置上重叠时（如冻结行与滚动行），最后被提交的行会覆盖之前行的悬停状态。

解决方案

经过分析，开发者提出了一个简单而有效的修复方案：在判断行悬停时，增加一个条件检查table_instance->HoveredRowNext < 0。这样修改后，系统会优先选择第一个被提交的行作为悬停行，而不是最后一个。

这个解决方案基于一个重要前提：在ImGui当前的表格实现中，冻结行总是位于表格顶部，并且总是先于可滚动行被提交。因此，先提交的行应该具有更高的悬停优先级。

影响范围

这个修复主要影响以下使用场景：

1. 使用冻结行功能的表格
2. 需要精确获取鼠标悬停行索引的应用
3. 结合使用ListClipper的大型表格

值得注意的是，这个解决方案暂时不考虑表格底部冻结行的情况，因为ImGui目前不支持这种布局。如果需要实现类似效果，开发者建议使用两个独立的表格实例，通过精确控制它们的位置来实现视觉上的无缝衔接。

最佳实践

对于开发者来说，在使用表格的悬停功能时，应该注意以下几点：

1. 明确表格的冻结行设置
2. 对于大型表格，合理使用ListClipper优化性能
3. 如果需要底部"冻结行"效果，考虑使用多个表格实例的方案

这个问题及其解决方案展示了ImGui表格系统内部工作机制的一个有趣方面，也提醒我们在使用看似简单的UI功能时，需要注意其背后的实现细节。