R devel - Jun 2003 - stuck tcltk scrollbars under Windows XP

Dear R-devel list members,

I've encountered a problem with my Rcmdr package under Windows XP and could 
use some advice:

The Rcmdr package uses the tcltk package to create menus and dialog boxes. 
My standard procedure when a dialog is created is to grab the focus -- e.g., by

     tkfocus(top)
     tkgrab(top)

(Here, top is a top-level window -- say, containing one or more 
scrollbars.) When the window is closed, I release the focus, destroy the 
window, and return the focus to another window -- e.g.,

     tkgrab.release(top)
     tkdestroy(top)
     . . .
     tkfocus(.commander)

(Here .commander is a top-level window residing in the global environment.)

This procedure works fine under Windows 2000 -- where I've done most of the 
testing of the Rcmdr package under Windows -- but I received a report of a 
problem from a Windows XP user, who noted that scrollbars tend to get 
stuck. I was able to reproduce the problem intermittently on an XP system, 
and found that the problem appears to go away when I remove the calls to 
tkgrab() and tkgrab.release().

You can test for the problem with the following code:

     window1 <- tktoplevel()
     window2 <- tktoplevel()
     xFrame <- tkframe(window2)
     xScroll <- tkscrollbar(xFrame, repeatinterval=5, command=function(...) 
tkyview(xBox, ...))
     xBox <- tklistbox(xFrame, height=4,
         selectmode="single", background="white",
exportselection="FALSE",
         yscrollcommand=function(...) tkset(xScroll, ...))
     for (x in letters) tkinsert(xBox, "end", x)
     onOK <- function() {
         tkgrab.release(window2)
         tkfocus(window1)
         tkdestroy(window2)
         }
     OKbutton <- tkbutton(window2, text="OK", width="12",
command=onOK,
default="active")
     tkgrid(xBox, xScroll, sticky="nw")
     tkgrid.configure(xScroll, sticky="ns")
     tkgrid(xFrame, sticky="w")
     tkgrid(OKbutton, sticky="w")
     tkselection.set(xBox, 0)
     tkbind(window2, "<Return>", onOK)
     tkfocus(window2)
     tkgrab(window2)

I find that I can make the scrollbar stick under Windows XP by repeatedly 
and rapidly pressing the scroll-down button. As mentioned, removing the 
calls to tkgrab() and tkgrab.release() seems to eliminate the problem.

I wonder whether anyone else has encountered this problem or has any 
insight into its source. Am I doing something wrong here? I could simply 
remove the calls to tkgrab() and tkgrab.release() throughout the package, 
or make them optional, perhaps checking for Windows XP via
shell("ver",
intern=TRUE)[2], but I'd rather solve the problem.

I've also had a report of tk windows failing to stay on top of the R-GUI 
SDI Console in Windows XP, but I haven't been able to duplicate this 
problem, and it has never occurred in my testing under Windows 2000 and 
Linux. Has anyone else experienced this behaviour?


Thanks,
  John
-----------------------------------------------------
John Fox
Department of Sociology
McMaster University
Hamilton, Ontario, Canada L8S 4M4
email: jfox@mcmaster.ca
phone: 905-525-9140x23604
web: www.socsci.mcmaster.ca/jfox

On Fri, 06 Jun 2003 07:23:27 -0400, you wrote:
>
>You can test for the problem with the following code:
...
>I find that I can make the scrollbar stick under Windows XP by repeatedly 
>and rapidly pressing the scroll-down button. 
I can reproduce it easily in XP in yesterday's 1.7.1 beta.
>I wonder whether anyone else has encountered this problem or has any 
>insight into its source.
I don't know TCL/TK well enough to know what tkgrab does in Windows
terms, but the general symptoms look as though events are being
missed.  When you click on something messages are generated for
mouse-down and mouse-up events; it looks as though some mouse-up
messages are being lost.
>I've also had a report of tk windows failing to stay on top of the R-GUI
>SDI Console in Windows XP, but I haven't been able to duplicate this 
>problem, and it has never occurred in my testing under Windows 2000 and 
>Linux. Has anyone else experienced this behaviour?
TK gets lost behind the MDI main window, but I haven't seen this yet
with SDI.  I haven't done a lot of testing, though...

Duncan Murdoch

