I agree. I wouldn't have a use for the doulbe-click, but I'm sure there are other developers that would. I hope were not pushing Oleg's buttons now...

Mark makes a great point.  Instead of treating all double-click events as a click event, they could be handled differently.  If the developer didn't want to treat double-click events differently, just set an option telling Command Bars to report a double-click as a click.

Oleg, I hope this is an alternative implementation you might consider.

Having said that, it would be quite useful for CommandBars to recognise a double-click and generate an event. This could be then used, as in Microsoft Word, for two-state buttons to permanently set a mode in the application. For example in Word on the drawing toolbar, if you click the Rectangle button it allows you to draw one rectangle before it switches back into normal text editing mode. However, if you double-click the Rectangle button, Word stays in 'rectangle mode' and allows you to keep adding rectangles until you switch manually to another mode.

This feature would be quite useful in CommandBars. Maybe it should be optional, set by a Property.

Mark

Thank you all. Really CommandBars was ignored DblClick event. In Next version DblClick event will be used as Click.

For me it always seems to call Execute half as many times as it should if I do button clicks as fast as I can. For example if I do 10 very fast clicks I get 5 items in the listbox, if I do 20 clicks I get 10 items. This implies to me that it is the double-click message not being handled properly. CommandBars seems to be interpreting the second click in each pair of clicks as a double click and doing nothing. This also seems to be the case when looking at the messages received by the button when clicked 10 times rapidly. See attached Winspector images - the left image is the CommandBars button and the right the standard button.

Doesn't quite make sense since the CommandBars button seems to call Execute on a mouse button up rather than a down and there are 10 ups in each case.

Mark

Mouse_Clicks.zip

Sorry for stretching this out for so long. Just to make another observation about this. I modified Boyd's Form_Load to this:

 CommandBars.Item(1).Visible = False
    With CommandBars.Add("Standard", xtpBarTop)
        .Controls.Add xtpControlButton, ID_TEST, "Click Me Rapidly", -1, False
        .Controls.Add xtpControlButton, ID_TEST + 1, "Me Too", -1, False
       
    End With

And noticed that if you click rapidly between 2 different buttons, this problem doesn't occur (at least for me). Which leads me to believe that when this problem occurs on one single button, the commandBars is treating rapid clicks as 'double clicks' instead of rapid clicks, which it's not set up to handle?

I'll be done now!

SuperMario: Thanks for double checking. I don't think it's a matter of 'the process finishing', but that's a good theory. I think if that was the case then the 'Execute' events that are missing would be on the call stack and would eventualy be fired.

Oleg: Mixing your sample above and Boyd's..

Private Sub CommandBars_Execute(ByVal Control As XtremeCommandBars.ICommandBarControl)
    Select Case Control.Id

...
     Case ID_FILE_SAVE:     

    Static iClick As Integer
    iClick = iClick + 1
    Me.Caption = iClick

The caption only updates (roughly) every other click for me. Not alot of code to execute. I'd be curious to know if others are experiencing the same problem.

I've had other 3rd party controls that act similar to this. In other cases, it has been when they are triggering an even (such as Execute) on mouseUp rather than mouseDown of the control. Not to say that's the case here...

It would be nice to get feedback from some of the other users on the forum about this.

SuperMario: Do you have to wait at all between button clicks?