[Rd] stuck tcltk scrollbars under Windows XP
jfox at mcmaster.ca
Fri Jun 6 16:38:56 MEST 2003
After some experimentation, I found that the crucial change appears to be
the call to tkwait.window. When I include this, the problem of sticking
scrollbars in Windows XP seems to go away. Since the dialogs with
scrollbars are always waiting for the user to press the OK or Cancel button
to dismiss the dialog, using tkwait.window seems fine.
The call to tkwm.deiconify also appears to raise the dialog window more
reliably, as you suggest.
In the absence of another solution, I'll bite the bullet and modify all of
the dialogs in Rcmdr along these lines.
Thanks for your help,
At 12:52 PM 6/6/2003 -0500, Marc Schwartz wrote:
> >-----Original Message-----
> >From: John Fox [mailto:jfox at mcmaster.ca]
> >Sent: Friday, June 06, 2003 11:31 AM
> >To: mschwartz at medanalytics.com
> >Cc: r-devel at stat.math.ethz.ch
> >Subject: RE: [Rd] stuck tcltk scrollbars under Windows XP
> >At 09:03 AM 6/6/2003 -0500, Marc Schwartz wrote:
> >> >...
> >> >tkbind(window2, "<Return>", onOK)
> >> >
> >> ># Here is the change
> >> >tkwm.deiconify(window2)
> >> >tkgrab.set(window2)
> >> >tkfocus(xBox)
> >> >tkwait.window(window2)
> >> >
> >Dear Marc,
> >Thank you for the suggestions -- I'll try them out. I'd prefer to
> >understand why things work as they do, for fear of introducing other
> >problems. Focusing on the list box won't work for me, I think,
> >since many
> >of the Rcmdr dialogs have more than one list box.
> >Thanks again,
> > John
>Glad to be of help, if indeed the above is of help. I am certainly in
>agreement that I prefer to understand why things do what they do.
>The resultant approach that I took in the tkSelectList() function I
>wrote was through some trial and error using Peter's article from R
>News (http://cran.r-project.org/doc/Rnews/Rnews_2001-3.pdf), Practical
>Programming in Tcl and Tk by Welch and Effective Tcl/Tk Programming by
>Harrison and McLennan.
>What I found was perhaps biased by some quirks and perhaps differences
>in the way in which the various window managers seem to work (ie.
>between WinXP and RH 8.0/9).
>I believe that the above modifications work in this situation given
>the following considerations:
>1. The use of tkwm.deiconify(window2) makes the window immediately
>available ("raises it") for interaction once the grab/focus is set.
>Lacking this command (even with the grab set) required me to actually
>click on the ListBox window in order for it to respond to events. This
>occurred even though it was already visually "on top" of all other
>windows on the screen.
>2. The use of tkfocus(xBox) instead of tkfocus(window2) is simply a
>choice in this case, since the initial object being interacted with is
>the ListBox. If you have more than one bound object in a window (ie.
>several ListBoxes, buttons, etc.), you can toggle/cycle between them
>with the TAB key. In that case, each object in sequence gains focus
>and the default bindings for the object are enabled.
>3. The use of tkwait.window(window2) seems to provide an enhanced
>level of priority in the processing of event signals. Presuming that
>you are waiting for the user to either make a selection or clear/close
>the ListBox window, this seems a reasonable approach. You would not
>likely want to use this function in the case of a window that is to be
>retained, since this call waits for the window to be destroyed before
>Not sure if that provides sufficient justification for the approach
>that I took, but it does seem to work under two different OS's and two
>different window managers, the latter of which seems to introduce a
>level of variability in behavior.
Department of Sociology
Hamilton, Ontario, Canada L8S 4M4
email: jfox at mcmaster.ca
More information about the R-devel