#1978 Missing <Enter> events for items

obsolete: 8.4.19
closed-accepted
9
2008-04-17
2005-10-15
No

When a <ButtonPress> (setting LEFT_GRABBED_ITEM), e.g.,
is bound to tk_popup a menu (triggering <Leave> item
and <Leave> canvas), leaving the menu with the pointer
positioned in the original item triggers <Enter>
canvas, but erroneously not <Enter> item.

Reproducable on Unix by:
pack [canvas .c]
.c create text 50 50 -text X
.c bind 1 <Enter> {puts "Enter 1"}
.c bind 1 <Leave> {puts "Leave 1"}
bind .c <Enter> {puts "Enter .c"}
bind .c <Leave> {puts "Leave .c"}
menu .m; .m add command -label Foo
.c bind 1 <1> {tk_popup .m %X %Y}

Left press on the X, leave the menu back onto the X,
and release the left button.

On Windows the issue can be provoked by replacing the
last two lines of the script above by:
toplevel .m -bg grey; wm overrideredirect .m 1; wm
withdraw .m
.c bind 1 <1> {wm geometry .m +%X+%Y; wm deiconify .m;
raise .m; grab .m}

Discussion

  • Sebastian Wangnick

    Logged In: YES
    user_id=202812

    The following patch seems to fix the problem. Whether it
    breaks other parts of the canvas semantics I don't know:
    *** tkCanvas.c.orig 2005-06-21 19:29:16.000000000 +0200
    --- tkCanvas.c 2005-10-15 22:22:05.000000000 +0200
    ***************
    *** 4647,4655 ****

    buttonDown = canvasPtr->state
    &
    (Button1Mask|Button2Mask|Button3Mask|Button4Mask|Button5Mask);
    - if (!buttonDown) {
    - canvasPtr->flags &= ~LEFT_GRABBED_ITEM;
    - }

    /*
    * Save information about this event in the canvas.
    The event in
    --- 4647,4652 ----
    ***************
    *** 4776,4782 ****
    * item was deleted.
    */
    }
    ! if ((canvasPtr->newCurrentPtr !=
    canvasPtr->currentItemPtr) && buttonDown) {
    canvasPtr->flags |= LEFT_GRABBED_ITEM;
    return;
    }
    --- 4773,4781 ----
    * item was deleted.
    */
    }
    ! if (!buttonDown) {
    ! canvasPtr->flags &= ~LEFT_GRABBED_ITEM;
    ! } else if (canvasPtr->newCurrentPtr !=
    canvasPtr->currentItemPtr) {
    canvasPtr->flags |= LEFT_GRABBED_ITEM;
    return;
    }

     
  • Sebastian Wangnick

    • assigned_to: hobbs --> mdejong
     
  • Sebastian Wangnick

    Second attempt to correct problem

     
  • Sebastian Wangnick

    Logged In: YES
    user_id=202812
    Originator: YES

    The patch posted 15-Oct-05 indeed breaks something else.
    When (L) on a canvas item is bound to pop up a menu, we get an leave event, but when releasing the mouse outside the menu on top of a different canvas item, $canvas find withtag current now returns the current AND the previous canvas item ids.

    Test script (Unix):
    pack [canvas .c]
    .c create text 50 50 -text X
    .c bind 1 <Enter> {puts "Enter 1 [.c find withtag current]"}
    .c bind 1 <Leave> {puts "Leave 1"}
    .c create text 50 60 -text Z
    .c bind 2 <Enter> {puts "Enter 2 [.c find withtag current]"}
    .c bind 2 <Leave> {puts "Leave 2"}
    bind .c <Enter> {puts "Enter .c"}
    bind .c <Leave> {puts "Leave .c"}
    menu .m; .m add command -label Foo
    .c bind 1 <1> {tk_popup .m %X %Y}

    Enter window, move onto right side of X, press <1>, leave menu back onto X, release <1>. Result:
    Enter window: Enter .c
    Move onto X: Enter 1 1
    Press <1>: Leave 1, Leave .c
    Move back onto X: -

    Now, original 8.4.5 behaviour on release <1>: Enter .c, Enter .c
    This is wrong, it should be Enter .c, Enter 1 1 (the other way around might also be acceptable)
    Behaviour 8.4.5 with patch 15-Oct-05 at release <1>: Enter 1 1, Enter .c, Enter .c
    This is better, as described (but also not perfect).

    But when releasing <1> on top of Z, the following happens:
    Original 8.4.5 behaviour: Leave 1, Enter 2 2, Enter .c, Enter .c
    Leave 1 is superfluous, but Ok ...
    Behaviour 8.4.5 with patch 15-Oct-05 at release <1>: Enter 2 1 2, Enter .c, Enter .c
    This is definitely not intended. .canvas find withtag current with the 15-Oct-05 patch suddenly returns TWO item ids.

    Another attempt to patch the problem is attached (patch2). This time the following happens:
    Release <1> over X: Enter 1 1, Enter .c, Enter .c
    This is as with the 15-Oct-06 patch.
    Release <2> over Z: Leave 1, Enter 2 2, Enter .c, Enter .c
    This is back to the original (acceptable) behaviour.

    Please can someone from the TCT team assess this correction. It is quite important for us, as we use the canvas item <Enter> and <Leave> events to control a highlight frame around accessible fields of the aircraft track labels on our air-traffic control display, and with the current Tk behaviour we might have ugly and distracting highlight frame artefacts staying on screen.
    File Added: patch2

     
  • Sebastian Wangnick

    Logged In: YES
    user_id=202812
    Originator: YES

    The patch posted 15-Oct-05 indeed breaks something else.
    When (L) on a canvas item is bound to pop up a menu, we get an leave event, but when releasing the mouse outside the menu on top of a different canvas item, $canvas find withtag current now returns the current AND the previous canvas item ids.

    Test script (Unix):
    pack [canvas .c]
    .c create text 50 50 -text X
    .c bind 1 <Enter> {puts "Enter 1 [.c find withtag current]"}
    .c bind 1 <Leave> {puts "Leave 1"}
    .c create text 50 60 -text Z
    .c bind 2 <Enter> {puts "Enter 2 [.c find withtag current]"}
    .c bind 2 <Leave> {puts "Leave 2"}
    bind .c <Enter> {puts "Enter .c"}
    bind .c <Leave> {puts "Leave .c"}
    menu .m; .m add command -label Foo
    .c bind 1 <1> {tk_popup .m %X %Y}

    Enter window, move onto right side of X, press <1>, leave menu back onto X, release <1>. Result:
    Enter window: Enter .c
    Move onto X: Enter 1 1
    Press <1>: Leave 1, Leave .c
    Move back onto X: -

    Now, original 8.4.5 behaviour on release <1>: Enter .c, Enter .c
    This is wrong, it should be Enter .c, Enter 1 1 (the other way around might also be acceptable)
    Behaviour 8.4.5 with patch 15-Oct-05 at release <1>: Enter 1 1, Enter .c, Enter .c
    This is better, as described (but also not perfect).

    But when releasing <1> on top of Z, the following happens:
    Original 8.4.5 behaviour: Leave 1, Enter 2 2, Enter .c, Enter .c
    Leave 1 is superfluous, but Ok ...
    Behaviour 8.4.5 with patch 15-Oct-05 at release <1>: Enter 2 1 2, Enter .c, Enter .c
    This is definitely not intended. .canvas find withtag current with the 15-Oct-05 patch suddenly returns TWO item ids.

    Another attempt to patch the problem is attached (patch2). This time the following happens:
    Release <1> over X: Enter 1 1, Enter .c, Enter .c
    This is as with the 15-Oct-06 patch.
    Release <2> over Z: Leave 1, Enter 2 2, Enter .c, Enter .c
    This is back to the original (acceptable) behaviour.

    Please can someone from the TCT team assess this correction. It is quite important for us, as we use the canvas item <Enter> and <Leave> events to control a highlight frame around accessible fields of the aircraft track labels on our air-traffic control display, and with the current Tk behaviour we might have ugly and distracting highlight frame artefacts staying on screen.
    File Added: patch2

     
  • Donal K. Fellows

    • priority: 5 --> 8
     
  • Nobody/Anonymous

    Logged In: NO

    Problem still exists in latest release: Tcl/Tk 8.5.1 (Feb 5, 2008)

     
  • Donal K. Fellows

    • priority: 8 --> 9
    • milestone: 503286 --> obsolete: 8.4.19
     
  • Don Porter

    Don Porter - 2008-04-16

    Logged In: YES
    user_id=80530
    Originator: NO

    I can confirm that "patch2" still
    applies to the tip of
    core-8-4-branch, and doesn't cause
    any new test failures on my test
    system. FWIW.

     
  • Donal K. Fellows

    Logged In: YES
    user_id=79902
    Originator: NO

    Staring hard at the code (as a non-expert), I notice that the move of the flag change later on means that an extra <Leave> event will be delivered, causing the previously current item to change. That seems to me to be the right idea, and the fact that it doesn't disturb the test suite means it's probably at least not horribly wrong! It'd be nice if we could have some kind of test for this sort of problem before we apply the fix, but I think this *probably* is a reasonable fix...

     
  • Don Porter

    Don Porter - 2008-04-17
     
  • Don Porter

    Don Porter - 2008-04-17

    Logged In: YES
    user_id=80530
    Originator: NO

    Here's the patch updated to the
    8.4.19 sources.
    File Added: 1327482.patch

     
  • Don Porter

    Don Porter - 2008-04-17

    Logged In: YES
    user_id=80530
    Originator: NO

    I withdraw my claim that the
    patch does not cause any new
    test failures.

    Not because I believe the patch
    introduces regressions. Only
    because I've been reminded that
    the results of running the Tk
    test suite are so damned random
    that it's near worthless as a
    tool for discovering regressions.

     
  • Don Porter

    Don Porter - 2008-04-17

    Logged In: YES
    user_id=80530
    Originator: NO

    ok, limiting to only those *.test
    files containing the [canvas] command,
    things are much more reliable. Six
    failures before; six after. All font
    related.

     
  • Don Porter

    Don Porter - 2008-04-17
    • assigned_to: mdejong --> dgp
    • status: open --> closed-accepted
     
  • Don Porter

    Don Porter - 2008-04-17

    Logged In: YES
    user_id=80530
    Originator: NO

    patch accepted for 8.4.19, 8.5.3 and 8.6

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks