Собственно, сабж.
Обычное и модальное окна создаются на ура (предварительно заменяется Application.Handle и все).
А вот с MDI фокус не проходит, ругается что 'Cannot create form. No MDI forms are currently active.'.
Естетсвенно у главной формы FOrmStyle стоит в fsMDIForm.

Если у кого-то фокус получился - расскажите, пожалуйста.

Prog2 MichaelЕсли бы. Тестовый проект. Там всего одна форма, которая по умолчанию является главной.
А что значит она не имеет MDIClient-окна?

Я полагаю, ты обнаружишь исчезновение всех проблем, как только начнешь собирать приложение и его dll-ки с run-time package'ами. Альтернативная практика.. Скажем так, борландеры вряд ли когда-нибудь всерьез предполагали, что кто-нибудь будет пытаться работать с приложением, каждая часть которого тащит свою копию VCL; при этом идет уйма проблем, часть из которых решается хакерскими способами (типа твоей передачи Application.Handle), а часть нормально не решается. Но главное - нет практически никаких причин тратить на это время; если есть необходимость добиваться межверсионной совместимости, гораздо проще сделать в основной программе пару необходимых "оберток" и работать, например, через ParentWindow.

По опыту: проект размером в пару человеко-лет я перевел с подобной схемы на использование package'ей за пол-дня. После того как начальство отчаялось исправить хакерским путем проблему, в то время как новую версию требовалось срочно отослать заказчику.

У меня нормально проходило после того, как в DLL-ке перед созданием форм делаешь замену переменных Application и Screen на экземпляры родительской программы.

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

Да, и ещё - для D6 и D7 есть проблемы с обработкой хинтов, возникающих в дочерних окнах. Почему - опять же не разбирался. Попросту компилировал проект с чуть более старыми версиями Forms.pas и Controls.pas.

Spirit-1
D Delphi 7 получилось! И меню со списком окон вроде как нормально обновляется.
Спасибо!

ПыСы Если что, еще напишу...

Добавление от 23.03.2004 09:32:

Подробности: необходимо перед переназначением сохранить Application и Screen в DLL, а при закрытии MDI-окна восстановить обратно. Один ньюанс: процедуру закрытия необходимо вызывать и в OnClose основной формы, т.к. при закрытии основного окна не закрыв предварительно дочерние, у них не отрабатывает OnClose.

Объясни все же: зачем долго и мучительно делать version-specific код, если можно обойтись парой щелчков мыши. Для спортивного интереса?

Softwarer
runtime packages - не есть хорошо, имхо. Это легко понять после того, как начинаешь распространять свои программы. Для не очень больших систем размер дистрибутива критичен.

Softwarer
Почему version-specific? Application и Screen всегда были и есть.

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

Безусловно, для небольших утилит runtime packages не нужны. Но и писать для них dll-ки также скорее вредно, даже если одна dll-ка используется в нескольких приложениях. Сравни, скажем (не поверишь, но числа не подбирал, старался заложить как раз довольно мягкий случай, всего с двумя dll, каждая из которых используется во всех трех приложениях и с большим собственным кодом в них):

---

Вариант без dll-ек:

Приложение1 (100Кб) Длл1 (50Кб) Длл2 (50Кб) СтандартныйКод(350Кб) = 550Кб
Приложение2 ---- аналогично -----
Приложение3 ---- аналогично -----

Итого: 1650Кб

---

Вариант с dll-ками:

Приложение1 (100Кб) СтандартныйКод (300Кб) = 400Кб
Приложение2 ---- аналогично ----
Приложение3 ---- аналогично ----
BORLNDMM.DLL (или как там его) - не помню сколько, допустим, 50Кб
Длл1 (50Кб) СтандартныйКод (250Кб) = 300Кб
Длл2 (50Кб) СтандартныйКод (200Кб) = 250Кб
Итого: 1800Кб.

---

И в любом случае, vcl-ные dll не предоставляют столько преимуществ, сколько требуют неудобств при подобной хакерской практике. Виндовые хуки, конечно, без них не работают.. но никто не мешает написать для них нормальную dll-ку, не использующую vcl и динамических типов данных.

Добавление от 23.03.2004 13:04:

Были и есть. Но никто не гарантирует, что в любой следующей версии не понадобится дополнительных действий или наоборот - отсутствия каких-либо действий.

Собственно, даже есть пример - как это все будет работать с поддержкой нескольких мониторов, появившейся, кажется, в D6? Уверен, что ничего больше не придется копировать?

Обрати внимание, скажем, на первое письмо от Spirit-1 - от того, что нормально хакающий D5 код ты откомпилируешь под D7, он не перестанет компилиться, но возникнет более или менее скрытая проблема с непредсказуемым проявлением. Скажем, "Да, и ещё - для D6 и D7 есть проблемы с обработкой хинтов, возникающих в дочерних окнах" может означать access violation, вылетающий у тебя в коде в месте, где ты сам пытаешься сделать что-то с хинтами.

Softwarer
Возможно, что это правда легче.
Но как обычный пользователь я бы таких программеров поубивал - у меня в системной папке виндюков уже столько разных run-time package-й скопилось, что в пору всю систему под ноль переставлять. Отсюда и любовь пусть и к немного раздутым программам, но не раздувающим системные папки.

Всё это ИМХО, конечно.

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

Совсем по-хорошему стоило бы ставить их куда-нибудь в Borland Shared - я имею в виду опять же стандартные. Но тут, к сожалению, есть недоработка винды, которая позволяет дополнять список путей для поиска dll только через path.