Tk Source Code

View Ticket
Login
Ticket UUID: 3437816
Title: canvas lower tagOrId ?belowThis?
Type: Bug Version: obsolete: 8.6b2
Submitter: hirner Created on: 2011-11-14 15:13:22
Subsystem: 04. Canvas Basics Assigned To: ferrieux
Priority: 5 Medium Severity: Minor
Status: Closed Last Modified: 2013-09-08 03:17:30
Resolution: Fixed Closed By: dgp
    Closed on: 2013-09-08 03:17:30
Description:
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.
User Comments: dgp added on 2013-09-08 03:17:30:
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

dkf added on 2012-08-01 15:46:53:

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.

nijtmans added on 2012-08-01 15:42:48:
> 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.

nijtmans added on 2012-08-01 15:31:25:
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.

ferrieux added on 2012-08-01 15:27:42:
s/widget/item in the previous comment, obviously ;)

ferrieux added on 2012-08-01 15:22:50:
> 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.

stevenaaus added on 2012-08-01 15:16:57:
You have modified long standing core behaviour of tags and the canvas.
Has there been any discussion about this ?

stevenaaus added on 2012-08-01 15:04:19:
> 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.

ferrieux added on 2011-11-15 00:48:15:
Fixed in trunk.

hirner added on 2011-11-14 22:18:57:
sources:   generic/tkCanvas.c