[Rd] stuck tcltk scrollbars under Windows XP

[John Fox]

Dear Mark,

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,
  John

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:
> >>SNIP
> >>
> >> >...
> >> >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
>
>
>Prof. Fox,
>
>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
>continuing processing.
>
>
>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.
>
>Best regards,
>
>Marc

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