Hi,

I use CommandBar for navigation in table (database). There is long delay between two CommandBars1_Execute events. Standard vb Toolbar (windows common control) has no delay.

Is there any property for delay in CommandBar?

Thanks

Jiri

Sorry, I don't understand what delay do you mean. In the SDISample I changed

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

...
     Case ID_FILE_SAVE:      Debug.Print Control.Caption

And see "Save" each time I click button without any delay...?

The problem occurs no matter what you're doing with the button.  I've created a very basic sample application which illustrates the problem.  The form includes a single CommandBar control and a list box.  Click the control and the listbox gets a new item.  No matter how quickly you click the control, the items are not added to the listbox at a comparable rate.  The ZIP file includes full source to the project in VB6 as well as an 'DelayTest.exe' file which can be executed as long as you have CommandBars ActiveX registered.  I hope this helps isolate and debug the issue with the delay.

http://forum.codejock.com/uploads/Boyd/9Z4_TestApp.zip - 9Z4_TestApp.zip

No, it's not a long delay (about half a second).  But it's enough to be noticed when you're trying to execute the same command very quickly.  This delay issue is evident in the Xtreme Command Bars Designer tool.  The 'Controls' pane has a list of all your controls, and the toolbar has an 'up' and 'down' arrow for you to move a control up and down the list.  Now let's say you have 50 controls in the control list and you want to move the one from the bottom of the list to the top.  After I select the control to move, I'll have to click the 'up' button about 50 times.  I can easily click the 'up' button about twice as fast as the command bar recognizes it.  If it had processed all of my clicks, I could have accomplished my task twice as fast.

I've updated the sample app I provided to include a standard command button.  Click this button rapidly and see how much faster it processes the click event.  Seeing the two controls perform side-by-side will better illustrate the delay.

http://forum.codejock.com/uploads/Boyd/D8C_TestApp.zip - D8C_TestApp.zip

SuperMario wrote: Yes, there is a noticable difference, but nowhere near half a second

Individual systems will certainly perform differently.  I just wanted to illustrate that there is a noticeable difference.

Just my 2 cents...

I've noticed this as well, but wouldn't categorize it as a delay, but rather:

The Execute event doesn't allways fire when pressing a commandBar button. On my system (P4 2.7 GHZ 1 GIG RAM) I have to wait a second between my button presses or the Execute event won't fire.

This is how the posted sample and CodeJock samples work on my system.

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?

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.

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!

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

http://forum.codejock.com/uploads/mark/Mouse_Clicks.zip - Mouse_Clicks.zip

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

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

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.

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...