>-----Original Message-----
>From: r-devel-bounces@stat.math.ethz.ch 
>[mailto:r-devel-bounces@stat.math.ethz.ch] On Behalf Of John Fox
>Sent: Friday, June 06, 2003 6:23 AM
>To: r-devel@stat.math.ethz.ch
>Subject: [Rd] stuck tcltk scrollbars under Windows XP
>
>
>Dear R-devel list members,
>
>I've encountered a problem with my Rcmdr package under Windows 
>XP and could 
>use some advice:
>
>The Rcmdr package uses the tcltk package to create menus and 
>dialog boxes. 
>My standard procedure when a dialog is created is to grab the 
>focus -- e.g., by
>
>     tkfocus(top)
>     tkgrab(top)
>
>(Here, top is a top-level window -- say, containing one or more 
>scrollbars.) When the window is closed, I release the focus, 
>destroy the 
>window, and return the focus to another window -- e.g.,
>
>     tkgrab.release(top)
>     tkdestroy(top)
>     . . .
>     tkfocus(.commander)
>
>(Here .commander is a top-level window residing in the global 
>environment.)
>
>This procedure works fine under Windows 2000 -- where I've 
>done most of the 
>testing of the Rcmdr package under Windows -- but I received a 
>report of a 
>problem from a Windows XP user, who noted that scrollbars tend to get
>stuck. I was able to reproduce the problem intermittently on 
>an XP system, 
>and found that the problem appears to go away when I remove 
>the calls to 
>tkgrab() and tkgrab.release().
>
>You can test for the problem with the following code:
>
>     window1 <- tktoplevel()
>     window2 <- tktoplevel()
>     xFrame <- tkframe(window2)
>     xScroll <- tkscrollbar(xFrame, repeatinterval=5, 
>command=function(...) 
>tkyview(xBox, ...))
>     xBox <- tklistbox(xFrame, height=4,
>         selectmode="single", background="white", 
>exportselection="FALSE",
>         yscrollcommand=function(...) tkset(xScroll, ...))
>     for (x in letters) tkinsert(xBox, "end", x)
>     onOK <- function() {
>         tkgrab.release(window2)
>         tkfocus(window1)
>         tkdestroy(window2)
>         }
>     OKbutton <- tkbutton(window2, text="OK",
width="12",
>command=onOK, 
>default="active")
>     tkgrid(xBox, xScroll, sticky="nw")
>     tkgrid.configure(xScroll, sticky="ns")
>     tkgrid(xFrame, sticky="w")
>     tkgrid(OKbutton, sticky="w")
>     tkselection.set(xBox, 0)
>     tkbind(window2, "<Return>", onOK)
>     tkfocus(window2)
>     tkgrab(window2)
>
>I find that I can make the scrollbar stick under Windows XP by 
>repeatedly 
>and rapidly pressing the scroll-down button. As mentioned, 
>removing the 
>calls to tkgrab() and tkgrab.release() seems to eliminate the
problem.
>
>I wonder whether anyone else has encountered this problem or has any 
>insight into its source. Am I doing something wrong here? I 
>could simply 
>remove the calls to tkgrab() and tkgrab.release() throughout 
>the package, 
>or make them optional, perhaps checking for Windows XP via 
>shell("ver", 
>intern=TRUE)[2], but I'd rather solve the problem.
>
>I've also had a report of tk windows failing to stay on top of 
>the R-GUI 
>SDI Console in Windows XP, but I haven't been able to duplicate this 
>problem, and it has never occurred in my testing under Windows 
>2000 and 
>Linux. Has anyone else experienced this behaviour?
>
>
>Thanks,
>  John

Professor Fox,

I can duplicate the scroll bar problem on WinXP Pro using R 1.7.1
Beta.

Try modifying the final lines in your code to the following and see if
it works under Win2k:

...
tkbind(window2, "<Return>", onOK)

# Here is the change
tkwm.deiconify(window2)
tkgrab.set(window2)
tkfocus(xBox)
tkwait.window(window2)

Using the above code, I seem to have eliminated the scroll bar
problem. This is the approach that I took with the tkSelectList()
function which I sent to you during our offline exchange.

Note that I have tkfocus() set to the scrollbar xBox and not to
window2, which results in the mouse scroll wheel working, whereas it
does not when the focus is set to window2.

Lastly, by using the tkwm.deiconify(...) function window2 is raised to
obtain focus.  That was a quirk that I found by experimentation.

HTH,

Marc Schwartz

SNIP
>...
>tkbind(window2, "<Return>", onOK)
>
># Here is the change
>tkwm.deiconify(window2)
>tkgrab.set(window2)
>tkfocus(xBox)
>tkwait.window(window2)
>
>Using the above code, I seem to have eliminated the scroll bar
>problem. This is the approach that I took with the tkSelectList()
>function which I sent to you during our offline exchange.
>
>Note that I have tkfocus() set to the scrollbar xBox and not to
>window2, which results in the mouse scroll wheel working, whereas it
>does not when the focus is set to window2.
>
>Lastly, by using the tkwm.deiconify(...) function window2 is raised
to
>obtain focus.  That was a quirk that I found by experimentation.

Quick correction:

The sentence in the paragraph above should read:

"Note that I have tkfocus() set to the **ListBox** xBox..."

Sorry for any confusion.

Marc

Dear Duncan,

Thanks for the confirmation. I assume that the scrollbar problem went away 
when the calls to tkgrab() and tkgrab.release() were removed. Is that right?

Regards,
  John

At 07:58 AM 6/6/2003 -0400, Duncan Murdoch wrote:
>On Fri, 06 Jun 2003 07:23:27 -0400, you wrote:
>
> >
> >You can test for the problem with the following code:
>...
> >I find that I can make the scrollbar stick under Windows XP by
repeatedly
> >and rapidly pressing the scroll-down button.
>
>I can reproduce it easily in XP in yesterday's 1.7.1 beta.
>
> >I wonder whether anyone else has encountered this problem or has any
> >insight into its source.
>
>I don't know TCL/TK well enough to know what tkgrab does in Windows
>terms, but the general symptoms look as though events are being
>missed.  When you click on something messages are generated for
>mouse-down and mouse-up events; it looks as though some mouse-up
>messages are being lost.
>
> >I've also had a report of tk windows failing to stay on top of the
R-GUI
> >SDI Console in Windows XP, but I haven't been able to duplicate
this
> >problem, and it has never occurred in my testing under Windows 2000 and
> >Linux. Has anyone else experienced this behaviour?
>
>TK gets lost behind the MDI main window, but I haven't seen this yet
>with SDI.  I haven't done a lot of testing, though...
>
>Duncan Murdoch
-----------------------------------------------------
John Fox
Department of Sociology
McMaster University
Hamilton, Ontario, Canada L8S 4M4
email: jfox@mcmaster.ca
phone: 905-525-9140x23604
web: www.socsci.mcmaster.ca/jfox