Fixed bug [f0188aca9e] (color names parsing on Windows), by Simon Bachmann

1 files changed, 23 insertions, 1 deletions

diff --git a/tests/color.test b/tests/color.test
index a7ed1f8..aa20099 100644
--- a/tests/color.test
+++ b/tests/color.test
@@ -90,7 +90,17 @@ proc colorsFree {w {red 31} {green 245} {blue 192}} {
 	    && ([lindex $vals 2]/256 == $blue)
 }
 
-if {[testConstraint psuedocolor8]} {
+# -- WARNING (SB, 6.4.2017) --
+#
+# The if block below looks _very_ outdated. It didn't get any
+# substantial changes as far back as the fossil history goes. It might
+# be from a time, when 256 color was the best you could get! :-o.
+#
+# The problem is, on machines with a fancy 24 truecolor display, the
+# 'colorsFree' constraint doesn't get set, turning off pretty much every test
+# in this file.
+
+if {[testConstraint pseudocolor8]} {
     toplevel .t -visual {pseudocolor 8} -colormap new
     wm geom .t +0+0
     mkColors .t.c 40 6 0 0 0 0 6 0 0 0 40
@@ -185,6 +195,18 @@ test color-2.6 {Tk_GetColor procedure} {colorsFree nonPortable} {
 test color-2.7 {Tk_GetColor procedure} colorsFree {
     winfo rgb .t #ff0000
 } {65535 0 0}
+test color-2.8 {Tk_GetColor, invalid char after 3 valid hex digits} -body {
+    winfo rgb . #abcg
+} -returnCodes error -result {invalid color name "#abcg"}
+test color-2.9 {Tk_GetColor, invalid char after 6 vaild hex digits} -body {
+    winfo rgb . #aabbccz
+} -returnCodes error -result {invalid color name "#aabbccz"}
+test color-2.10 {Tk_GetColor, 3 hex digits, last one invalid} -body {
+    winfo rgb . #abz
+} -returnCodes error -result {invalid color name "#abz"}
+test color-2.11 {Tk_GetColor, 6 hex digits, last one invalid} -body {
+    winfo rgb . #12345g
+} -returnCodes error -result {invalid color name "#12345g"}
 
 test color-3.1 {Tk_FreeColor procedure, reference counting} colorsFree {
     eval destroy [winfo child .t]