- The <Unmap> binding isn't fired when the popup dissapears, which includes when the user doesn't select one of the menu items.
- All processing of the script stops as soon as the popup is displayed. The script continues where it left off after the popup dissapears.
- Here the <Unmap> binding actually gets fired when the popup dissapears.
- Processing of the script continues after the popup is shown. The rest of the script doesn't wait for the popup to dissapear.
set noob [label .noob -text noob -bg purple -fg red]
pack $noob
set t [text .t -height 20 -width 70 -wrap none]
pack $t -fill both -expand 1
proc ins {msg} {
global t
$t insert end \
"[clock format [clock seconds] -format %T] $msg\n"
}
set m [menu .m -tearoff 0]
$m add command \
-label Party! \
-command [list ins "Noob Party!"] \
-underline 0
bind $noob <Button-3> [list showpopup %X %Y]
proc showpopup {X Y} {
global m t
tk_popup $m $X $Y
ins "script resumes now after tk_popup command..."
return
}So how do I fix this!?Pretty simple. Well umm it took me a while to figure it though ;)So I want the item that was right-clicked on to stay hilited when showing the popup. If the mouse moves over any other item, I don't want the hilited item to change. This is because the user doesn't remember what item was clicked on -- jeez, I am the user and I can't remember much for long!So here's the algo:The item gets right clicked:- Hilite that item and suspend hiliting (use a namespace'd bool).
- On windows, you just need to re-enable hiliting after the tk_popup command. But wait! On unix you can't do that, since as soon as the popup is shown, tk_popup returns! So for unix, you bind to <Unmap> and re-enable hiliting in the binded proc.
LV a note recently posted on comp.lang.tcl suggests that if you no longer want the native behavior, you could rename the command and then source in the Tcl script implementing the Unix behavior. Some people prefer to have cross platform identical look and feel and behavior, while others prefer the native approach, even when it means that things don't work the same across platforms.Vince: surely the fact that the 'unmap' binding isn't called is simply a bug in WinTk and should be reported on sourceforge so a maintainer can perhaps fix it...Ro: Yeah, I agree, the <Unmap> event really should be fired on Windows. But thats not the only difference. Witness how in unix the script continues after the popup is shown, which is not what happens in Windows.Vince: and that indeed is another bug (at the very least it should be documented as a platform-difference, and preferably fixed for consistency). Please do report these problems a bugs to the tktoolkit project on sourceforge.Ro: July 22, 2002 - Done [2]. Thanks Vince.
Schnexel
#!/usr/bin/wish -f
#!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
# tk_popup at <ButtonPress-1> eats <ButtonRelease-1> !!!!
# tk8.4, tested at 2 Linux boxes !!!!
#!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
canvas .cv -height 200 -width 200
.cv create rectangle 1 1 200 200 -fill red
pack .cv -fill both -expand yes
#Variant1:
.cv bind all <ButtonPress-1> {puts <ButtonPress-1>; create_menu %X %Y}
.cv bind all <ButtonRelease-1> {puts {<ButtonRelease-1> never put}}
#Variant2: (same Problem)
#bind .cv <ButtonPress-1> {puts <ButtonPress-1>; create_menu %X %Y}
#bind .cv <ButtonRelease-1> {puts {<ButtonRelease-1> never put}}
#Variant3: (same Problem)
#.cv bind all <ButtonPress-1> {puts <ButtonPress-1>; create_menu %X %Y}
#bind .cv <ButtonRelease-1> {puts {<ButtonRelease-1> never put}}
#Variant4: (same Problem)
#bind .cv <ButtonPress-1> {puts <ButtonPress-1>; create_menu %X %Y}
#.cv bind all <ButtonRelease-1> {puts {<ButtonRelease-1> never put}}
proc create_menu {X Y} {
puts "Creating the menu"
catch { destroy .cv.m }
menu .cv.m -tearoff 1
.cv.m add command -label "Something" -command "puts Something"
tk_popup .cv.m $X $Y
puts "Menu popped up"
#... and <ButtonRelease-1> gone
}