Tk Source Code

Example:
pack [canvas .c]
if { [catch {.c raise A B} err] } {
   puts "TCL_ERROR >>$err<<"
} else { 
   puts "TCL_OK >>$err<<" 
}
RESULT: a TCL_ERROR occurs  an this is ok. see:
TCL_ERROR >>tagOrId "B" doesn't match any items<<

the same with the lower command:
 
if { [catch {.c lower A B} err] } {
   puts "TCL_ERROR >>$err<<"
} else {
    puts "TCL_OK >>$err<<" 
}
RESULT: TCL_OK occurs instead of an TCL_ERROR !!! see:
TCL_OK >>tag "B" doesn't match any items<<

the lower command should also return an TCL_ERROR when tag "B" doesn't match any item.
Or is the behavior well known?

Thanks
Hirner U.

It's likely this change broke something called
"wavesurfer", at least as reported over in the
Debian world.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719109

allow_comments - 1

Since the fix in question (https://core.tcl.tk/tk/ci/43facdb6f8?sbs=0) was just ensuring that we generate an error (and *not* a change to the message) it's pretty clear that the bug was due to an errant refactoring.

Changing the behavior to no longer produce an error is a reasonable request (which I might or might not agree with) but it *is* a FRQ and not a bugfix. As such, I'm locking out non-dev comments; pursue this via a new issue if you want.

> Steven, may i suggest a workaround for you: just put a
> [catch] around it in your code, and it will work as
> you expect in any Tk version.

Or file a feature request, together with a use-case why
this would be useful. But then it should involve
both the "raise" and "lower" subcommands.

Steven, may i suggest a workaround for you: just put a
[catch] around it in your code, and it will work as
you expect in any Tk version.

Looking at the documentation:
> \fIBelowThis\fR is a tag or id; if it refers to more than one
> item then the first (lowest) of these items in the display list is used
> as the destination location for the moved items.
This says nothing about what happens when the belowThis
doesn't match anything, so - yes - that should be clearified.

s/widget/item in the previous comment, obviously ;)

> Why ? These seems silly to me. 

Because the obvious failure path is a typo in the ?belowThis? item/tagname...

Moreover, the fix just brings symmetry between 'lower' and 'raise'. If you find the 'raise' behavior silly, you've been quite silent for the 15+ years it has been in effect.

> If we delete a tag from an item that doesnt already have the tag - should this be an error too?

Nope, the analogy between lower/raise and dtag is wrong: lower/raise (with an extra argument) clearly express an intention to finely tune the stacking order wrt a specific widget, whose existence must be verified; while dtag is typically a mass-manipulation tool: calling dtag B over a tag A is an elegant way of computing set difference.

You have modified long standing core behaviour of tags and the canvas.
Has there been any discussion about this ?

> the lower command should also return an TCL_ERROR when tag "B" doesn't match any item.

Why ? These seems silly to me. 
If we delete a tag from an item that doesnt already have the tag - should this be an error too?

% .c create line 0 0 10 10
1

% .c dtag 1 notag

[no error]

I think this is a bad change.

Fixed in trunk.

sources:   generic/tkCanvas.c