New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Color Clamping #38

HakShak opened this Issue Feb 25, 2015 · 2 comments


None yet
2 participants

HakShak commented Feb 25, 2015

After using a measure for each color (, I tried to create the long version of Clamp() inline with LineColor, and that works, however, it's extremely unwieldy.

I find it odd that the Color::MakeARGB function seems to accept values above and below 255 and does what seems to be a modulo operation on them. Which may be a by product of casting somewhere within their API.

Is there any reason not to clamp the color range here:

ARGB ConfigParser::ParseColor(LPCTSTR string)
int R = 255, G = 255, B = 255, A = 255;
if (!ParseInt4(string, R, G, B, A))
if (wcsncmp(string, L"0x", 2) == 0)
string += 2; // skip prefix
size_t len = wcslen(string);
if (len >= 8 && !iswspace(string[6]))
swscanf(string, L"%02x%02x%02x%02x", &R, &G, &B, &A);
else if (len >= 6)
swscanf(string, L"%02x%02x%02x", &R, &G, &B);
return Color::MakeARGB(A, R, G, B);

I'm not clear if it's a common practice to take advantage of this "looping" pattern.


This comment has been minimized.


brianferguson commented Mar 3, 2015

The problem was not really in the Clamp function itself, but with the parsing of comma-separated options with multi-arg math functions.

This has been fixed as of the latest beta, so I am closing this issue.


This comment has been minimized.

HakShak commented Mar 7, 2015

If anyone is curious about an easier work around for this:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment