FastReport VCL & DLL
Есть проблема:
версия 2.47
приложение работает с DLL в которой есть MDIChild форма. На ней размещаю
компоненты FR. Все компилируется нормально.
Динамически загружаю DLL.
Отчет строится нормально.
Выгружаю DLL.
Закрываю приложение и тут трабл: "Память не может быть Read".
Если на форме оставить только frReport и frPreview трабла нет.
Спасибо.
версия 2.47
приложение работает с DLL в которой есть MDIChild форма. На ней размещаю
компоненты FR. Все компилируется нормально.
Динамически загружаю DLL.
Отчет строится нормально.
Выгружаю DLL.
Закрываю приложение и тут трабл: "Память не может быть Read".
Если на форме оставить только frReport и frPreview трабла нет.
Спасибо.
Комментарии
Вы используете bpl?
Проблема именно в том, что форма в DLL - MDI Child, и используется FR_Chart, который в свою очередь использует TeeProcs, TeEngine, Chart, Series.
Именно из-за попытки использования этих модулей из пакета ТeeСhart форма MDI Child, помещенная в DLL, работает не корректно.
Я вот только-только наступил на эти же грабли, потому как их уверенно обойти - не знаю.
Пока есть в уме два варианта:
- приобрести исходники ТeeСhart-а, и расколупать его
- из MDI-формы вызывать еще одну DLL, в которой нет MDI-форм, и размещать FR-компоненты в этой дополнительной DLL, которая и будет строить отчет...
Она поможет вам разобраться с dll-ками.
По теме: ошибка появляется в модуле TeeProcs, в разделе finalization, на строчке
Screen.Cursors[crTeeHand]:=NullCursor;
Ну оно и понятно - если MDI форма выгружается, то Screen на момент выполнения finalization будет уже nil-ом.
Вставил проверку if assigned(Screen), TeeChart сам по себе заработал вроде...
Теперь осталось вроде только перекомпилить FR_Chart
см справку TApplication - Handle
Я использовал такую технология. Между dll-ками передавал и строки и типы. Никаких проблем не было.
* Практически невозможность дальнейшего сопровождения. При любом изменении виртуальной таблицы методов (VMT) базового класса - пакеты, их использующие, становятся неработоспособными. И даже более того - опасными!
* Условная взаимозаменяемость. Так или иначе, придется скрупулезно проверять вызов каждой функции и каждого метода.
* "Усложненность" разработки. Как показывает практика, при уровне "наследуемости" пакетов больше трех процесс компиляции понравится только мазохистам (а если учесть 1 пункт, то проще на все плюнуть )
"уровень наследуемости пакетов больше трех" - это по-моему уже само по себе мазохизм.
Как делал я: одна bpl-ка в которой мои общии классы для всего приложения. Отдельно в dll-ках реализованны логические модули, которые без проблем взаимодействуют с главной формой и между собой (через интерфейсы). Всё это, естественно, компилилось с опцией "build with runtime packages" (и я не заботился о каких то там хендлах)