Opened 5 years ago

Last modified 5 years ago

#15063 reopened defect

Incorrect HitTest for ListCtrl when in report view

Reported by: dhyams Owned by:
Priority: normal Milestone:
Component: GUI-generic Version: stable-latest
Keywords: hittest listctrl carbon Cc: dhyams
Blocked By: Blocking:
Patch: no


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

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.

Attachments (1)

listctrl.hittest.patch download (701 bytes) - added by dhyams 5 years ago.
Patch to fix this issue

Download all attachments as: .zip

Change History (8)

Changed 5 years ago by dhyams

Patch to fix this issue

comment:1 Changed 5 years ago by VZ

  • Resolution set to fixed
  • Status changed from new to closed

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

Account for the header height if the header is present.

Closes #15063.

comment:2 Changed 5 years ago by dhyams

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

comment:3 Changed 5 years ago by dhyams

  • Patch unset

comment:4 Changed 5 years ago by vadz

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

comment:5 Changed 5 years ago by VZ

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

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

See #15063.

comment:6 Changed 5 years ago by 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 ;)

comment:7 Changed 5 years ago by vadz

  • Component changed from wxOSX-Carbon to GUI-generic
  • Milestone 2.9.5 deleted

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.

Note: See TracTickets for help on using tickets.