@Sam_Rowlands - Standard API-1 ListBox
In your Lifeboat example, do mouse down events get raised, even if the CellClick event doesn’t?
For me, it’s the
Change event of a regular classic
Listbox that’s not being raised reliably. Clicking additional times makes it work, but for some reason not every
Change event is being raised (and so the view does not always change).
It would be interesting to know which version of Xojo has been used to create the app, as well as the platform.
I have sold thousands of copies of my Windows apps created with 2016R3, which contains several listboxes, including one that is used a lot. Never got any report about clicks not working.
I sold about 1700 copies of the same apps on Mac, currently using 2021R3.1, and no more reports of clicks not working.
There are always idiosyncrasies, in particular under Windows, as the platform hardware and software fragmentation is high. But even on Mac there can be problems with drivers. That is why I suggested issues linked to input devices.
79 was built with 2022r1 and 77 was built with 2021r3.1; built on Mac, only experience the issue on Mac so far; both versions experience the inconsistency.
In the following screenshot I’ve managed to get the “Clear Caches” view visible with “MariaDB / MySQL” selected. The only thing that’s happened is the
Change event hasn’t been raised by the framework.
Perhaps the issue is with the Listbox itself. System.MouseDown would be a possible workaround ?
- I assume the listbox is atop a PagePanel?
- Is the listbox naked or wrapped in a containerControl?
- Can you make a build that will help confirm is the listbox receives a mouseDown event, but not a change event.
- Could this be an update issue? i.e. the Listbox not invalidating the row? If you use the cursor keys after, does it jump to where it should be or select the next/prev highlighted row.
- The hierarchy:
- PagePanel > ContainerControl > [Listbox & PagePanel]
- Maybe, we’ll see if I can find the time
- If you arrow key the Change event will be raised with the correct SelectedRowIndex which corrects the view.
I may not have explained fully, the correct expectation in the screenshot above is that the MariaDB / MySQL view would be showing. The Clear Caches view is the stale one.
Since I updated to MacOS 12.3.1, I’ve encountered problems with listboxes on Apple apps that sound similar to what’s discussed here. I know Xojo’s listboxes and Apple listboxes are different beasts, but I can’t ignore how similar what is described in this thread is with my experience (therefore, if it’s a right assumption, it would have something to do with the 12.3.1 update).
What I’m seeing, e.g. in Apple’s Mail, often: the first click on a mail does nothing. Then, I can click anywhere on the UI and the first click is registered (the mail gets selected, but one step too late). This goes on further, with my clicks always being triggered one step late until I eventually click on the menubar (or a “non-view UI”) and then the clicks get synchronised as they should.
This looks like the same behaviour as Tim’s description:
Gotchya, so it highlights the correct row, but because the change event never fires, it’s still showing the incorrect panel.
Thanks for clarifying it.
It funny you should mention this, because I found with 12.3 that polling the NSEvent stack for future events was failing when the period was 1/60. I had to widen the time frame to 1/30 to actually get the event. It took me days to realize what they’d changed (with of course no documentation to say it).
So yeah, Apple made some changes to events with 12.3… At this point, I think Apple is doing the least possible QA to determine how little QA they can do without it damaging Mac sales. Gotta max that profit.
That’s all on target for macOS, but I’m seeing this on Windows. My hierarchy is:
Window → PagePanel → Listbox
And there are a total of 4 in that same hierarchy with 3 of them working properly (all 4 work on Linux and macOS through 12.3). I even went so far as to copy the events, delete the failing LB, and then create a new version.