Implementing higher-order clicks

re: Implementing higher-order clicks

Carlos — Mon, 18 Oct 2004 14:31:00 GMT

This is nit-picking, but I don't like the hit-test rectangle because it's not symmetrical around the starting point, and the code is broken when SM_CXDOUBLECLK==1. (Even if this can't happen in practice, it's still scruffy.) You can fix both problems by inflating a 1x1 rectangle rather than an empty rectangle.

re: Implementing higher-order clicks

anonymouse — Mon, 18 Oct 2004 15:05:00 GMT

A more important question would be:

"Does Raymond Chen know everything!"

re: Implementing higher-order clicks

asdf — Mon, 18 Oct 2004 15:32:00 GMT

Windows doesn't make sure it's an even number (hell, it doesn't even make sure it's a positive number) in the call to SystemParametersInfo.

re: Implementing higher-order clicks

Chris Becke — Mon, 18 Oct 2004 15:36:00 GMT

Raymond Chen forgot to make his rect bottom right exclusive? Ha, that sounds like a much needed blog entry. Dealing with bottom right exclusive rects in Win32 :)

re: Bottom Right Exclusive Rects

Steve Thresher — Mon, 18 Oct 2004 15:43:00 GMT

Is this what you wanted http://weblogs.asp.net/oldnewthing/archive/2004/02/18/75652.aspx

re: Implementing higher-order clicks

Chris Becke — Mon, 18 Oct 2004 15:50:00 GMT

hmmm. isn't that ironic.

re: Implementing higher-order clicks

Matthew Riley — Mon, 18 Oct 2004 15:55:00 GMT

g_rcClick is of indeterminate value the first time through this function and is passed to PtInRect before initialized... might this pose a problem?

re: Implementing higher-order clicks

Merle — Mon, 18 Oct 2004 15:55:00 GMT

Why in the name of all that is sacred would you want to use *triple* clicks in an application?

Yes, I understand Word has some magic selection behaviour where the more you click the more text is selected. But I still don't think that's a good idea. I would much rather have that sort of thing in a context menu where you can select. It feels more like a "wow, this is so cool that I can detect this, let's give it some random functionality" thing to me.

Unless you have a trackball (or glidepoint and use the buttons) it's really hard to click multiple times without moving the mouse.

re: Implementing higher-order clicks

Raymond Chen — Mon, 18 Oct 2004 16:10:00 GMT

1. Yes, the rectangle is asymmetric, but that's how Windows has worked since 1983 and the goal here is to emulate the behavior not to fix it.

2. asdf: I meant that the Windows control panels enforce the even-ness, not the API.

3. Matthew: One of the subtleties of the code is that it doesn't matter what g_rcClick is initialized to.

re: Implementing higher-order clicks

Nicholas Allen — Mon, 18 Oct 2004 16:43:00 GMT

Merle-

Your browser probably supports triple clicking as well. In Netscape it selects the line while in IE it selects the paragraph.

re: Implementing higher-order clicks

Merle — Mon, 18 Oct 2004 16:45:00 GMT

Ha! You're right. Even if the click happens to be within the uninitialized g_rcClick, and if by wild happenstance g_tmLastClick is close to what GetMessageTime() returns (another uninitialized variable), it's a NOOP the first time through.

Tricky.

I'd feel safer initializing the RECT, though. ;-)

re: Implementing higher-order clicks

Merle — Mon, 18 Oct 2004 16:48:00 GMT

Nicholas: hmm, you're right. Even though Opera 5 pops up a contexty menu on double click, continued clicking selects text much as in Word. Never noticed. (never tried, actually) Three clicks gives you text between punctuation (oddly stopping at the comma), four the paragraph.

But I maintain my initial question: why do you want that?

Especailly since it's not consistent between apps...

re: Implementing higher-order clicks

Nicholas Allen — Mon, 18 Oct 2004 17:03:00 GMT

Merle-

Well, it's mostly because you can't just shove everything into a context menu. Usability studies have shown that small, consistent context menus are the best way to go. So rarely used features get pushed to more obscure trigger combinations. At some point they should be dropped entirely but then you'd get nasty letters by the three people that use the feature all the time.

re: Implementing higher-order clicks

Smeghead — Mon, 18 Oct 2004 17:13:00 GMT

