\nFirst, I’m going to refer you to\n\nthe MSDN documentation on mouse clicks<\/A>,\nsince that’s the starting point.\nI’m going to assume that you know the mechanics of how\nsingle-clicks are converted to double-clicks.\n<\/P>\n \nOkay, now that you’ve read it, let’s talk about some logical\nconsequences of that article and what it means for the way\nyou design your user interface.\n<\/P>\n \nFirst, some people design their double-click action to be\nsomething unrelated to the single-click action.\nThey want to know if they can suppress the initial\nWM_LBUTTONDOWN of the double-click sequence.\n<\/P>\n \nOf course, you realize that that would require clairevoyance.\nWhen the mouse button goes down for the first time, the\nwindow manager doesn’t know whether another click will come\nor not. (Heck, often the user doesn’t know either!)\nSo it spits out a WM_LBUTTONDOWN and waits for more.\n<\/P>\n \nNow suppose you’re a program that nevertheless wants to\ncontinue with the dubious design of having the double-click\naction be unrelated to the single-click action. What do you do?\n<\/P>\n \nWell, one thing you could do is to do nothing on receipt\nof the WM_LBUTTONDOWN message aside from set a timer to fire\nin\n\n \nThis “wait a tick” technique is also necessary if you don’t\nhave a double-click action, but the second click causes trouble\nin conjunction with the first click. Why is this necessary?\nBecause many users double-click everything.\nHere are some examples of where the “delayed action to avoid\nthe second click” can be seen:\n<\/P>\n \n<\/P>\nGetDoubleClickTime()<\/CODE><\/A> milliseconds.\n[Corrected 10am.]\nIf you get a WM_LBUTTONDBLCLK message within that time,\nthen it was a double-click after all. If you don’t, then\nit must have been a single-click, so you can do your single-click\naction (although a bit late).\n<\/P>\n\n