Всем доброго времени суток!

В общем суть такова. Имеется два проекта на C++ Builder - один из них родительское приложение, второй - дочернее. Родительское приложение запускает дочерний процесс через ShellExecute(), а дочернее назначает свое главное окно дочерним по отношению к главному окну родительского приложения, через функцию SetParent().
На этом моменте все работает нормально - главное окно дочернего приложения становится дочерним MDI-окном главного окна родительского приложения, и отображается в его рабочей области.
Проблема в том, что формы дочернего приложения, которые должны открываться (показываться) как модальные диалоговые (через ShowModal()) перестали быть таковыми. Т.е. стиль границ окна остался как у диалогового окна (в заголовке только кнопка "Закрыть" и блокируется возможность изменения размеров окна), но вот "модальность" исчезла. Выражается это в том, что главное окно, запускающее диалог активно (Enabled) и пользователь, по сути, может второй раз попытаться вызвать тот же диалог, что приводит к ошибке. Пытался дизаблить основное окно через EnableWindow(this->GetParentHandle(), FALSE) в обработчике OnShow() диалога, но оно по-прежнему остается доступным для пользователя. Во-вторых, исчезла привязка диалогового окна к основному, т.е. при попытке свернуть окно родительского приложения, оно сворачивается вместе с дочерним, а диалоговое окно остается на экране.

Подскажите, как вернуть "модальность" диалоговым окнам дочернего приложения?

Спасибо!

Подскажите, тогда, как в WinAPI задать владельца окна (Owner), или установить привязку одного окна к другому. Насколько я понимаю, у диалоговых окон должен быть владелец, так вот, каким образом задать этого владельца для уже созданного диалогового окна?

Уже весь мозг сломал, и начал запутываться вконец :((

В общем результат должен быть таким: Запускается приложение, которое способно скрываться в трей. В этом приложении, нажатием на кнопку запускается второе приложение (как модуль). Его окно становится дочерним MDI-окном первого приложения, и, по сути, эти два приложения должны работать как единое целое. При сворачивании первого (основного) приложения на панель задач или скрывании его в трей, в месте с ним скрывается и дочернее MDI-окно второго приложения.
На этом этапе все работает как требуется. Дальше, во втором приложении, могут открываться различные диалоговые окна, которые перестают быть таковыми после того, как основное окно становится дочерним - все диалоговые окна становятся оторванными, не привязанными ни к чему. При сворачивании первого приложения, если было открыто какое-либо окно во втором приложении, оно остается на экране (кроме основного окна), а должно тоже сворачиваться вместе со всеми окнами.

Не пойму как указать что владельцем конкретного диалогового окна является главное окно, которое является дочерним окном для окна первого приложения, и оно должно тоже сворачиваться при сворачивании владельца, прятаться при скрывании владельца (SW_HIDE) и владелец должен быть дизабленным пока не закроется диалог

MasterZivfreebits,

Подскажите, как вернуть "модальность" диалоговым окнам дочернего приложения?

Все — в одно приложение, срочно, пока еще чего-то не натворил.

Переход на одно большое приложение исключен в виду нецелесообразности. Требуется модульная схема с динамической загрузкой модулей, т.е. веся система состоит из 4 модулей, которые имеют разное назначение, но доступ к ним должен осуществляться централизовано и ограничиваться правами (полномочиями) доступа посредством авторизации в общем окне. Другими словами, администратор системы имеет доступ ко всем четырем модулям. Другой группе лиц для работы в системе требуется только один модуль, а доступ к остальным абсолютно не нужен, и для них он должен быть исключен.

Вот это, грубо говоря, ТЗ. Если вы видите другое решение, с удовольствием выслушаю. Все 4 модуля уже написаны и отлажены в виде отдельных приложений. Осталось их связать в единую систему, с общей схемой распределения полномочий, общими правилами доступа к данным, общей настройкой и т.п.

MasterZivfreebits,

Твои окна не перестали быть модальными они просто модальные для одного приложения.

Если бы это было так, меня бы все устраивало. По сути, приложения выполняются раздельно и для них все осталось так же, требуется просто визуально отобразить как одно приложение и все. Что в этом такого?

MasterZivВладелец окна pop up/overlapped — это просто его parent. Это оно и то же поле окна, просто у child оно называется parent, а у остальных окон - owner.

msdn.microsoft.com/en-us/library/ms632599(v=VS.85).aspx#owned_windows

Спасибо за ссылку. На выходных более внимательно изучу windows management и более объективно оценю возможность реализации задуманного. Спасибо за помощь.

[quot MasterZiv]авторПереход на одно большое приложение исключен в виду нецелесообразности. Требуется модульная схема с динамической загрузкой модулей,

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

MasterZivУ тебя в ТЗ прямо так и написано "сделать всё как разные приложения" ?

Нет. Скажем так, заказчику не важно сколько там приложений, он в этом не понимает и проверять не будет. Важен результат.

MasterZivЕсть какие-то предпосылки, чтобы это было не одно приложение ?
Может быть есть что-то, что ты не можешь сделать, если это будет одно приложение а не 10?




Только сроки.

MasterZiv
Ну, сделай из них .dll-и, из каждого приложения. Ты даже можешь сделать условную компиляцию и собирать из них в одном случае приложения, в другом -- библиотеки для загрузки в основное приложение.


чтобы скомпилить проекты как библиотеки dll, их нужно практически полностью перелопатить, заново тестить и отлаживать, таким временем я не располагаю, решил пойти по кратчайшему пути, но он тоже затягивается...

Спасибо за ваш вариант решения задачи.

MasterZivТолько сроки.


ДА не надо ничего перелопачивать.

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