Tk Source Code

This is new behaviour, and i ~think~ is probably a bug.

If the "belowThis" tag is not defined, wish throws an error.
All previous version os wish this does not happen.

pack [canvas .c]
.c create line 0 0 10 10 -tags aline
.c lower aline noline

> tag "noline" doesn't match any items

Merged to trunk, following acceptation of the TIP by the TCT.

I have created [http://core.tcl-lang.org/tips/doc/trunk/tip/565.md|TIP #565] to gather further comments on this.

I understand what was done in [3437816fff]: symmetry between the error-spitting <code>.canvas raise</code> command and the non-error-spitting <code>.canvas lower</code> was restored so that both spit the same error. Yes this was a bugfix, and the reasons for having done so are explained in that ticket.

That said, in the wake of the "Do nothing gracefully" reform, aka [https://core.tcl-lang.org/tips/doc/trunk/tip/323.md|TIP #323], I think we could indeed remove the error when calling <code>.canvas raise|lower</code> with a non-existent "aboveThis"|"belowThis" tag.

Especially since the error spitting is currently inconsistent:
<verbatim>
package require Tk
.c create line 0 0 10 10 -tags aline

# inconsistent error spitting
.c lower aline noline   ; # tagOrId "noline" doesn't match any items
.c lower bline aline    ; # no error

# ditto for raise instead of lower:
.c raise aline noline   ; # tagOrId "noline" doesn't match any items
.c raise bline aline    ; # no error
</verbatim>

We would do this in 8.7 and not in 8.6. Would need a small TIP I guess.

Comments?

The issue is <b>Many</b> tk apps are now going to needlessly start throwing errors.
My tkspider game does just this. (screenshot attached).

There is no real plus side to this change.

File Added - 455554: a6.png

I't be nice to not throw an error here (and also modify the raise command's behaviour)
* AFAIK - all other references to  non-existing tags do not throw errors
* This is the way it has been with "lower" for a long time.

No, it's a FRQ

allow_comments - 0



data_type - 362997

allow_comments - 1

No, it's a bug fix: See #3437816