OK, thanks.  Just out of curiosity, why would this be the "expected behavior"?  What is the logic for this "expected behavior"? Why would anyone want to have to have a click event eaten by a combo closing? This is not happening on any combo I have ever used, including the UltraCombo when not in CheckedList mode.  It is as the original issue reported stated, "extremely annoying", and to such an extent that now two of my clients are requesting the removal of the multi-select feature they asked for and going back to only having a normal single select combos.  My combos are all over these applications and I am not sure of any side effects of the work around you provided.

Hi,

I'm a little confused. I tried this out with UltraCombo, UltraComboEditor, and the inbox ComboBox and I get the same results in every case, with or without multi-select. In all cases, when the combo is dropped down, the first click anywhere in the application is eaten by the combo closing.I have attached my sample project here so you can try it for yourself.

Then I tried some Windows applications like the navigation bar in Windows Explorer. Once again, I get the same results.

So I believe this is a standard of Windows programming in general. Am I missing something?

clicking a selection in all these will close the combo and so there is no problem.  Not sure about "eating the click" unless the combos also have a click event.  I guess if you do not select anything with a dropped down combo, and try to go somewhere else it might eat the click. That itself is probably a bug for all combos, certainly an undesirable "expected behaviour" for again, even in this case, why would a user want the click eaten, to confirm to them that they did not select anything?

The problem being discussed here is on the CheckedItems, a user may want to select multiple items, which is the reason for the multicombo, so it is not closing up automatically. Since in the real world most uses of this functionality is to pick some kind of filter or select multiple things before performing some action, the result is that after selection, the user's next action, a click on a button more than likely (or even another control) is just wasted and they have to do again.  All my clients are screaming about this, they are busy, head-down users selecting options and clicking to run reports, fill grids, etc.) and when they look up and see nothing is running, they have just wasted a lot of time.  I have given my clients shortcuts to the commands (which avoid the problem) and told them to tab out if they remember, but this is not the desired way some users work.

Anyway, if this can't be modified or a reliable workaround found, it really diminishes the usefulness of this option of the control, at least for my clients.

Thanks.

Hello sunibla,

I am checking about the progress of this issue. Please let me know If you need any further assistance on this.

Mike:  Thanks.  I understand the behavior of combos better now owing to this issue.  The only difference here, is that with multi-select capability on checked items, the combo is not closing automatically (as it shouldn't) when a selection is made in order to allow multiple selections.  On normal combos, selecting an item would close the combo and so the missing click issue does not come up. 

Here I think an option to not eat the click somehow would be great if you could implement since the user has made a selection (or multiple) and is expecting a click somewhere else to produce an action.  If there are no selections made, then perhaps the normal behavior of nor going anywhere might be "standard".  Any, if Infra could do it, it would be much appreciated.

In the mean time, since the original workaround does not work (probably owing to controls buried in panels, other controls, etc.) I have my users testing another workaround:  Mousemove event on Infra tab control where these combos sit will close any of my multi-select combos.  Downside is, the user has to be careful not to move their mouse outside of the control when making multiple selections or scrolling the list.

Hi,

The behavior is the same whether you are using CheckedItems or not. When the combo is dropped down and you click on something outside the combo, it closes up and the mouse message is eaten up by this process.

I am sure this is intentional, and it's the same way that every dropdown in Windows behaves. As to why, you'd have to check with Microsoft to get a definitive answer, but my guess is that clicking away from the combo indicates a sort've no-op by the user. The user is basically saying, I just want to close the dropdown without doing anything. If the click was processed by whatever you clicked on, then the user would be forced to find a spot to click on which didn't contain anything, which would be mildly inconvenient.

I expect that Windows users in general are used to this behavior and any change it would be confusing and potentially dangerous.

Having said that, I can't immediately see any reason why we couldn't implement a property on the control that turns this behavior off. So we could submit a feature request for you and perhaps this can be added in a future volume release.

Sunibla,

I have just verified that the Microsoft's ComboBox and Button are acting in the same way.

Please take a look at my sample, attached to this post.