Итак я научился делать прозразный фон окон! Спасибо Earnest! Правда я чуть поправил код, ибо он не работал до конца нормально. Но огромное спасибо тебе за мысль!!! Спасла старика, и дала веру в себя!
Чуть позже я выложу вам способ
Теперь помогите добить окна..Я совсем перегорел..
Я прикрепляю файл с интерфейсом.
Есть БОЛЬШОЕ главное диалоговое окно. Оно имеет три кнопки слева, две справа вверху и окно контейнер.
Обратите внимание! Посередине него есть большое окно. Оно имеет полосу прокрутки. Остальное вы не увидете из-за прозрачного фона оно сделано производным от СWnd Это окно контейнер
Я нарисовал на БОЛЬШОМ (главном диалоге его как CUSTOM CONTROL)
Внутри этого окна создаются белые окошки-динамически по мере поступления сообщений от системы.
Белые окошки я сделал от диалоговых производными.
Теперь вопросы.
1.Где динамически создавать диалоговые окна? Так как я окно контейнер не создаю через Create(), то сообщения в этом классе по созданию окна отлавить невозможно. Поэтому я создаю диалоговые окна в OnInitDialog() большого окна..
2.Где ресайзить белые диалоговые окна? Они должны ресайэиться вместе с главным окном.
3.Как лучше контролировать каждое созданое белое окошко? Как знать о его уникальности? Создать массив указателей? Назначать каждому ID? Но как знать, что именно пятое диалоговое окошко должно обновить в себе элементы?

Присоединённый файл ( Кол-во скачиваний: 18 )
 all.rar 51,45 Kb

Никто даже не скачал файл!

Помогите!

Добавлено @ 17:45
Я ж вам помогал в свое время, жулики!

Coocky, это опять я...
Во первых, молодец, что справился с прозрачностью! Я же тебе говорила, что справишься
Во-вторых:
1) в OnInitDialog создавать дополнительные окна вполне нормально
2) Где ресайзить? Что за вопрос! Это же его child'ы - значит, в OnSize основного диалога
3) Конечно, нужно их все запомнить в массиве, я бы помнила pWnd, нафига их ID, это вообще что-нибудь служебное, лишь бы было.
4) Обновляются пусть сами, на OnIdle, и сами следят за своими изменениями. Скажем, главное окно по Idle вызывает их Idle-обработчики.

Как узнать, что именно пятое окно должно обновить свои данные? Можно по-разному сделать.

Например, схема N1, асинхронная: окна запрашивают данные у какого-либо объекта, назовем его "источник данных", кто бы он не был. Этот объект обладает следующим свойством: при изменении части данных он инкрементирует свой внутренний флаг timestamp.Окно, которое должно выводить данные этого источника, тоже имеет свой timestamp. Idle-обработчик спрашивает источник данных - какой нынче timestamp. Если у меня такой же, спим спокойно дальше, если больше, чем у меня, обновляем данные, обновляем timestamp и снова спим дальше.
А далее - можно по источнику данных на каждое окно, можно один для всех - как удобно...

Схема N 2, синхронная: реализуем шаблон Подписчик-Издатель. Ну, то есть, источник данных, сразу после обновления, рассылает уведомления всем заинтересованным объектам (тем, что подписались).

Мне лично для синхронизации с UI больше нравится схема N1: обновлять timestamp можно после изменения любого поля, не беспокоясь о том, единичное это изменение или пакетное - обновление данных будет происходить на Idle, без лишних морганий.

благодаря тебе

Т.е и диалоги и диалоговы элементы? Все в обработчике основного окна?
Ну я понимаю кнопки БОЛЬШОГО диалога, ну понимаю , что окно контейнер надо, но разве белый диалог и его дочернии элементы тоже там?
Я чего спросил.. Попробывал я ресайэить кнопки белого диалога(так называю что б понятней из рисунка было.. ) в обработчике OnSize() этого диалога... Дуля с маком(как в детстве говорили)
Вот примерно что получается



Дя меня вообще остались важными 3 момента.
1.Скролирование окна контейнера. Никогда руками не делал, но правда еще и не брался Но на всякий случай уже боюсь.
2.Где обрабатывать(в каком классе) сообщения. Дело в том, что программа "слушает" программы шпионы. И как только (я не знаю как это происходит-это драйверный отдел делает ) обнаруживает его-создается белый диалог с заполнеными данными про обнаруженого шпиона. Таких диалогов может создаться бесконечно.
Т.е стоит вопрос-либо класс окна контейнера либо БОЛЬШОГО окна (слушать в классе белого диалога я не вижу смысла )
3.КАК же правильно всех ресайзить!! Где,т.е.

Это сообщение отредактировал(а) Coocky - 30.1.2006, 21:42

Вставлю пару слов по поводу ресайзинга.
Я с этим уже прилично намучался, и вспомнил свой небольшой опыт программирования на JAVA. Так вот, в GUI-прибамбасе этого языка ("java awt", если не изменяет память, называется), по умолчанию на всех окнах установлны так называемые менеджеры компоновки. То есть заранее все окна разбиты на какую-то логическую структуру (например, табличный менеджер компоновки), и при добавлении элементов в окно элементы сазу заполняют такую структуру. (То есть например, ячейки некой абстрактной таблицы). И дальше при любых махинациях с позицией/размером окон менеджеры компоновки сами перерисовывают контролы в соответствии с этой "Картой". Размеры ячеек создаются как фиксированными, в пикселах, так и в процентном соотношении от размера окна. (Если когда-нибудь работал с HTML, то наверняка знако с таким подходом. )

