backcolor being reset to yellow

General
1

I have been having a problem some controls with the backcolor being reset (to yellow), so I added, for instance, me.BackColor = RGB(255,255,255)
It didn’t work completely and I’m not sure how to describe it.
I didn’t select any text. but one textarea control in an array kept the problem of seltext color being yellow after something happened
The text seemed to have a selected color, as in the color is usually blue, of yellow.
I do know there was some selected text, but selstart and sellength are 0 at the end of a method.
The color didn’t change with that run of the debugger no matter how many times the text changed until I restarted.
Not even sure how to test for this randomness.

2

First thing to do if you encounter weirdness is to quit Xojo and empty it’s cache. Simply reboot the computer if you don’t want to empty the cache manually, or look for a script to do it automatically.

3

My suspicion is that XOJO handles colors internally differently from what is exposed to developers, or that it may have a bug.

For example, set an object with a color to RGB(255,255,255) or to the color literal &cFFFFFF (the alpha component would default to 0 if not specified, so this color would be defaulted to &cFFFFFF00). Now look at the color as a text string using the Str function. This will return “ h00FFFFFF” . Clearly this hex string is in the form “hAARRGGBB” rather than “&cRRGGBBAA.

Note that if your code (or a bug in XOJO) reads it in RR,GG,BB order, then your color would be equivalent to &c00FFFFFF or RGB(0,255,255) , also known as “Yellow”. (If it handles the last hex value as “alpha”, then it should apparent fully transparent).

Do you handle, set or convert colors using Strings at any point? If so, I would look for the error there?

Or maybe there’s a bug in XOJO? For example, in the documentation for the Str function, it says “For Colors, it returns the string value of the Color as a Hex number in the format, &hRRGGBB. "

I think this statement is wrong and should say: … &hAARRGGBB .

If the intention is to return as &hRRGGBBAA , then there’s a bug in XOJO

4

I doubt this is the issue…
The reason (I suspect) that you see assign ALPHA on the RIGHT, but later see it on the LEFT
is due to the fact that Xojo implemented Alpha as part of the Color Object “late in the game”
so the assign it on the right end in order to not break existing code.
but internally shift it to the left side where the operating system is expecting it

So yes, if you say

myColor=&c12345678

if will return

s=str(mycolor)  // &c78123456

This is not to say there is not a bug in the specific color handling code for a TextArea (since it doesn’t support Alpha colors, it may not have implemented the same methods [though it should])

but it all uses RRGGBB and not RRGGBBAA then there should be no problem.

perhaps the OP expects the color to change once SelStart/Length are changed? If so that doesn’t happen.
Its not “highlighting” like dragging the mouse in the IDE… once set it stays set until you physically change it again

6

this happens since years. it happens to me only after Xojo crashes, text fields loosing the color information for whatever reason, I don’t know. I subclass my textfields and textareas and set back color to white.

7

I forgot to say, I’m on OS X, it might work for windows, linux … differently

8

I confirm this is happening since years.
Here it’s a feedback case where I reported some clues to help finding the problem: <https://xojo.com/issue/49214>
If you can reproduce it please comment the case to have it opened again, please.

9

Thanks for confirming I’m not crazy. This is the first time I had this problem. I have only had this problem for years with it showing up when the page only opens in the IDE. Still can’t figure out how to produce a test case.

10

I’ve seen this many times after a crash of the Xojo IDE. But i was not able to make a reliable case for a FR…

11

For me it’s always an ‘unsaved’ project that xojo offers to recover after a crash. The binary ‘safety’ copy written during a debug run doesn’t always properly recover background colors in text objects. It resembles a big vs little endian byte swap incorrectly restored. I’ve seen &cFFFFFF00 turn into both &h00FFFFFF (yellow) and &HFF00FFFF (magenta), but I can’t pin it down, either.

12

This is what I also found, however can’t reproduce this 100% and this is why my feedback case was closed.
There should be something additional to have this happening.

13

This is exactly what appened more than 1 time, here. :slight_smile: