From jfox at mcmaster.ca  Fri Jun  6 13:29:15 2003
From: jfox at mcmaster.ca (John Fox)
Date: Fri Jun  6 18:29:32 2003
Subject: [Rd] stuck tcltk scrollbars under Windows XP
In-Reply-To: <x2vfvjbc3t.fsf@biostat.ku.dk>
References: <i301evkt8c708e0j4mh9s0fuev4so7r29t@4ax.com>
	<5.1.0.14.2.20030606072039.01ed78a0@mcmail.cis.mcmaster.ca>
	<i301evkt8c708e0j4mh9s0fuev4so7r29t@4ax.com>
Message-ID: <5.1.0.14.2.20030606122243.01ea4848@mcmail.cis.mcmaster.ca>

Dear Peter,

At 02:54 PM 6/6/2003 +0200, Peter Dalgaard BSA wrote:
>Duncan Murdoch <dmurdoch@pair.com> 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: jfox@mcmaster.ca
phone: 905-525-9140x23604
web: www.socsci.mcmaster.ca/jfox


[Rd] stuck tcltk scrollbars under Windows XP
John Fox