I’ve got a problem with selecting ListBox rows (DesktopListBox in case it matters) with mouse clicks and I’m not sure whether it is a Xojo or a macOS issue.
When I click on different rows in a listbox (single selection) the SelectionChanged event doesn’t fire on every click when the frequency of mouse clicks is fairly high. The row clicked on gets highlighted alright but the SelectionChanged event doesn’t fire (and neither does CellPressed, for that matter). I need to click a second time for the selection to register. Only when I wait at least a second between two clicks will the SelectionChanged or CellPressed events fire reliably. If on the other hand I use the cursor keys to switch between rows I can hammer away at the keyboard at any speed and SelectionChanged will fire every time.
Eventually I realized this was due to the longish double click interval I have chosen in the OS-wide System Settings. With the shortest setting (‘hare’ rather than ‘tortoise’) the problem went away. But does that make sense? One shouldn’t need to wait for a possible second click as part of a double click because a double click is comprised of two clicks at the same (or nearly the same) coordinates while I was clicking in different (and not necessarily adjacent) rows. It’s particularly irritating when the highlight suggests the selection has registered when in fact it has not.
Has anyone else noticed this behavior? Is it a peculiarity of macOS in general or just Xojo’s handling of (possible) double clicks?
I noticed this too. It goes as far back as 2022r2. I have a timer re-check the SelectedRowIndex after a short period to be sure I have the final, correct selection. It’s a horrible workaround for something that shouldn’t be a problem.
I’m not sold on this, I use the default speed setting.
You should get eighter a DoublePressed event or SelectionChanged event (or maybe both) but they are split out so you could code towards this:
If the row selection (single click, with allow row selection and/or multiple selection) is changed you’d get a SelectionChanged event.
if it was a double-click e.g. a little pause between each click you should get DoublePressed.
Note that SelectionChanged may behave differently when you have Single or Multple selection allowed on. And changing selectedRowIndex will also trigger the SelectionChanged so don’t use this in a SelectionChanged event for example.
I can’t reproduce it in a simple project, I’ve only ever seen it happen in my actual code bases. For that, and a few other reasons, I did not make a ticket. I wouldn’t suggest making one until you can reproduce it reliably, in a simple project, and with detailed instructions.
I’ve had my workaround in place for quite some time, so the effect can no longer be seen in my Strawberry Software products. It’s easier to see if you tie SelectionChanged to a PagePanel.SelectedPanelIndex. When it doesn’t get raised, the panel doesn’t change views.
The vast majority of my work is web apps and console apps. (at least today!)
Any desktop app work I do is for internal team use; mostly used by myself; and they’re all 5+ year old apps which are very infrequently updated and mostly (entirely?) are still using the old desktop framework.
So I’m probably not the right person to try and report this issue, either.