Version 9 of Text Widget Bug

Updated 2005-06-09 10:05:38

MG, on June 8th 2005


Um, is this reported in the Tk Bug Tracker? http://sourceforge.net/tracker/?group_id=12997&atid=112997

MG I've just skimmed the list, and can't see it there, no. I'm not entirely sure it is actually a Tk bug, though - we're both running the same OS, and the same version of (Active)Tcl/Tk, but I can't get the problem on my computer, doing exactly the same thing he's doing. I'll do some more testing as suggested below, and see if I can replicate it any other way (either on this computer, or on his outside of this particular Tcl program), and see what I can find out...


Hey folks,

A friend of mine using a Tcl/Tk program I wrote (Potato MUSH (MUD) Client) seems to have found a bug in the Text widget, but it's one I can't to replicate (I'm using ActiveTcl 8.4.9). The text widget has a few modified bindings, but the only one which could be relevant to this is a new <MouseWheel> binding:

  bind Text <MouseWheel> {mouseWheel %W %X %Y %D}
  proc mouseWheel {w x y d} {

    set in [winfo containing -displayof $w $x $y]
    if { $in == "" || [winfo class $in] != "Text" } {
         $w yview scroll [expr {- ($d / 120) * 4}] units
       } else {
         $in yview scroll [expr {- ($d / 120) * 4}] units
       }
  };# mouseWheel

When he scrolls with the middle button (a wheel mouse), the display of the Text widget becomes, for lack of a better word, "screwy". A couple of screen shots (before and after scrolling) are below, along with some info on his computer / Tcl version.. if anyone has any ideas, about whether this is a bug in the Text widget or something in my code, I'd appreciate any help.

Mike

(My apologies for the huge images, btw - I didn't want to shrink them for risk of losing clarity)


escargo 8 Jun 2005 - Maybe you could build a test version and use event generate to simulate mousewheel movement and see if you can duplicate the problem.

MG Yeah, that's a good idea - can't think why it never occurred to me, now that you've said it :) I'll do some experimenting and see what I can find... There isn't a way to bind to any and all events, is there? I know you can, for instance, bind to <Key> for all keypress events, but I don't know of a catch-all binding (for the purposes of bind $textWidget <All> {puts %K} to see exactly what's firing).


 % set tcl_patchLevel
 8.4.9
 % set tk_patchLevel
 8.4.9
 % parray tcl_platform
 tcl_platform(byteOrder) = littleEndian
 tcl_platform(machine)   = intel
 tcl_platform(os)        = Windows NT
 tcl_platform(osVersion) = 5.1
 tcl_platform(platform)  = windows
 tcl_platform(user)      = The Master
 tcl_platform(wordSize)  = 4

Before:

http://www.talvo.com/textwidget/bugtst1.jpg

And after:

http://www.talvo.com/textwidget/bugtst2.jpg


Peter Newman 9 June 2005: From the bind manpage:-

  • %X - The x_root field from the event. If a virtual-root window manager is being used then the substituted value is the corresponding x-coordinate in the virtual root. Valid only for ButtonPress, ButtonRelease, KeyPress, KeyRelease, and Motion events.
  • %Y - The y_root field from the event. If a virtual-root window manager is being used then the substituted value is the corresponding y-coordinate in the virtual root. Valid only for ButtonPress, ButtonRelease, KeyPress, KeyRelease, and Motion events.

Doesn't this mean that %X and %Y aren't supported by the <MouseWheel> event?

MG Running wish and typing

 bind . <MouseWheel> {puts "%W %X %Y %D"}

into the console, it looks like it actually does. I moved the mouse around over '.', scrolling the mousewheel, and it printed to the console just what I expected:

 . 305 310 -360
 . 272 326 -360
 . 269 311 -360
 . 255 300 -360

I will get him to try and recreate the problem without the modified <MouseWheel> binding as soon as I see him, though, and see if he still sees the problem.