DesktopTextArea.Text Color with 2022r4 on macOS - Feature or Bug?

I noticed something with 2022r4 that 2022r3.2 or prior didn’t do.

With “AllowStyledText” turned off, setting DeskTopTextArea.TextColor no longer works (at least on macOS in light mode).

Here is how to replicate this:

  • Create a new Desktop project
  • Add a DeskTopTextArea to Window1. Disable its “Allow Styled Text” property in the IDE
  • Add the following code to the Window1.Opening event handler or the Pressed event handler of a button:
    TextArea1.TextColor = &cffffff00
    TextArea1.BackgroundColor = &c00000000
    TextArea1.Text = “Hello World”
  • Run the project

With 2022r3.2 and prior, this results in Text Area with a black background and white font. However, with 2022r4, this results in black text on a black background. This is at least the case on macOS in light mode. Setting the text color seems to work in dark mode.

Is this behavior intended or a bug?

Is it just white or is it any color? What version of macOS?

Any color. macOS Ventura.

Beta 58692, Ventura 13.1 beta:

It’s a bug. I haven’t bothered to log it, just coded around it. It doesn’t seem to be related to AllowStyledText as I’ve found the same thing with it on. Seems to be just dandy in light mode but, in dark mode, new text will go to black - seemingly at random. And it goes back to 2021rx. It’s not Ventura’s fault as manually setting &cFFFFFF on DarkMode stops it dead - so the OS is informing the app of it’s mode - Xojo just isn’t responding correctly.

Sorry for not logging it.

Hi Beatrix, if you want to reproduce it, just chuck a DesktopTextArea in a window and type something during runtime whilst in DarkMode.

Don’t know if it does it in TextFields or on Windows but I know it does it in both TextAreas and DesktopTextAreas. But, as I say, it’s a bit random…

During testing I added an Issues report that TextColor always showed as Black (I was trying Green text on a Black background), even when changed. It seems they have more work to do, as this it still the case.

Yep, that is consistent with what I’m seeing. I have a major project that I’ve been maintaining for over 10 years, and I have a text area that let’s the user select custom colors. This has worked up to (and including) 2022r3.2 but broke with 2022r4. The workaround I found that works for me is to temporarily set “AllowStyledText” to true, then set the background and text color, and then set “AllowStyledText” back to false.

@David_Cox, what’s the report number for this issue? I’ll see if I can add some additional information.

Im also seeing this problem with the old TextArea and TextField controls. They do not switch automatically as they should when theme is changed. In dark-mode they display black text instead of white on a black background.

Long-term legacy project has worked fine through 2022r3.2 but broken now on 2022r4.

Many TextAreas in the project would take a long time to convert to DesktopTextArea.

My Issues report is: https://tracker.xojo.com/xojoinc/xojo/-/issues/70689#note_543101

It says fixed now… So I suspect in either 2022r4.1 or 2023r1 update.

4 weeks ago targeting r4. What was done should be in the current release.

Sometimes things don’t make it into release. Perhaps this didn’t. You would be best asking in the bug report, that way the developer who made the change gets messaged.

Not tested. Not sure if is does not work, not sure if @David_Cox issue or some variation of it still exists. If so, would be his job giving more details about his findings there.

It is fixed in the latest release. but there might be further problems than my initial issue.

Sorry, I thought you were saying it wasn’t fixed :slight_smile:

My initial issue was fixed, but a regression crept in, which was fixed in the latest release, but I still have an issue with the latest release that I have not had time to pin down in a sample app. Sorry if this is confusing (it is even to me).

Sounds fun… in a depressing sort of way :slight_smile:

It’s g-r-o-w-i-n-g [Cue ominous music] 2022.r4 IDE

Screenshot 2022-12-19 at 10.30.33 am