_{Ну раз никто глупых вопросов не задает, тогда задам я}


В общем задача понятна должна быть, но тезисы обрисую:

1) Есть юзерконтрол. У него должна быть некая функция, которая обеспечивает появление дополнительного окошка, в которое в идеале динамически грузится другой юзерконтрол с произвольным функционалом.

2) Окошко не должно ограничиться границами контейнера, на котором расположен базовый юзерконтрол (иначе можно было бы просто изменять размеры юзерконтрола)

3) Окошко должно реагировать на края экрана и выпадать сверху, если снизу оно не помещается до края экрана.

4) Окошко должно исчезнуть, если произошел клик мимо него (простая потеря фокуса не годится, так как если просто кликнуть по пустой части формы, активный контрол фокус не теряет), а также потеря фокуса основным контролом или базовым приложением.

Как я понимаю, п.2,3,4 без АПИ реализовать не удастся, подскажите плиз - какими функциями нужно воспользоваться.

Antonariy,

Упс...
старый склеротик...
тогда не разобрал, не до этого было....

ща займусь.

Antonariy,

А ты его после того не дорабатывал? Чтоб уж последнюю версию смотреть...

Ругается на отсутствие cUxTheme.dll
Это для чего? в той версии такого не было

Antonariy,

Я в данный момент на 2000к и стили мне не нужны, так как выпадания будут вызываться специфическими кнопками, поэтому пока ковыряю старую версию.

Пытаюсь курить код, тяжело, ибо стихи АПИ - нет беглости, а пока изучишь каждую функцию, забудешь с чего начинал. Так структуру примерно разобрал, просто много непонятно, почему именно так. К примеру, почему события Click и DblClick сделаны через отдельный класс? А вот само время жизни окна находится внутри цикла, в котором нет DoEvents - как же он обходится?

Shocker.ProК примеру, почему события Click и DblClick сделаны через отдельный класс?
Кстати, для чего они вообще нужны?
По идее - требуется, чтобы по возникновению какого-то события в выпавшем фрагменте, сам выпавший фрагмент закрылся. Для этого, как я понимаю, нужно выставить fStop в True, но это делается через сообщения, почему? Только из-за того, чтобы работало на модальной форме?

фух, отодрал работу со стилями, ща буду курить дальше уже новую версию...

WorobjoffЕсть еще один маленький клопик:
Если форма внизу экрана, фрейм дропается вникуда (за пределы экрана, а не вверх).
А это ты не стал исправлять делать, как я понимаю?

AntonariyShocker.Pro А вот само время жизни окна находится внутри цикла, в котором нет DoEvents - как же он обходится?GetMessage ожидает событий, блокируя поток. Пока их нет, цикл стоит.
Но, получается, при этом спокойно отрабатываются события в другом потоке? То есть в "выпавшем" контроле я могу делать что хочу?

В принципе, получается такая цепочка, если я все правильно понял:
1) TargetProc перехватывает сообщения окну "выпавшего" контрола
2) Если находит WM_LBUTTONDBLCLK, посылает контейнеру "выпавшего" окна сообщение на уничтожение
3) ...Одновременно с этим запускает таймер для генерации события
4) Окно контейнера уничтожается, GetMessage получает WM_QUIT, цикл завершается, завершая работу "выпадения"
5) тем временем таймер генерит событие в классе, которое получает базовый контрол.

В общем-то, я хочу несколько переиначить это дело, то есть наплевать на Click, DblClick - у выпадающего юзерконтрола могут быть задачи посерьезнее и я делегирую ему полномочия решить, когда ему закрыться (например пользователь нажал определенную кнопку). То есть пункты 2,3,5 я могу смело ликвидировать.
Если я опять же правильно понял, когда выпавший контрол решит, что его миссия выполнена, он должен сделать это:
(разумеется gDropWindow должно оказаться в его области видимости)
и цикл завершит свою работу. При этом сам факт завершения цикла будет событием для базового контрола, что выпавшая часть завершила свою работу, а если нужна дополнительная информация - ее можно взять через свойства выпадающего контрола.
Правильный подход?

ЗЫ: твой текущий пример можно загнать в астрал следующим образом - раскрыть выпадающий список и нажать Alt+F4

AntonariyКстати, здесь есть громадная засада. Контрол спроектирован так, чтобы исключить возможность появления вообще в системе обновременно более одного выпадающего окна, потому что глобальные переменные модуля разделяются всеми экземплярами контрола во всех процесах.

Я тоже поначалу не понял, почему это модуль, а не класс.
Что причина, а что следствие -
1) ТЗ на то, что нельзя получить два выпадающих списка одновременно => реализация в виде модуля
или
2) Реализация в виде модуля - как следствие невозможность получить два выпадающих контрола
?
А если изолировать модуль в класс - будут работать два?

Насколько я понимаю, увод фокуса автоматически закроет выпадающую часть, так что второй выпадающий контрол может появиться только если это будет по инициативе программы, а не пользователя.
Кстати, а что будет, если приложение по своей инициативе уведет фокус на другую форму (есть у меня такое - приход сверхважного сообщения)?

AntonariyЕсли же процедуру закрытия будет регламентировать не DDControl, а кто попало, то потенциально возможна попытка показать более одного дропдауна, что приведет к краху программы.
Ну, собственно, вариант с отсылкой WM_USER + 4 это решает? или ты что-то другое имеешь ввиду?

AntonariyВ любом случае, в виде класса это сделать не получится без ассемблерных вставок, а оно разве надо?

Для общего развития - а что там такого, что не может быть размещено в классе?

AntonariyОконные процедуры. AddressOf понимает только те, что объявлены в модуле.

Ну обойти, конечно, можно, разместив оконные процедуры в модуле и делая реестр hwnd и соответствующих им объектов.... но незачем, конечно же....

Блин.
БЛИН.

Antonariy,

Ща начал интегрировать в рабочий проект и тут-то выяснилось, что метод не подходит для моих целей. Как я писал в самом начале - предполагается выпадение юзерконтрола с произвольным функционалом. Возьмем в примитивном случае, что должен выпасть фрейм с кнопкой на нем.

Как только я пытаюсь нажать кнопку, у окна gTarget возникает сообщение WM_KILLFOCUS и мое окошко DD уничтожается, не дав мне даже получить событие от кнопки. А нужно, чтобы оно в этом случае вообще не закрывалось.


В общем, методом тыка и грубой силы сделал следующим образом: при получении WM_KILLFOCUS, DD не уничтожается, а запускается таймер. Вот обработчик таймера:

Ничего другого в голову не пришло, прошу совета, а то мне кажется это как-то слишком грубо. Кроме того, теоретически ведь я могу щелкнуть по другому контролу с выпадающим списком. И тогда возникнет та самая ситуация, когда открывается следующий DD, а предыдущий не закрыт. Я даже пока не стал пробовать такую ситуацию, конечно, можно сделать контрольные проверки, но пока не делаю, надеюсь, что будет идея получше.

он еще и не рабочий этот метод
если убрать строку
то работает, но перестает закрываться по потере фокуса по понятным причинам.
а с этой строкой - события кнопки не возникают

Ситуацию исправил добавлением процедуры обработки потери фокуса для любого контрола, находящегося в подчинении DD. Выглядит ужасно: