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
~~~~~~~~~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
