Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uwm.edu!lll-winken!sun-barr!decwrl!granite!basalt!pjs From: pjs@basalt.dec.com (Philip Schneider) Newsgroups: comp.windows.x Subject: Re: Help with double-click recognition. Message-ID: <647@granite.dec.com> Date: 1 Nov 89 17:45:22 GMT References: <8910191633.AA08710@dawn.crd.Ge.Com> <1989Oct31.230557.16809@antel.uucp> Sender: news@granite.dec.com Reply-To: pjs@basalt.DEC.COM (Philip Schneider) Organization: DEC Advanced Technology Development, Palo Alto, CA Lines: 50 As I was the original poster of the request for double-click recognition help, I feel it is my duty :-) :-) :-) to post a follow-up to all the follow-ups (is that grammatical?). Some of you may recall that I wanted to find a way to get an Athena widget to recognize double clicks. My "solution" at the time was to have my ButtonPress callback routine do a call to select with a timeout corresponding to the desired double-click interval, but it wasn't quite working as I wanted, for no apparent reason. I had used this technique relatively successfully in the past, in non-toolkit X programs, and was wondering what the problem was. A number of well-intended folks responded with things like "it isn't possible", "what about processes being swapped out", "problems with network latency", etc. This is b.s., as far as I'm concerned. I routinely work across an ethernet that is usually "maxed-out", and often using machines that are VERY heavily loaded. I've NEVER seen this to interfere with my double-click-recognition routine. Let's face it -- your basic human finger is a LOT slower than most computers and networks. In a heavily-loaded compute environment, one could just increase the threshhold interval. For all you know-it-alls out there, here's the problem -- I naively thought that the toolkit would make correct calls to XSelectInput for the window in question, only allowing events through that were specified in the various tables, etc. So, when I called "select", it would immediately return when that first up-click (i.e., ButtonRelease event) ocurred. Since the second ButtonPress would NOT be able to get into the queue by the time my routine checked it (maybe I'm slow, but MY finger can't move as fast as the CPU on my machine), the double-click was not recognized. There are several possible solutions to this -- for example, one could explicitly call XSelectInput on the window, and disallow ButtonRelease events, or make the recognition routine more sophisticated so that it dealt correctly with other sorts of events, etc. In fact, one could write a custom widget that would do this for you! Amazing, ain't it ??? I've recently been informed that the DECWindows toolkit does seem to correctly implement double-click recognition, so I don't think this is all my imagination. - Philip Schneider Philip J. Schneider | pjs@decwrl.dec.com DEC Advanced Technology Development | decwrl!pjs 100 Hamilton Avenue | (415)853-6538 Palo Alto, CA 94301 | (415)386-8232