При выборе элемента списка из комбобокса, вызывается  LWS_UpdateInfo();. Она же вызывается, в OnIdle.
Не знаю как, но когда я открываю список мышкой и не кликая перемещаю курсор с одного элемента списка на другой, срабатывает OnIdle.
Как этого избежать? Т.е. Idle должен работать всегда, кроме момента, когда я работаю со списком.
Как не пытался задействовать фокусы у списка и даже формы ничего не получается. Приложение либо снимается, либо работает так, как описано выше.

Дело в том, что Idle вызывается каждый раз когда приложение простаивает (нет ничего в очереди сообщений). Поэтому, чтобы отделять ситуацию "приложение не выполняет действий" от ситуации "ждём реакции пользователя", нужно либо:

1) Не использовать Idle
2) В обработчике Idle проверять некий флаг, который ставить в true в каждом месте, где может возникнуть ожидание без действий со стороны пользователя (aka без добавления сообщений в очередь сообщений)

2. Пытался такое сделать, но, в какой момент ставить флаг? На какиех двух событиях на комбобоксе это завязать?
Пробовал разное...

Событие DropDown - генерится при открытии раскрывающегося списка. Событие DropDownClosed - при закрытии.

mr.DUDA, возможен еще и такой вариант, что список будет юзаться не раскрываясь через клаву или колесико мышки...

Тогда ловим SelectedIndexChanged/SelectedItemChanged, но имхо это не то. Ведь юзер может долгое время просто ничего не делать - как это обрабатывать ? Забивать на Idle с момента получения фокуса комбобоксом  ?

Какую задачу вообще нужно решить ? Если необходимо выполнять действия в фоне, то вполне подойдёт отдельный поток (System.Threading.Thread).

Нужно проверять состояние одного сервиса, постоянно. И реагировать на это.


Пробовал. Не работает. Попозже попробую еще раз.

Тогда отдельный поток - то что нужно.

Пример:

А это не будет сильно грузить систему?
пошел покупать книжку Шилдта...

Выставишь задержку в потоке, и будет занимать вообще 0%

Окей. Спасибо... Пойду разбираться.
Ресурсы, которые кушает поток будут меньше, чем аналогичная реализация алгоритма через Timer?

Ну, в общем да; смотря какой таймер, кстати. Есть System.Windows.Forms.Timer, который работает через обычную очередь сообщений винды и WM_TIMER -- такой таймер будет пропускать тики до тех пор, пока есть необработанные сообщения в очереди, закинутые раньше чем тик; а есть System.Threading.Timer - он посылает свои события через ThreadPool. Что кстати не всегда подойдёт, т.к. в случае если обработка события таймера занимает бОльшее время, чем период таймера -- тогда события таймера будут накапливаться в очереди на обработку, вплоть до разбухания очереди до бесконечности. Поэтому, советую юзать класс Thread, с пом. которого запускать свой метод в отдельном потоке, и делать в этом методе любые действия, разделяя их паузой этак в 10-100 миллисекунд.

З.Ы. кстати, если нужно работать с контролами на форме из отдельного потока -- то см. пример от ivashkanet, где стоит коммент " анонимный делегат, который поменяет значение Лабела"...

Не совсем понятно назначение этого анонимного делегата...
Реализовал через потоки. Работает. Попозже код положу.

Ну, это для того чтобы можно было работать с виндошными контролами (окна, текстбоксы, листбокс, и т.п.) из не-GUI потоков. Обычно, если пытаешься например изменить текущий item в комбобоксе из другого потока --  генерируется exception.