I thing that the EVENT_MOUSE_CLICK_DOUBLE is inposible to do ...
first EVENT_MOUSE_CLICK is too fast can we setup this ?
and I watch in visual studio double click is a EVENT_MOUSE_CLICK + an EVENT_MOUSE_BUTTON_DOWN
if it's could help you ...
I don't think it's impossible to do. The catch is whatever you are doulbe-clicking still will recieve the single-click event, but if a second click is recieved in close succession, then the double-click event will be fired.
This may sound limiting, but it's really the only way I've ever seen double clicks handled. For example, in Windows if you click once on an icon it selects it. If you double click, it selects it after the first click and then opens it on the second click. Try it!
Otherwise you are right that there would have to be some delay to wait for a potential second click, which wouldn't make sense at all.
I laid out the logic to implement an exclusive way to obtain double/single click events in an older thread. Whether it works in practice, I have yet to find out. Just to clarify, *exclusive* means you will not receive a single click before a double click. If all else fails I'll have to go the non-exclusive route, which is the same as all other GUI's functionality. (well, some don't even support double click yet)
But will that register a delay for single clicks? I guess in a smart system, the delay would only be applicable when a listener for the double-click event is added.
If you've figured out a way to do it without any delays, I've gotta hear that! I don't think it's theoretically possible
You're right, I don't think its possible either, there will have to be a delay.
Here is the basic discussion:
I'm rusty on how it works, so I can't go in depth at the moment.
Its not possible without the delay as you said. If I go with the default method, the double click is pretty limited IMO. For example, imagine you have a potion in your equip box (diablo style). Single click will drink the potion, and double click will place it in your belt. This isn't possible with the standard approach because you'd drink the potion before the double click registers..
I actually don't really agree with the idea that exclusive is better than non-exclusive. Every use I've seen of a double-click is where the single-click functionality is reversable and relatively unimportant. That is, when you single-click it selects something, or activates something, not consumes or destroys something.
I think this makes sense for 2 reasons: First, it eliminates the need for a delay, because the one-click event doesn't preclude the double-click event, so it's ok if both fire. Second, the user might slip and not properly do the double-click in time, so the option should still be available to them if they managed to only click the mouse once on their first try. Imagine your parents using a computer...
About the delay times mentioned in the previous thread, I agree that a double-click needs a window about about 600ms-800ms to register. However, it would be obscene
if every click had this length of delay! That would frustrate the hell out of users and that would be the end of it. The accepted standard is that any delay in reaction time longer than 100ms will begin to annoy users.
I would suggest that the library API not provide exclusivity for double-click events (at least not be default), and instead let the user implement it themselves. If you really do think it could be useful, then create an option in the API so users can enable this functionality through the delay, but don't make it the only way.
Please think about the big picture use for a little while before implementing...
Well nobody specifically asked for the exclusive idea, I just thought it would be cool to have. I can't say if the delay would be tolerable or not, but it looks like I've found one user who thinks its outrageous.
Well at least with the behavior you describe, it seems easier to implement. I'd probably use two sets of timers:
Haven't thought out all the logic yet. Want to help?
I noticed on Windows XP platform that the double click happens when the mouse button goes down a second time. (as opposed to the second mouse up) Is there any benefit/consequence to this behavior? It's odd that clicks are determined on mouse up, and double clicks on mouse down.
I also want to support a triple click. We should have the following functions/members added this weekend:
void GUIManager::injectMouseClick(const MouseButtonID& button);
void GUIManager::injectMouseDoubleClick(const MouseButtonID& button);
void GUIManager::injectMouseTripleClick(const MouseButtonID& button);
void GUIManager::setDetermineClickEvents(bool determine);
This gives the user the choice to inject click events themselves, or have it determined through use of the injectMouseButtonDown function. (default behavior)
Input regarding double/triple click detection on mouse down vs up is welcome.
Hey, sorry if my previous post sounded too critical... I was in a bit of a rush
Anyway, I'd be happy to come up with the logic or even implement it if you want. I've got some ideas for it, so I'll post them later today.
About the double-click registering on the up or down, that's an interesting observation. I don't really have a preference either way, but it might be good to stick with whatever seems to be convention (on the mouse down I guess). Perhaps it's to prevent a double click-drag combo, which might confuse people. I don't really know though