FastReport VCL & DLL

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

Комментарии

  • отредактировано 03:37
    написал:
    Если на форме оставить только frReport и frPreview трабла нет.
    На какой форме? Что вы имеете в виду?

    Вы используете bpl?
  • отредактировано 03:37
    Нет bpl я не использую. Сама dll содержит форму, FormStyle=MdiChild (ест-но главная форма вызывающего приложения FormStyle=MdiForm), на этой форме размещены компоненты FR (FrReport, FrPreview, FrDataSet, FrCheckBox,FrChar и пр.). Если оставить только FrReport, FrPreview все работает отлично, но без FrDataSet и др. комп. не обойтись никак, сами понимаете. Даже если не размещать компоненты, а в uses добавить имена соотв. модулей (что собс-нно и делают комп-ты FR), трабл остается.
  • отредактировано 03:37
    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, которая и будет строить отчет...
  • отредактировано 03:37
    Рекомендую почитать статью
    Она поможет вам разобраться с dll-ками.
  • отредактировано 03:37
    написал:
    Рекомендую почитать статью
    Она поможет вам разобраться с dll-ками.
    Да, многие рекомендуют как плагины использовать механизм пакетов... Но там тоже есть свои недостатки...

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

    Вставил проверку if assigned(Screen), TeeChart сам по себе заработал вроде...
    Теперь осталось вроде только перекомпилить FR_Chart ;)
  • отредактировано 03:37
    если 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
  • отредактировано 03:37
    написал:
    Да, многие рекомендуют как плагины использовать механизм пакетов... Но там тоже есть свои недостатки...
    Интересно какие?
    Я использовал такую технология. Между dll-ками передавал и строки и типы. Никаких проблем не было.
  • отредактировано 03:37
    написал:
    написал:
    Да, многие рекомендуют как плагины использовать механизм пакетов... Но там тоже есть свои недостатки...
    Интересно какие?
    Я использовал такую технология. Между dll-ками передавал и строки и типы. Никаких проблем не было.
    взято отсюда
    * Практически невозможность дальнейшего сопровождения. При любом изменении виртуальной таблицы методов (VMT) базового класса - пакеты, их использующие, становятся неработоспособными. И даже более того - опасными!
    * Условная взаимозаменяемость. Так или иначе, придется скрупулезно проверять вызов каждой функции и каждого метода.
    * "Усложненность" разработки. Как показывает практика, при уровне "наследуемости" пакетов больше трех процесс компиляции понравится только мазохистам (а если учесть 1 пункт, то проще на все плюнуть )
  • отредактировано June 2005
    Я считаю, что эти недостатки устраняются правильным проектирование своего приложения.

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

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

Оставить комментарий

Многофункциональный текстовый редактор. Чтобы отредактировать стиль параграфа, нажмите TAB, чтобы перейти к меню абзаца. Там вы можете выбрать стиль. По умолчанию не выбран ни один стиль. Когда вы выберете текст, появится встроенное меню форматирования. Нажмите TAB, чтобы войти в него. Некоторые элементы, такие как многофункциональные вставки ссылок, картинок, индикаторов загрузки и сообщений об ошибок могут быть вставлены в редактор. Вы можете перемещаться по ним, используя стрелки внутри редактора и удалять с помощью клавиш delete или backspace.