At 02:54 PM 6/6/2003 +0200, Peter Dalgaard BSA wrote:
Duncan Murdoch <[EMAIL PROTECTED]> writes:
> On Fri, 06 Jun 2003 07:23:27 -0400, you wrote: > > > > >You can test for the problem with the following code: > ... > >I find that I can make the scrollbar stick under Windows XP by repeatedly > >and rapidly pressing the scroll-down button. > > I can reproduce it easily in XP in yesterday's 1.7.1 beta. > > >I wonder whether anyone else has encountered this problem or has any > >insight into its source. > > I don't know TCL/TK well enough to know what tkgrab does in Windows > terms, but the general symptoms look as though events are being > missed. When you click on something messages are generated for > mouse-down and mouse-up events; it looks as though some mouse-up > messages are being lost.
We have an old issue on Windows which I haven't had the stamina to dig into: On Unix, all Tcl event handling is keyed to the keyboard loop. On Windows, we run a check for Tcl events "every once in a while".
I think it was Brian that implemented the Windows version and it seemed like a good idea at the time. However, it breaks some things where Tcl/Tk tends to assume atomic processing. E.g., this is behind the code in the tkfaq demo (and elsewhere):
txt <- tktext(tt, bg="white", font="courier") scr <- tkscrollbar(tt, repeatinterval=5, command=function(...)tkyview(txt,...)) ## Safest to make sure scr exists before setting yscrollcommand tkconfigure(txt, yscrollcommand=function(...)tkset(scr,...))
Where the point is that the text widget will otherwise generate an event which results in a call to tkset(scr,...), possibly before scr exists.
In a Tcl script, there is no problem with this and the preferred idiom is actually
text .tt.txt -command {set .tt.scr} scrollbar .tt.scr -command {yview .tt.txt}
(although you can't run them like that individually on the wish command line for the same reason as above).
I.e. Tcl scripts generally expect to run to completion before event processing takes place. You could be bumping into something similar in the function that calls tkgrab.
I've habitually defined scrollbars before the corresponding text boxes, but I suppose that the reverse problem (the scrollbar referring to the box before it exists) could occur. I don't seem to have encountered that problem, however.
Why should this problem arise with tkgrab? I don't issue the call to tkgrab until the whole window is defined. As well, I find it curious that the problem only seems to surface in Windows XP.
I wish that we could all forget about trying to get everything to work under Windows, except that nearly 100% of the people I deal with use it. If no better solution materializes, I'll set an option to suppress the calls to tkgrab and tkrelease. Does that seem reasonable?
By the way, thank you again for the wonderful tcltk package.
Regards, John
----------------------------------------------------- John Fox Department of Sociology McMaster University Hamilton, Ontario, Canada L8S 4M4 email: [EMAIL PROTECTED] phone: 905-525-9140x23604 web: www.socsci.mcmaster.ca/jfox
______________________________________________ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
