Colour change escape sequences in Label() strings don't work correctly

Issue #265 resolved
prl created an issue

In Label() strings colour change strings are allowed in the form \cAARRGGBB, where the characters are hexadecimal digits.

Hexadecimal digits 'a'..'f' and 'A'..'F are interpreted as numbers 1..6. 'j'..'o' and 'J'..'O' are interprereted as he hexadecimal digits 'a'..'f'.

Eg, in the colour change string \cFEDCBA98, the colour interpreted as #65432198. The colour change string \cONMLKJ98 is interpreted as #fedcba98.

The cause of the error is in the constructor gRGB::gRGB(const char *colorstring) in gdi/pixmap.h, where ASCII characters are converted into 4-bit integers by

val |= (colorstring[i]) & 0x0f;

This is correct for ASCII digits '0'..'9', but not for 'a'..'f' or 'A'..'F'.

I have a fix for this ready to check in.

This bug does not affect other colour code interpretations in the repository Python code (like parseColor() in skin.py), because they use the gRGB::gRGB(unsigned long val) constructor.

Reproduction steps

This is hard to reproduce within the GUI.

In the code, find a fixed string Label, and change its text from something like:

"This is a text label"

to something like

"This\c00ffffff is a\c00666666 text\c00oooooo label"

In this example, "This" will be displayed in the skin foreground colour, "is a" will be in grey, "text" will be in the same shade of grey as "is a", and "label" will be full white.

Comments (3)

  1. prl reporter
    • removed issue_update

    The issue was updated with the following change(s):

    • This issue's description has been changed
  2. Peter Urbanec
    • removed issue_status

    The issue was updated with the following change(s):

    • The status has been updated, from New to Testing.
  3. prl reporter
    • removed issue_resolution
    • removed issue_percent
    • removed issue_close
    • removed issue_status

    The issue was updated with the following change(s):

    • The status has been updated, from Testing to Closed.
    • This issue has been closed
    • This issue's progression has been updated to 100 percent completed.
    • The resolution has been updated, from Not determined to Fixed.
  4. Log in to comment