[Rd] stuck tcltk scrollbars under Windows XP

Marc Schwartz mschwartz at medanalytics.com
Fri Jun 6 13:52:07 MEST 2003


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



More information about the R-devel mailing list