Label.TextColor = &c00000000 does not equal black text. Why???

I have several labels that I am using as indicators on a window with a black background.

I’ve discovered that when I set the Label.TextColor to &c00000000, the label text becomes gray (not black).

The closest to actual black I can get is to set Label.TextColor to some very low but non-zero value.

I want the labels to essentially disappear into the black window background when they are not hi-lighted.

Why does the label control refuse to display text as black?

This is happening on Ubuntu & Raspbian Linux if that matters.

Xojo turns text that is &c000000 to the system provided text color so that dark mode works correctly. To disable the auto system-color feature you have to use a slightly off-black as you’ve discovered. Doing so by only one is all that’s necessary, as long as it’s not &c000000.

Edit: It probably shouldn’t happen on systems that don’t support dark mode, but I would guess that feature is why you’re not able to use &c000000 black.

Maybe a bug related to the alpha channel (transparency). Create a sample case and post a bug report.

also with = Color.Black ?
or its because label should be visible and black on block is forbidden.
label have not a .visible property?

colors really need 3 settings

  1. an explicit color ( &c000000 )
  2. a name (like Red or TextColor)
  3. maybe a value like “Default” which, on a supported OS, follows the default for the control (textcolor for labels,text areas, textfields)
    this way when you’re in Dark mode on macOS its one color, in light mode its different

Right now &c00000000 serves purpose 3

If you want it to NEVER change from “black” use &c01000000


An “internal color” needs more bits to describe the special features OUTSIDE the RGBA value.

Thanks guys.

I had a suspicion that I was dealing with a “magic number” implementation. I truly hate magic numbers. I agree with Norman that there needs to be some additional metadata like the “Default” he suggests to indicate that the object should track the OS specified color scheme.

&c00000000 really should yield Black, not some undocumented alternate color and/or behavior.

Anyway, my curiosity is assuaged and I’ll add some code to fudge my way around this.


OS color support should not be assumed to be 32 bit values :slight_smile:
NSColor represent each component as a CGFloat and so can represent colors that dont have an exact equivalent in a Xojo color
.Net’s “Color” has ScA, ScB, ScG, ScR which are all floats

Xojo doesnt have a color type that maps onto those well as it assumes colors are only 32 bits