The Problem with Listbox.CellBackgroundPaint

This is for an X-Platform (Mac/Windows) desktop app.

Maybe there is a way around this in newer versions, but at least in 2019.r1.1 (which I have to stay on for backwards compatibility in this project) the only robust workaround I can see is handling ALL the cell drawing in the CellBackgroundPaint event and not use CellTextPaint at all…

Yes that can be done… I did it in my MergableCell Listbox subclass BUT you need to know the Mac ListboxRow highlight color if if you want to match it to other Xojo Listboxes and to make it general and be aware of ALL possible listbox features that can affect how things are drawn - which is not trivial.

When I wrote my subclass (over 10 years ago!) I did all that…

The reason for this is to draw something that is partially outside the text area (for this app a small icon in the upper lefthand corner of the cell when the data meets certain conditions).

I can’t just use CellAllignmentOffset because the alignment looks odd when there is no icon and screen real-estate is tight for some of the machines this needs to run on, so making the cells larger is not an option and I don’t want to make the font size smaller.

If you draw it CellBackground paint and return false, on a Mac the highlight obliterates what you draw as it draws the highlight after the event, and the Clipped graphic context you get in CelltextPaint does not allow you to draw to the edge of the cell.

That is true even if the listbox is not hierarchical, doesn’t have a row picture or a checkbox. (IIRC in that case the border is 3 pixels - well these days probably points)

OK you say so draw the highlight yourself and then your icon and return true…

But you have to know what that highlight color is … that is where the robustness part comes in IMO…

Xojo does not provide a framework method to get that color for a Mac AFAIK… So one has to rely on declares… which can morph with OS version so it would-be best if the Xojo framework provides it. That way I would only need to compile with the right Xojo version for the target machine if Apple changes the “correct” API…

MANY years ago I put in a feature request to provide that color by my ether having a listbox.HighlightColor method , or setting g.forecolor to the background color for the graphics context passed into CellBackgroundPaint, or just painting the highlight before the event (IIRC that is what happens on Windows)… But it never happened.

So is there a backwards compatible (to 2017r1.1) way to do this without declares that I have missed over all these years?

Thanks for listening to my rant! :wink:

Off the wall idea… (untried)
Can you have a listbox with one row, set it to selected, use .drawinto and then examine the color?
I can envisage a lot of reasons why this wouldnt work, but…

Years ago I did stuff like hat but eventually decided not to rely on such kludges.

Apparent you can get the color in newer version of Xojo using color groups IF you know the name of teh color and the fact that you cam get it that way.

I never understood why the never just set g.forecolor to teh correct background color for the graphics object (or whatever the API 2 name is now) passed into CellbackgroundPaint.

It would be X-Platform, consistent, simple, intuitive and even discoverable! Certainly much more user friendly for the non-pro audience they are targeting than having to know to use a color group on a Mac to get the right highlight color!


And color groups are not backwards compatible so that kind of puts the fubar into it if you need that

One of the old issues was that the highlight color / selected color was accessible in different ways depending on what API you were using etc
Some of that is what makes even using a declare painful