Apple has it right, Microsoft has it wrong.

This just in, Water is wet, the sky is blue.

re: Implementing higher-order clicks

Anon — Mon, 18 Oct 2004 17:20:00 GMT

Shouldn't:

tmClick - g_tmLastClick >= GetDoubleClickTime()) {

be:

tmClick - g_tmLastClick > GetDoubleClickTime()) {

re: Implementing higher-order clicks

Raymond Chen — Mon, 18 Oct 2004 17:36:00 GMT

Anon: Yup, good catch. Fortunately this is undetectable in practice since no human being can do things to 1ms precision anyway.

re: Implementing higher-order clicks

Henk Devos — Mon, 18 Oct 2004 18:04:00 GMT

Smeghead: Why does Apple get it right and Microsoft wrong?
I just tested on Safari and IE:Mac.
On Safari, 1 click is positioning the cursor, 2 clicks is selecting a word, 3 clicks is selecting a line.
In IE:Mac, this behavior is the same, except that 4 clicks is selecting a paragraph. They are compatible, while offering an extra option that is more useful than selecting a line.
I think Microsoft got it right and Apple got it wrong.

re: Implementing higher-order clicks

Smeghead — Mon, 18 Oct 2004 18:56:00 GMT

Not according to the users I have to HELP. ITs always confusion between LEFT or RIGHT and single nad double click. So yes, Apple (or xerox) got it right numbnuts.

Make sure you understand this

Alan De Smet — Mon, 18 Oct 2004 20:06:00 GMT

I understand that GetMessageTime's return value occasionally wraps around to 0. But I'm not entirely clear on how your suggestion is better.

The wrong answer is:

tmClick > g_tmLastClick + GetDoubleClickTime()

As far as I can tell, this will actually work in practice. Everyone should get
promoted to LONG. GetMessageTime rolls over based on MAXLONG. So
(g_tmLastClick+GetDoubleClickTime()) should roll over in matching behavior.
That said, relying on roll over and generally overflowing variables is A Bad
Idea, so it's wrong. Am I correct so far?

The right answer is apparently:

tmClick - g_tmLastClick > GetDoubleClickTime()

However, if GetMessageTime rolled over, we've still got problems. tmClick will be small, g_tmLastClick will be very large. (tmClick-g_tmLastClick) will be massively negative and will never trigger. As far as I can tell any click over the rollover boundary will register as double/triple/whatever click.

This leads me to conclude that I need to do something like so (code untested):

LONG clickDelta = tmClick - g_tmLastClick;
if ( tmClick < g_tmLastClick) {
clickDelta += MAXLONG;
}

I suspect I'm overlooking something and would appreciate knowing what.

(Oh, and thanks for the blog, it's fascinating reading.)

re: Implementing higher-order clicks

Raymond Chen — Mon, 18 Oct 2004 20:12:00 GMT

Everything gets promoted to DWORD, not LONG. Does that help? (Hint: What if g_tmLastClick = 0xFFFFFFFF - GetDoubleClickTime()?)

re: Implementing higher-order clicks

A non anon — Mon, 18 Oct 2004 21:53:00 GMT

Uhm. None of the g_* variables in the sample code are uninitialized, since global variables are zero-initialized.

nedit

Johan Thelin — Tue, 19 Oct 2004 05:00:00 GMT

The lovely editor nedit uses multiple clicks in a great way. Single click moves the carret, double click selects a line, tripple click selects a paragraph and, if I'm not missremembering, quadruple(!) click selects the entire document. Quite handy actually :)

re: Implementing higher-order clicks

muro — Tue, 19 Oct 2004 05:35:00 GMT

OK, this is nitpicking, but anyway:
shouldn't there be another line at the end?
HANDLE_MSG(hwnd, WM_RBUTTONDOWN, OnRButtonDown);

a pleasure to read this stuff.

re: Implementing higher-order clicks

Raymond Chen — Tue, 19 Oct 2004 05:37:00 GMT

Extending to right-clicks is left as an exercise.

re: Implementing higher-order clicks

muro — Tue, 19 Oct 2004 05:38:00 GMT

The missing line is actually funny, when you read second paragraph from the end of the article - especially the parenthesis. :-)
but sorry for nitpicking, its lame.

re: Implementing higher-order clicks

Raymond Chen — Tue, 19 Oct 2004 05:40:00 GMT

Oh, you're right. I forgot what I wrote. (I wrote it so long ago.)

re: Implementing higher-order clicks

Cyrus Najmabadi — Tue, 19 Oct 2004 07:06:00 GMT

Ugh, you had to write the code for this now after i spent a good half day getting this working right in some code i was writing. What's worse is that you're the one who told me how to do it, but you weren't willing to take the time to write this up :-P

Oh, and to those of you who are interested this was to add a feature in C# where as you click more and more we start selecting more and more of the C# code you've written based on the parse tree.

So we'll start by selecting the expression, then the statement, the then method, then the class, namespace, etc. Basically each successive click selects one higher level in the parse tree.

it's a feature you grow to love :-)

re: Implementing higher-order clicks

krisztian pinter — Tue, 19 Oct 2004 07:30:00 GMT

i still not get that DoubleClickTime trick

say
g_tmLastClick == ~4bil
tmClick == 10

now 10 - ~4bil is a large number because of the overflow. it will treated as a double. OK.

but

g_tmLastClick == ~4bil
tmClick == 60000 (click one minute later)

60000 - ~4bil is still a large number, so it will also be treated as double, however it is clearly a single.

can someone explain this to me?

re: Implementing higher-order clicks

muro — Tue, 19 Oct 2004 09:07:00 GMT

To clarify: consider, the difference calculation is correct:
tmClick - g_tmLastClick really calculates the time difference between the clicks correctly for our purpose, even when an overflow happens.

First, lets show the overflow calculations with 8bits. GetDoubleClickTime() = 0x10:
0x01 - 0xff = 0x01 + ~(0xff) = 0x01 + (0x100 - 0xff) = 0x01 + 0x01 = 0x02 -> double click
0x21 - 0xff = 0x21 + ~(0xff) = 0x21 + (0x100 - 0xff) = 0x21 + 0x01 = 0x22 -> single click

Then the same for 32bit:
GetDoubleClickTime() = 10:
g_tmLastClick == 4bil = e.g.: 2^32 - 10
tmClick == 5:
5 - 4bil = 5 + ~(4bil) = 5 + (2^32 - 10) = 5 + 10 = 15 -> double click

tmClick == 60000 (click one minute later):
60000 - 4bil = 60000 + ~(4bil) = 60000 + (2^32 - 10) = 60000 + 10 = 60010 -> single click

Sometimes it helps to think in lower precision. Makes all the scary big numbers go away :-). And off course - remember that subtraction is addition of complement. Makes it even less scary.

