AntonariyShocker.Pro А вот само время жизни окна находится внутри цикла, в котором нет DoEvents - как же он обходится?GetMessage ожидает событий, блокируя поток. Пока их нет, цикл стоит.
Но, получается, при этом спокойно отрабатываются события в другом потоке? То есть в "выпавшем" контроле я могу делать что хочу?
В принципе, получается такая цепочка, если я все правильно понял:
1) TargetProc перехватывает сообщения окну "выпавшего" контрола
2) Если находит WM_LBUTTONDBLCLK, посылает контейнеру "выпавшего" окна сообщение на уничтожение
3) ...Одновременно с этим запускает таймер для генерации события
4) Окно контейнера уничтожается, GetMessage получает WM_QUIT, цикл завершается, завершая работу "выпадения"
5) тем временем таймер генерит событие в классе, которое получает базовый контрол.
В общем-то, я хочу несколько переиначить это дело, то есть наплевать на Click, DblClick - у выпадающего юзерконтрола могут быть задачи посерьезнее и я делегирую ему полномочия решить, когда ему закрыться (например пользователь нажал определенную кнопку). То есть пункты 2,3,5 я могу смело ликвидировать.
Если я опять же правильно понял, когда выпавший контрол решит, что его миссия выполнена, он должен сделать это:
1.
2.
PostMessage gDropWindow, WM_USER + 1 , 0 , 0
PostMessage gDropWindow, WM_CLOSE, 0 , 0
PostMessage gDropWindow, WM_DESTROY, 0 , 0
(разумеется gDropWindow должно оказаться в его области видимости)
и цикл завершит свою работу. При этом сам факт завершения цикла будет событием для базового контрола, что выпавшая часть завершила свою работу, а если нужна дополнительная информация - ее можно взять через свойства выпадающего контрола.
Правильный подход?
ЗЫ: твой текущий пример можно загнать в астрал следующим образом - раскрыть выпадающий список и нажать Alt+F4