Я подумал, почему бы данной идее не прижиться и в родимом MFC, и реализовал у себя класс, подобный явовскому табличному менеджеру компоновки. Экземпляр этого класса я создаю в каждом нужном мне окне, связываю с окном-хозяином, и в его ячейки помещаю *CWnd всех контролов, находящихся в окне-хозяине. Единственное, что после этого остается сделать - в окне-хозяине в обработчике WM_SIZE вызвать одну из функций этого класса. И все. О ресайзинге после этого можно забыть. Главное, в каждом окне правильно расчертить карту, то есть правильно заполнить параметры менеджера компоновки. Ну и естественно, делается все по принципу "матрешек" - то есть в каждом масштабируемым подобным образом окошке создается свой табличный менежер, в его ячейках - свой, и так, пока каждый контрол не окажется на своем законном месте.

Получается, что работает такая хреновина следующим образом - при получении сообщения WM_SIZE вызывается как рз та самая функция менеджера компоновки. Эта функция рассчитывает все значения координат для добавленных в него контролов, после чего каждому контролу делает SetWindowPos с соответствующими параметрами. Эта функция приводит в свою очередь к тому, что каждое добавленное в менеджер компоновки окошко в свою очередь тоже ловит WM_SIZE, и если в этих окошках есть свои "мини-карты", то для них тое соответственно вставляются обработчики этого события.
Вставка всех необходимых обработчиков занимает буквально несколько минут.
"Разметить" карту плучается чуть дольше, для этого допусти в диалоге, созданном в редакторе ресурсов, нужно для каждого кнтрола получить его указатель и засунуть в менеджер кмпоновки соответствующей функцией, тут главное не напутать с размернотью ячеек (а их можно проставлять как в пиксельном, так и в процентном соотношении, как я и говорил уже).
Ну и на разработку самго класса у меня ушло около часа-двух, и хоть он получился достаточно сырым и путанным - он мне уже сильно облегчил жизнь, с ресайзингом дочерних контролов больше не заморачиваюсь.
Так что советую воспользоваться чем-то подобным ;)

Это сообщение отредактировал(а) Dreamer_0x01 - 30.1.2006, 23:11

Кстати,о скроллинге. Одной из моих первых программ на MFC была фишка, где одно окно скроллировалось внутри другого. Ничего сложного и глючащего, все прекрасно работало.
А делал так -
1. в главном окне создавал окошко "окно 1" от CWnd и полосы прокрутки.
2. Внутри "окна 1" создавал "диалог 2" от CDialog со стилем CHILD, в отором создавал столько контроло и окон, сколько душе угодно.
3. Делал SetWindowPos "диалога 2" внутрь "окна 1" c флагом "SWP_NOZORDER" и "SWP_NOSIZE". И вот координаты, передаваемые в этот SetWindowPos величины, высчитанные из отношения разности в размерах окон "диалог 2" и "окно 1", к позиции скроллбара. А параметры скроллбара, соответственно, высчитывал также сходя из отношения размеров этих двух окон. Могу в принципе нарисовать рисуночек, если не понятно. Либо сотворить небольшой проектик, где это реализуется.

Почти моя ситуация, только этих диалогов может быть сколь угодно и создаются они динамически
Но это еще впереди..Главная проблема сейчас №1-немогу отпозиционировать элементы самого вложеного диалога по отношению к этому диалогу. Читай выше

Так как предлагает Earnest-надо тогда перебирать все диалоги в окне контейнере(кстати, а как правильно перебрать все диалоги и получить на них указатели-для окна контейнера)?-не сложно ли это будет?
Добавлено @ 10:55
Хаха!
Вообще бред!

Обьект умирает до отладки
Простите инвалида

Добавлено @ 11:24
Итак ресайзинг побежден..Осталась прокрутка
Ждите новых сообщений

Ах да,забыл спросить Как перебрать все диалоги(получить на них указатели) в окне контейнере?

Ну что ж,я начинаю востанавливать свою былую форму
Итак перебор все окон


Осталась прокрутка, пока

Ну и что это меняет?


и как поживает?

Еще не знаю Всегда пользовался только халявным CSrollView

Я даже не знаю как запускать, не говоря о расчетах..
Я не пойму -окно само прокрутит или нужно сдвигать все диалоги при прокрутке?

Coocky "Само" ничего не делается .

Не совсем поняла из твоих постов: эти самые диалоги, которых сколько угодно и которые динамически создаются - они что, в контейнере располагаются друг под другом, как бы на длинной ленте, которая проматывается через окно контейнера? Или я что-то путаю?

Почему бы тебе тогда не использовать ScrollView в качестве контейнера?
Можно также посмотреть код FormView.

Насчет ресайза я, конечно, имела в виду, что каждый, кто получает WM_SIZE, вызывает SizeWindow или MoveWindow (или лучше SetWindowPos) только для своих непосредственных детей, они, соответственно - своих и т.д.

Точно. Только еще эти диалоги могут сворачиваться и разворачиваться пользователем

А разве нет проблем присоздании на диалоге ScrollView? Просто добавил класс и все?