Здраствуйте.
У меня возникла проблема. Есть приложение (содержит одну форму типа MDIForm), которое использует функцию (описана в DLL) создания и вывода на экран формы типа MDIChild, хранящейся в DLL. Вот код:

Код функции в DLL:

...
TApplication* a_DLLApplication = NULL;
...
void __stdcall DLL_EXP f_ChildWindow(TApplication* a_Calling)
{
  if (!a_DLLApplication && a_Calling)
  {
    a_DLLApplication = Application;
    Application = a_Calling;
  }

  frm_Child = new Tfrm_Child(Application);

  frm_Child->Show();
}

Код DllEntryPoint

BOOL WINAPI DllEntryPoint(HINSTANCE hinstDLL, DWORD fwdreason, LPVOID lpvReserved)
{
  if (fwdreason == DLL_PROCESS_DETACH && a_DLLApplication)
    Application = a_DLLApplication;

  return 1;
}

Обработчик OnClose главной формы приложения:

void __fastcall Tfrm_Main::FormClose(TObject *Sender, TCloseAction &Action)
{
  while(MDIChildCount)
    MDIChildren[0]->Free();

  if (h_Dll)
    FreeLibrary(h_Dll);
}

А теперь собственно проблема, заключающаяся в обработчике OnCLose... Если поставить галочки "Use dynamic RTL" и "Build with runtima packages" в настройках проектов, то все работает просто замечательно, т.е. MDIChildCount содержит число созданных дочерних окон и приложение нормально завершается, если не закрыть предварительно эти дочерние окна. Если галочки снять, то MDIChildCount всегда равно 0 и приложение не завершается корректно, если предварительно на закрыть все дочерние окна. Вылетает просто офигенное исключение. Дело в том, что первый вариант мне не подходит, т.к. прога будет юзаться на машине без Builder'а. Подскажите, плиз, где я ошибся, как это исправить, и можно ли вообще.

Здравствуйте, Blade, Вы писали:

B>А теперь собственно проблема, заключающаяся в обработчике OnCLose... Если поставить галочки "Use dynamic RTL" и "Build with runtima packages" в настройках проектов, то все работает просто замечательно, т.е. MDIChildCount содержит число созданных дочерних окон и приложение нормально завершается, если не закрыть предварительно эти дочерние окна. Если галочки снять, то MDIChildCount всегда равно 0 и приложение не завершается корректно, если предварительно на закрыть все дочерние окна. Вылетает просто офигенное исключение. Дело в том, что первый вариант мне не подходит, т.к. прога будет юзаться на машине без Builder'а. Подскажите, плиз, где я ошибся, как это исправить, и можно ли вообще.

Все, что пришло мне в голову: может быть, ты в .exe-шнике отключил эти галочки, а в dll-ке нет или наоборот...

Здравствуйте, AkaSaint, Вы писали:

AS>Все, что пришло мне в голову: может быть, ты в .exe-шнике отключил эти галочки, а в dll-ке нет или наоборот...

В том то и проблема, что изначально все галочки в обоих проектах были отключены. Потом мне попалась на глаза литературка, где автор НАСТОЯТЕЛЬНО рекомендует их включить (опять же в обоих проектах), иначе ничего не получится. Я это проделал, и все заработало. Но меня такой вариант (еще раз уточню) не устраивает, т.к. прога должна работать на машине без Builder'а. После этого я перепробовал все возможные сочетания наличия и отсутствия галочек в проекте. Ничего более не работает.

Здравствуйте, Blade, Вы писали:

B>... т.к. прога должна работать на машине без Builder'а. После этого я перепробовал все возможные сочетания наличия и отсутствия галочек в проекте. Ничего более не работает.

А она и будет работать без Buildera, Вы только создайте нормальный Setup с помощью InstallShield куда и войдут все dll-и и bpl-и.

Здравствуйте, VSlava, Вы писали:

VS>А она и будет работать без Buildera, Вы только создайте нормальный Setup с помощью InstallShield куда и войдут все dll-и и bpl-и.

А есть смысл таскать за собой кучу DLL и BPL ?? Я не вижу. И этот вариант меня собственно тоже не устраивает.

Здравствуйте, Blade, Вы писали:

B>Здравствуйте, VSlava, Вы писали:

VS>А она и будет работать без Buildera, Вы только создайте нормальный Setup с помощью InstallShield куда и войдут все dll-и и bpl-и.

B> А есть смысл таскать за собой кучу DLL и BPL ?? Я не вижу. И этот вариант меня собственно тоже не устраивает.
А что, Borland настолько улучшила линкер, что заметна разница Exe + RTL супротив Ехе, в который включена RTL???
С точки зрения пользователя, лучше иметь библиотеки в DLL. Т.к. есть ненулевой шанс получить два и более приложений, использующих то же самое. И вовсе незачем эти пару метров хранить на диске в N экземплярах. Не говоря уже о повышении эффективности использования физической памяти.

