Re: [Rd] misbehaviour of some tk windows, R 2.6.0 on SUSE 10.1?

From: Peter Dalgaard <>
Date: Tue, 09 Oct 2007 22:31:45 +0200

Peter Dalgaard wrote:
> David Firth wrote:
>> I don't know whether this is specific to (my installation
>> of) SUSE 10.1, or is more general.
>> With R 2.6.0, I am finding that some widgets made through
>> the tcltk package are having problems which become evident
>> through scrollbar activity. An example is demo(tkfaq) --
>> see below. To reproduce the problem, I do the following:
>> after the tk window appears, hold down the "scroll-down"
>> tab at the foot of the window for a few seconds, then
>> release. If scrolling stops (as it should, if all is
>> working correctly), do the same thing again. Repeating
>> this 2 or 3 times usually results in uncontrolled
>> (unstoppable) scrolling activity; and closing the window
>> when that happens delivers the errors that appear in the
>> transcript below.
>> My R 2.6.0 was built on my own system,
>> OS: SUSE linux 10.1
>> tcl: 8.4.12-14
>> tk: 8.4.12-14
>> gcc: 4.1.0-25
>> Since I had not seen this behaviour with previous versions
>> of R, I did a check with R 2.5.1: a fresh build today of R
>> 2.5.1 on the same system does not appear to have the same
>> problem.
>> Any ideas? Is anyone else seeing this behaviour?
>> David
> Looks a bit nasty. I see it on SUSE 10.2 as well. Increasing the
> repeatinterval setting for the scrollbar helps, but even at a setting of
> 50, I still see the effect. It is usually stoppable with the middle
> button over the trough.
> The error message is what you'd expect from killing a window while
> something is trying to talk to widgets inside of it. The details of the
> popup dialog is a little more informative:
> while executing
> "$w cget -repeatinterval"
> (procedure "tk::ScrollSelect" line 12)
> invoked from within
> "tk::ScrollSelect .3.2 arrow2 again"
> ("after" script)
> I think there's a clue in there. It has the hallmarks of a race
> condition: As I understand it the autorepeat feature runs an "after"
> script which effectively presses the arrow again 5 ms later, invoking
> another "after" script, etc. A button release is supposed to kill the
> after script, but it might not do so in time, in which case it may try
> to kill something that already died, etc.
> Can't offhand see that we did anything to the event loop that could
> cause this, though.
Exactly the same behaviour on Fedora 7. Looping scrolling with 2.6.0+, no probs with 2.5.1.

Can probably eliminate OS issues and hardware then (2x3.2GHz, 64 bit SUSE vs. 600MHz, 32bit Fedora). Argh....

   O__  ---- Peter Dalgaard             Ă˜ster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics     PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark          Ph:  (+45) 35327918
~~~~~~~~~~ - (                  FAX: (+45) 35327907

______________________________________________ mailing list
Received on Tue 09 Oct 2007 - 20:46:13 GMT

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Thu 25 Oct 2007 - 11:37:10 GMT.

Mailing list information is available at Please read the posting guide before posting to the list.