re: Implementing higher-order clicks

muro — Tue, 19 Oct 2004 09:10:00 GMT

Overlooked in 32 bit part:
GetDoubleClickTime() = 10: would mean, the first 32bit example is also single click (as time difference is 15), but I hope you get the idea.

re: Implementing higher-order clicks

krisztian pinter — Tue, 19 Oct 2004 09:50:00 GMT

thanks, muro!

in my mind, result of substraction was the same as the distance. in a "modulo world", it is not that easy.

re: Implementing higher-order clicks

Raymond Chen — Tue, 19 Oct 2004 15:05:00 GMT

You can think of modulo arithmetic as points around a circle. Subtraction gives you the distance along the circumference, which doesn't care where your zero marker is.

Another way of looking at subtraction is to view it as a translation of the circle, which is isometric (distance-preserving).

re: Implementing higher-order clicks

Joshua Schaeffer — Thu, 11 Nov 2004 23:58:00 GMT

Merle, triple clicks in Word are one of the biggest time savers for me. Sometimes I'm in this utmost lazy chair position where even using right-click is a tiresome expense of a few seconds. Although I personally wouldn't mind a "click chart" like so:

1 - (normal)
2 - word
3 - sentence
4 - paragraph
5 - everything

Using modular arithmetic to avoid timing overflow problems

The Old New Thing — Tue, 31 May 2005 16:03:24 GMT

Avoiding timing overflows is easier than you think.

Clairvoyant Interaction | Chui’s counterpoint

Clairvoyant Interaction | Chui’s counterpoint — Sun, 24 Aug 2008 19:41:43 GMT

PingBack from http://www.redmountainsw.com/wordpress/archives/clairvoyant-interaction