Здравствуйте, Sinclair, Вы писали:

S>А что, Borland настолько улучшила линкер, что заметна разница Exe + RTL супротив Ехе, в который включена RTL???
S>С точки зрения пользователя, лучше иметь библиотеки в DLL. Т.к. есть ненулевой шанс получить два и более приложений, использующих то же самое. И вовсе незачем эти пару метров хранить на диске в N экземплярах. Не говоря уже о повышении эффективности использования физической памяти.

Я вообще-то не просил объяснять мне эти различия (прошу прощения). Дело в том, что у меня есть руководство, и есть регламентированные правила (!), из-за которых я и уточнил, что такой вариант меня тоже не устравивает. И потом, приложение, содержащее порядка 2 десятков библиотек будет таскать за собой еще и Борландовские?! Мне кажется, это уже слишком. Что касается лишних метров, то при нынешних объемах HDD я думаю не стоит задумываться о хранении лишних 2 метров, тем более, что это сказывается еще и на скорости работы!

Здравствуйте, Sinclair

... и еще... Кроме RTL придется таскать за собой еще и Runtime пакеты...

Здравствуйте, Blade, Вы писали:

B>Я вообще-то не просил объяснять мне эти различия (прошу прощения). Дело в том, что у меня есть руководство, и есть регламентированные правила (!), из-за которых я и уточнил, что такой вариант меня тоже не устравивает. И потом, приложение, содержащее порядка 2 десятков библиотек будет таскать за собой еще и Борландовские?! Мне кажется, это уже слишком. Что касается лишних метров, то при нынешних объемах HDD я думаю не стоит задумываться о хранении лишних 2 метров, тем более, что это сказывается еще и на скорости работы!
Не буду с этим спорить. Задам один простой вопрос: а билдер умеет делать BPL вместо DLL? Если да, то нужно в срочном порядке сконвертировать library в package и использовать его. Тогда все встанет на свои места.

Здравствуйте, Sinclair, Вы писали:

S>Не буду с этим спорить. Задам один простой вопрос: а билдер умеет делать BPL вместо DLL? Если да, то нужно в срочном порядке сконвертировать library в package и использовать его. Тогда все встанет на свои места.

Умеет. А можно ли их будет потом использовать и в Delphi? И все-таки... Хотелось бы, чтоб это были DLL и не надо было бы таскать за собой борландовские библиотеки.

Здравствуйте, Blade, Вы писали:

B>Умеет. А можно ли их будет потом использовать и в Delphi?
Да.
И все-таки... Хотелось бы, чтоб это были DLL и не надо было бы таскать за собой борландовские библиотеки.
Это неправильное желание. Ну зачем вам DLL? Все равно борландовые DLL не совместимы с чужими. А так вы получите значительно преимущество в виде гарантии стабильной работы VCL. В качестве бонуса вы получите уменьшение размера BPL по сравнению с DLL:
EXE + DLL, no runtime packages, конфликт из-за двух копий VCL:

+-----+  +-----+  
| EXE |  | DLL |
|+---+|  |+---+|
||VCL||  ||VCL||
|+---+|  |+---+|
+-----+  +-----+

EXE + DLL, use runtime packages, таскаем доп. библиотеки:

+-----+ +-----+  
| EXE | | DLL |
+-----+ +-----+
   \ +---+ /
     |VCL|
     +---+

EXE + BPL, use runtime packages, те же вид сбоку:

+-----+ +-----+  
| EXE | | BPL |
+-----+ +-----+
   \ +---+ /
     |VCL|
     +---+

EXE + BPL, No runtime packages — ответ на все вопросы.

+-----+ +-----+  
| EXE | | BPL |
|+---+|/+-----+
||VCL|/
|+---+|
+-----+

Здравствуйте, Sinclair:

Вот теперь я вижу совет по решению моей проблемы. Хотя и не совсем так как хотелось бы . Пожалуй соглашусь, что это более реальный выход из сложившейся ситуации. Но не согласен с одним Вашим утверждением, а именно: "борландовские DLL не совместимы с др." — это не так. Я юзал их из Visual C++, ORACLE Developer'а. Правда это были DLL без дочерних форм (тока модальные диалоги), но все работало. Вот так. А за совет еще раз спасибо, буду пробовать.

Здравствуйте, Sinclair.

Сделал я пакет. Пользовался литературкой, где конкретно описано, как создавать пакеты с дочерними формами. Однако... При попытке создать форму (дочернюю, хранящуюся в пакете) возникает исключение с сообщением "Cannot create form. No MDI forms are currently active.".