The problem with listbox.CellBackgroundPaint

General
1

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:
-Karen

2

It’s not clear to me from your rambling “rant” what your problem is. Show us you code and then describe the problem.

3

you not have this constant or is it displayed wrong at your mac?

Color.HighlightColor

there is no date in docu when it was added to xojo.

at least at windows it seems the default blue selected color.

based on the row selected state you could draw this color or something else.

4

The problem comes down to the fact that Xojo does not provide a framework method for setting the selected row highlight color for the listbox on the Mac. (actually there are 2 different ones - one where the listbox is active and one where it is not)

The workaround is to use declares to get teh colors, but that should not be necessary, and the way apple changes APIs , It would be best if the framework provided the colors

The reason you need to know the highlight color is that on a Mac if one needs to draw outside the text area provided in CellTextPaint event one needs to do it in CellBackgroundPaint… but then you have to draw the highlight color yourself and so need to know it, but the framework does not provide it.

In the past I have worked around that with a declare, but this really should be built in.

-Karen

5

It has existed forever as RealBASIC.HighlightColor

But It’s the wrong color on a Mac… the Mac uses what the OS calls the AlternateHighlightColor But Xojo does not provide that.

The simplest thing would be if they just assigned the the background color to be used to the graphics context that is passed into CellBackgroundPaint.

That way it would be right for any listbox state on any OS. But as I said I suggest ed that many years ago (over 10) and it never happened even though it is a logical need and (famous last words) should be trivial for them to implement.

-Karen

1 Like
6

That is not true. With the introduction of the ColorGroup class in 2019r3, it is possible to access the native color values.

' Highlight Color (active)
g.DrawingColor = ColorGroup.NamedColor("selectedContentBackgroundColor")

' Highlight Color (inactive)
g.DrawingColor = ColorGroup.NamedColor("unemphasizedSelectedContentBackgroundColor")
7

First that does not help me as i can’t use that as I need to be backwards compatible…

But really how would one know to do that?

Those names are not in teh language reference and certainly not in teh Listbox docs that I can find … Not very user friendly, and certainly not hopbbiest / “citizen developer” friendly…

a big reason many people use Xojo so they don’t have to know such OS specific details…

I never understood why they never just set g.forecolor (or the API 2 property name) to the correct background color for the graphics object passed into CellBackgroundPaint upfront.

After all the text drawing setting are passed in that way into the CellTextPaint event, including teh color to draw the text!

Doing that for CellBackgroundPaint would be X-Platform, consistent, simple, intuitive and even discoverable!

It would certainly be much more user friendly, particularly for the non-pro audience they are targeting, than having to know to use a color group and the right names on a Mac just to get the right cell background color!!

IIRC I put in a feature request for that over a decade ago… It never got any traction with teh company…

Famous last words but it seems the should be VERY easy to implement… they have to get the color so they can draw the background anyway it seems to me!

It is a little thing, but a lot of little things play a large factor in what people think of a product.

-Karen

1 Like
8

You can look here. I’ve created a post about :wink: Quick Tip: macOS System Colors without Declares - It looks very much like ColorGroups are the future in Xojo.

Which Feedback Case Number(s)?

9

IIRC they were using different system for that back then. I have been considering submitting a new one… but I doubt it would get implemented.

-Karen

10

OK I submitted a request…

<https://xojo.com/issue/62640>

62640 - Pass the appropriate background color for the state into CellBackgroundPaint by setting g.DrawingColor upfront

There is no way (without declares) to get the the correct Cellbackground color for the state the row is in without resorting to a declare or named colors.

That means if you :

  1. Need to match the look of the other Xojo listboxes in your app
  2. need to draw on top of the cell background color
  3. And part of that drawing needs to be outside the drawing area the graphics context context provided in CellTextPaint supports

You have to to know that color so you can:

  1. fill the cell with it
  2. Do your Drawing
  3. return true so the framework does not obliterate your drawing

Right now to know that color you need platform specific knowledge… which is not simple as as the cell can be selected or not Active or not or the listbox can be disabled but the row selected….

Because of this complexity the solution proposed in Julian’s request may not be adequate…

A big reason many people use Xojo is so they don’t have to know such OS specific details…

The simplest solution would be to set g.DrawingColor to the correct background color for the cell State for the graphics object passed into CellBackgroundPaint upfront.

This would be consistent with what has always been done for CellTextPaint where all the text drawing setting are passed in that way into the CellTextPaint event, including the color to draw the text!

Doing that for CellBackgroundPaint could be X-Platform, consistent, simple, intuitive and even discoverable for us!

It would certainly be much more user friendly, particularly for the non-pro audience then Xojo targeting, than having to know to use a color group or some other methods just to get the right cellbackground color!!

Workarounds:
Use declares or NamedColors

11

Not sure I understand… You want Xojo to add something to access the listbox’s highlight colour, but, at the same time, the “new” calls Martin mentioned don’t help you because they are not backward compatible.

I’m afraid they are mutually exclusive.

12

There is the current project I am working on, which HAS to be backwards compatible with OS x 10.7, and there is the future.

What i was saying is that I can’t use his solution FOR THIS PROJECT, but that does not speak to future projects.

I have felt for many years that the framework should provide a platform agnostic way to get this property in the framework.

His solution still requires that you need to know OS specific stuff (and you still have to figure out which named colors Xojo is using) for no good reason.

Passing the correct background color into the CellbackgroundPaint event in the graphics context so one does not even have to think about it would be best IMO

-Karen

13

I think Karen means backwards compatible in that the project would still compile in older IDEs. Obviously the new feature won’t be there, but it will still at least build. Color groups don’t exist at all in older IDEs, so the project won’t compile.

This is very clever, and would be a super cool way to implement it.

1 Like
14

I fail to see how the new features that are (obviously) not in older IDEs would compile there either.
Color groups don’t exist at all in older IDEs, right, but new features are the same (Color group “is” a new feature).

But perhaps I’ve not understood the conversation… :thinking:

15

Yes, there are some things like this one that have always be absent from Xojo/RS/RB.
Being part of a “colour list” where other items are available, I always wondered why this one was not considered.

That’s the same kind of things as the SpecialFolder function to retrieve items not in Xojo’s list (don’t remember the exact name right now).
I bet this is even worse in XCode languages, because you certainly have to use these constants every time (not just when they aren’t included in Xojo).

I agree.

16

It’s the default color of the g as Graphics object. The Graphics object exists in old versions. You’re not understanding what the issue and suggestion is if you don’t understand this.

17

I’ve actually never used or considered color groups as of now, so it’s possible it’s the reason I don’t get it…

18

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.