FastReport VCL & DLL

Комментарии

• -=Serg=-

  April 2005 отредактировано 01:54

  написал:

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

  На какой форме? Что вы имеете в виду?
  
  Вы используете bpl?
• HSimpson

  April 2005 отредактировано 01:54

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

  June 2005 отредактировано 01:54

  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=-

  June 2005 отредактировано 01:54

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

  June 2005 отредактировано 01:54

  написал:

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

  Да, многие рекомендуют как плагины использовать механизм пакетов... Но там тоже есть свои недостатки...
  
  По теме: ошибка появляется в модуле TeeProcs, в разделе finalization, на строчке
  Screen.Cursors[crTeeHand]:=NullCursor;
  Ну оно и понятно - если MDI форма выгружается, то Screen на момент выполнения finalization будет уже nil-ом.
  
  Вставил проверку if assigned(Screen), TeeChart сам по себе заработал вроде...
  Теперь осталось вроде только перекомпилить FR_Chart
• Vlad_p

  June 2005 отредактировано 01:54

  если 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=-

  June 2005 отредактировано 01:54

  написал:

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

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

  June 2005 отредактировано 01:54

  написал:

  написал:

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

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

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

  June 2005 отредактировано June 2005

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