#926 Canvas item active and Enter fail if mouse moves quickly

obsolete: 8.3.1
Brent B. Welch

OriginalBugID: 5989 Bug
Version: 8.3.1
SubmitDate: '2000-07-06'
Severity: LOW
Status: UnAssn
Submitter: techsupp
OS: Windows NT
OSVersion: NT 4.0 SP5 Server
Machine: 600MHz, 256KRAM

Roy E. Terry

package require Tk
canvas .c
set rid [.c create rectangle 10 10 100 100]
.c itemconfigure $rid -activefill yellow
# .c bind $rid <Enter> {puts "Entered [incr eCnt]"}
pack .c

when the mouse moves *slowly* into the rectangle it becomes active and
turns yellow. When the mouse is quickly moved to the center area of the
rectancle (not point to its border) then the rectangle never turns yellow.

Mouse over a canvas item should (eventually) always be detected and standard behavior should be then executed. In this case the rectangle should eventually
turn yellow as long as the pointer remains in the rectangle.


    • labels: 104343 --> 104332
  • Points inside of a rectangle are not considered as "inside" points, so I think <Enter> should only work on the vertices. For the disired behavior a polygon should be used.

  • Don Porter
    Don Porter

    • labels: 104332 --> 05. Canvas Items
  • Jeffrey Hobbs
    Jeffrey Hobbs

    • status: open --> closed-invalid
  • Jeffrey Hobbs
    Jeffrey Hobbs

    Logged In: YES

    As noted by hinteger, an unfilled rectangle only has valid
    points on the edge, and when moving a mouse quickly, mouse
    points will get dropped.

  • Logged In: YES

    But that behavior is absolutely senseless. Or do you
    consider the pointer as "outside", if the mouse is moved
    into the rectangle very quick ??
    I think that bug was introduced with the dash patch, since
    that behavior was definitely not in 8.0.5.
    I even submitted a TIP
    http://tcl.activestate.com/cgi-bin/tct/tip/46.html for that,
    but noone ever responded to it, maybe I should contact one
    of the TCT directly, Jeff ?
    My TIP basically sugests, that all objects are "real"
    objects have a) vertices *AND* b) an area (*regardless* of a
    fill color) and not have different combinations of a) and b)
    for different canvas objects.
    The tip also sugests a special fill color (e.g. "hollow")
    for objects, that are only wireframes. (like in the not
    desired example of Roy)

    There even was a patch to correct that (at least for poly
    and rectangle I think, consisting of just a few lines,
    submitted by John Ellon) but that patch never seemed to
    reach one of the TCT members

    Gerhard Hintermayer

  • Jeffrey Hobbs
    Jeffrey Hobbs

    Logged In: YES

    I like the idea of a 'hollow' fill color, as that would
    also address:


    However, as I noted in the about response, I think it is
    correct behavior. We are not declaring the mouse to be
    incorrectly "inside" or "outside", because that is not what
    is being asked. There is certainly room for improvement,
    but I do believe the current behavior is reasonable.

  • Logged In: YES

    Just noticed in my similar bug entry #226357, that the patch
    is in 8.4a3cvs since june.
    But then ther's still the TIP to discuss

    Gerhard Hintermayer

  • Logged In: YES

    Jeff, I don't see any benefits in your CLT posting, nor do I
    see it as a correct behavior, because "canvas find overlap"
    would not return the enclosing object either, which is at
    least a behavior you have to have if you want to write
    graphic editors, which basically use the canvas as drawing
    sheet. I wrote such an editor for a SCADA system and had to
    use a special treatment for objects, that were just
    wireframes, because I could not select them (exept by
    clicking directly on a vertice), since "canvas find overlap"
    did *NOT* return the items for interior points. I had to use
    "canvas find closest" in a loop, while incrementing halo,
    until I found an object, which is definitely a) slow and b)
    not elegant at all.

    Gerhard Hintermayer

  • Logged In: YES

    The only canvas items that notice the mouse in their inside when that is transparent are polygons (the other effect can
    always be done with a closed line) all other items are (supposed) to only have inside to be those points that are painted by
    the item. The easiest way to do sensitive collections is to place a completely transparent polygon over the whole lot and
    put all the bindings on that (using tags or an array to handle the aggregation, depending on the precise details of the app.)

    IIRC, this is the way Tk (and coincidentally other toolkits have analogous behaviour) is documented to behave; if it doesn't,
    report it as a bug.

  • Logged In: YES

    Give me just one good reason why polys should be treated
    different than other objects.
    I know there's a workaround, but doubling the objects in a
    canvas has a large impact if element count is high,
    splitting rectangle points to polys is not elegant nad what
    about cirles/arcs - should I write my own proc to split an
    arc/circle to a poly ?
    I know that the docs are right and that the behavior of the
    canvas is according to the man page, so that's the reason I
    wrote a TIP and *not* a bug report.
    I really don't know why everybody says "leave it as it is,
    because it is conforming to the man page", this
    functionality (differ between poly and others and the lack
    of ability to create transparent objects, i maen objects
    that have an area and not just wireframes) doesn't make any
    sense to me.
    Lets make all objects behave the same way, with *no*
    exeption. And give the application designer a posibility to
    differ between -fill "" and e.g. -fill hollow/transparent,
    the first should create solid transparent objects (interior
    points belong to object, Enter/Leave generated anywhere
    inside), the latter wireframes (only vertices belong to
    object, Enter/Leave generated only at vertice)