Incorrect HitTest for ListCtrl when in report view

[dhyams]

The hit-testing for items in a ListCtrl tend to be 1-off because the header, if present, is not taken into account.

The patch is against wxWidgets 2.9.1.1.

I'm marking this as a OSX/carbon only patch, but it certainly might affect other platforms, as the fix is for the generic listctrl in src/generic/listctrl.cpp.

OSX/carbon is where I noticed the problem and chased it down, and have not had the chance to test on other platforms; don't think it would affect windows, because I don't think the generic listctrl is used under windows. I don't know about OSX/cocoa.

[dhyams]

Patch to fix this issue

[VZ]

(In [73563]) Fix off by 1 error in wxGenericListCtrl::HitTest().

Account for the header height if the header is present.

Closes #15063.

[dhyams]

Please undo this patch as soon as possible...while it does fix my direct-call-to-HitTest issues, it messes up selection in the control.

I'm not sure of the correction solution to this situation quite yet, but this patch isn't it.

[vadz]

I'll revert the patch but it would be useful to know how exactly is the selection broken?

[VZ]

(In [73596]) Revert "Fix off by 1 error in wxGenericListCtrl::HitTest()."

Revert r73563, this breaks the selection in the control apparently.

See #15063.

[dhyams]

At this point I'm confused enough not to be entirely sure. It may not be selection that's messed up; I think that idea erroneously took root during my hacking session to try to figure out what was going on.

I'll confess to being a Python user, using wx.lib.mixins.listmix.TextEditMixin to add editing capability to my list control that is in report mode, and has a header. That mixin also makes use of HitTest, with the mouse position given to it by the incoming EventObject (on a mouse event obviously). There, the Hit testing seems to work fine (without the patch), because the coordinates incoming via the event object seem to be already referenced properly whether or not the listctrl (in report mode) has a header or not. In other words, I printed coordinates there, and clicking extremely close to the header gives a mouse y coordinate of 0. That's what is passed to the listctrl's hittest, so it works fine.

Where I noticed things being off was in my own custom Tooltip implementation, which uses HitTest as well. Here, I'm getting the mouse coordinate with wx.GetMousePosition(), then converting to the list ctrl's coordinates with ScreenToClient(). Here, the y coordinate, if I click very close to the header, is not zero. It's 18 or 19, which is the height of the list ctrl's header. That's what gave rise to the submitted patch.

So anyway, without this patch, my HitTesting is off, but the TextEditMixin's is just fine. With the patch, just the opposite.

I tried using the window obtained with listctrl.GetMainWindow() in the ClientToScreen() call, but that didn't make any difference.

I might be misusing something...if anyone sees the error of my ways, please let me know ;)

[vadz]

The problem must be with something you're doing in your code as HitTest() itself works just fine for me in the sample account, try it with Ctrl-right clicking an item. It would be really nice to have a patch reproducing the problem in the sample as it's still not clear what exactly doesn't work here.