FastReport VCL & DLL

HSimpson

Есть проблема:
версия 2.47
приложение работает с DLL в которой есть MDIChild форма. На ней размещаю
компоненты FR. Все компилируется нормально.
Динамически загружаю DLL.
Отчет строится нормально.
Выгружаю DLL.
Закрываю приложение и тут трабл: "Память не может быть Read".
Если на форме оставить только frReport и frPreview трабла нет.
Спасибо.

-=Serg=-

написал:

Если на форме оставить только frReport и frPreview трабла нет.

На какой форме? Что вы имеете в виду?

Вы используете bpl?

HSimpson

Нет bpl я не использую. Сама dll содержит форму, FormStyle=MdiChild (ест-но главная форма вызывающего приложения FormStyle=MdiForm), на этой форме размещены компоненты FR (FrReport, FrPreview, FrDataSet, FrCheckBox,FrChar и пр.). Если оставить только FrReport, FrPreview все работает отлично, но без FrDataSet и др. комп. не обойтись никак, сами понимаете. Даже если не размещать компоненты, а в uses добавить имена соотв. модулей (что собс-нно и делают комп-ты FR), трабл остается.

AlPet®

HSimpson написал:

Нет bpl я не использую. Сама dll содержит форму, FormStyle=MdiChild (ест-но главная форма вызывающего приложения FormStyle=MdiForm), на этой форме размещены компоненты FR (FrReport, FrPreview, FrDataSet, FrCheckBox,FrChar и пр.). Если оставить только FrReport, FrPreview все работает отлично, но без FrDataSet и др. комп. не обойтись никак, сами понимаете. Даже если не размещать компоненты, а в uses добавить имена соотв. модулей (что собс-нно и делают комп-ты FR), трабл остается.

У меня те же грабли.
Проблема именно в том, что форма в DLL - MDI Child, и используется FR_Chart, который в свою очередь использует TeeProcs, TeEngine, Chart, Series.
Именно из-за попытки использования этих модулей из пакета ТeeСhart форма MDI Child, помещенная в DLL, работает не корректно.
Я вот только-только наступил на эти же грабли, потому как их уверенно обойти - не знаю.
Пока есть в уме два варианта:
- приобрести исходники ТeeСhart-а, и расколупать его
- из MDI-формы вызывать еще одну DLL, в которой нет MDI-форм, и размещать FR-компоненты в этой дополнительной DLL, которая и будет строить отчет...

-=Serg=-

Рекомендую почитать статью
Она поможет вам разобраться с dll-ками.

AlPet®

написал:

Рекомендую почитать статью
Она поможет вам разобраться с dll-ками.

Да, многие рекомендуют как плагины использовать механизм пакетов... Но там тоже есть свои недостатки...

По теме: ошибка появляется в модуле TeeProcs, в разделе finalization, на строчке
Screen.Cursors[crTeeHand]:=NullCursor;
Ну оно и понятно - если MDI форма выгружается, то Screen на момент выполнения finalization будет уже nil-ом.

Вставил проверку if assigned(Screen), TeeChart сам по себе заработал вроде...
Теперь осталось вроде только перекомпилить FR_Chart

Vlad_p

если exe и dll собраны Борландом можно попробовать перекинуть хендл главного окна приложения в dll

написал:

Note: When writing a DLL that uses VCL forms, assign the window handle of the host EXE’s main window to the DLL’s Application.HandleApplication->Handle property. This makes the DLL’s form part of the host application. Never assign to the Handle property in an EXE.

см справку TApplication - Handle

-=Serg=-

написал:

Да, многие рекомендуют как плагины использовать механизм пакетов... Но там тоже есть свои недостатки...

Интересно какие?
Я использовал такую технология. Между dll-ками передавал и строки и типы. Никаких проблем не было.

AlPet®

написал:

написал:

Да, многие рекомендуют как плагины использовать механизм пакетов... Но там тоже есть свои недостатки...

Интересно какие?
Я использовал такую технология. Между dll-ками передавал и строки и типы. Никаких проблем не было.

взято отсюда
* Практически невозможность дальнейшего сопровождения. При любом изменении виртуальной таблицы методов (VMT) базового класса - пакеты, их использующие, становятся неработоспособными. И даже более того - опасными!
* Условная взаимозаменяемость. Так или иначе, придется скрупулезно проверять вызов каждой функции и каждого метода.
* "Усложненность" разработки. Как показывает практика, при уровне "наследуемости" пакетов больше трех процесс компиляции понравится только мазохистам (а если учесть 1 пункт, то проще на все плюнуть )

-=Serg=-

Я считаю, что эти недостатки устраняются правильным проектирование своего приложения.

"уровень наследуемости пакетов больше трех" - это по-моему уже само по себе мазохизм.

Как делал я: одна bpl-ка в которой мои общии классы для всего приложения. Отдельно в dll-ках реализованны логические модули, которые без проблем взаимодействуют с главной формой и между собой (через интерфейсы). Всё это, естественно, компилилось с опцией "build with runtime packages" (и я не заботился о каких то там хендлах)