Tcl Source Code

I have encountered what is probably the weirdest bug that 
I have ever seen. I have a little color chooser that I wrote 
recently because none of the ones available did quite what 
I wanted. One of its features is that you can ask it to propose 
a random color. Another is that you can ask it to find the 
named color that is closest to the current color. 
 
When you ask for a random color, it shows it in the lower 
of two example slots. If you then ask for the closest named 
color, the random color is moved into the upper example slot 
and the named color is shown in the lower one. In general, 
the two will not be identical since there are far more 
possible colors than named colors. 
 
The bug arises when a message translation is read 
(that is, when msgcat::mcget is executed and finds 
a tranlsation in the message catalogue. 
(Loading a message catalog is not sufficient to trigger the bug.) 
When  
 
When I do, the color chooser always shows the random color 
as agreeing perfectly with some named color. 
A little investigation shows that what is actually 
happening is that the primary example is being copied 
into the secondary example slot, as it should, but is 
then not being updated with the color of the closest 
named color. So the two identical colors shown are 
the random color, not the closest named color. 
It turns out that SetColor is not being called 
in response to the ButtonPress-1 event generated 
at the end of ShowEntry. 
 
I have succeeded in constructing a version of the 
program from which I have stripped as much as I 
can without eliminating the bug, and a version 
that eliminates the bug. They differ by the single 
line: 
 
pack .srch.search -side left -expand 1 -fill x -anchor e  -padx 4; 
 
As far as I can see, there is nothing wrong with this line, 
or with anything else in the Tcl code. I am wondering 
whether I have managed to trigger an obscure memory 
allocation bug. 
 
This is with Tcl/Tk 8.4.11 on GNU/Linux 2.6.3-7 with Gnome.. 
 
To reproduce the bug: 
 
(a) set your locale to French, e.g. fr_FR. 
(b) run ReducedWithBug.tcl (attached) 
(c) click on "Alleatoire" - a new color should appear in 
     the lower example slot; 
(d) click on "Plus Proche" 
 
If the bug is present, the upper example slot will become the 
same color as the lower one. If the bug is absent, this will only 
happen in rare instances. So, if the two are not the same, you can 
be sure that the bug is not present. If the two are the same, 
repeat the process a few times. If the two examples are always the 
same after pressing "Plus Proche", the 
bug is present.

Logged In: YES 
user_id=939324

Yes, I guess it is a Tk issue. I'll refile it there. Thanks.

Logged In: YES 
user_id=939324

There is indeed a bug. The only circumstance in which the
upper and lower colors should be the same is when the random
color happens to be one of the named colors. The fact that
the two are always the same (after pressing "Plus Proche)
indicates the existence of a bug. My diagnosis of this as
failure of
ShowEntry to trigger the ButtonPress-1 event (or of that
event to trigger the desired action, namely the calling of
SetColor) is correct in that it explains why the lower color
is not changed to that of the named color selected by
FindClosestNamedColor. I now realize that my message above
was misleading in one respect: where I said " the color
chooser always shows the random color as agreeing perfectly
with some named color" I mis-spoke; I should have said "the
color chooser always shows the random color as agreeing
perfectly with what is supposed to be the closest named color".
The rest of the description is correct.

You can see the difference in behavior by changing your
locale to something other than French or by commenting out
the line:
pack .srch.search -side left -expand 1 -fill x -anchor e -padx 4

I recognize that it is hard to deal with such a large
example of a bug but I haven't yet figured out how to remove
anything further and still trigger it.
Commenting out that one line is sufficient to eliminate the bug.

Logged In: YES 
user_id=939324

There is indeed a bug. The only circumstance in which the
upper and lower colors should be the same is when the random
color happens to be one of the named colors. The fact that
the two are always the same (after pressing "Plus Proche)
indicates the existence of a bug. My diagnosis of this as
failure of
ShowEntry to trigger the ButtonPress-1 event (or of that
event to trigger the desired action, namely the calling of
SetColor) is correct in that it explains why the lower color
is not changed to that of the named color selected by
FindClosestNamedColor. I now realize that my message above
was misleading in one respect: where I said " the color
chooser always shows the random color as agreeing perfectly
with some named color" I mis-spoke; I should have said "the
color chooser always shows the random color as agreeing
perfectly with what is supposed to be the closest named color".
The rest of the description is correct.

You can see the difference in behavior by changing your
locale to something other than French or by commenting out
the line:
pack .srch.search -side left -expand 1 -fill x -anchor e -padx 4

I recognize that it is hard to deal with such a large
example of a bug but I haven't yet figured out how to remove
anything further and still trigger it.
Commenting out that one line is sufficient to eliminate the bug.

Logged In: YES 
user_id=80530


The essence here is when an
[event generate] on a $canvas
will fire scripts registered by
the [$canvas bind] command
onto a particular canvas item.

Those are Tk issues, so at least
re-file these questions with the
tktoolkit project, and assigned
to one of the Categories dealing
with [canvas].

Do try to narrow things down more
though.

Logged In: YES 
user_id=80530


> When I do, the color chooser
> always shows the random color
> as agreeing perfectly with some
> named color. 

That's not what I see.

following your instructions, I get
a random color of #173971 and
the "Plus Proche" does produce
the same color in both slots.
However, that color is not a
named color.

This suggests the bug is really
in your [ShowEntry] routine
not displaying one of the named
colors.

I'm not seeing any evidence of
a bug in Tcl or Tk here.

If there's really a bug in Tcl or
Tk lurking here, we'll need
a simpler demo of it, and a
more precise pointer to just
what the problem is.

File Added - 149930: ReducedWithBug.tcl