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.

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?

The workaround does not work:  no matter where I click, another control, the form, an infragistics tool bar button, etc., the control returned by GetChildAtPoint(this.PointToClient(Control.MousePosition)) is null

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.