Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

проблема с TActionList.OnUpdate в Dll

Starkom © (2002-11-27 08:43:00)
Есть панелька инструментов на форме. Все enabled обновлялись через ActionListUpdate. Все работало. Затем форму завернули в Dll, и ActionListUpdate перестал вызываться тогда, когда нужно!
Помогите, пожалуйста!

asmith (2002-11-27 21:27:00) [1]
Да, все работать будет, если не делать резких движений. Сегодня, например, в одном из сообщений по другомк поводу мелькнул совет передать в Dll объекты Application и Screen и присвоить их значение соответствующим объектам в Dll. Так вот если с Application все прошло успешно (он просто устроен), то при присвоении Screen выскочило исключение что-то типа "Cannot Assign Font Property". Т. е. объект имеет проперть объектного типа, но присвоение невозможно ввиду формально разных типов. Я не комментирую смысл этого совета - это лишь пример ситуации, когда в Dll передается ссылка на объект и что его может там поджидать.

Fantasist (2002-11-27 20:39:00) [2]

> . Об одном здесь идет речь-перестают вызываться ActionListUpdate.
> Другой такой эффект - из Dll в апликацию подгружаются динамически
> формы, которые внедряются как дочерние окна в окно апликации,
> нарушается порядок обхода контролов по Tab

И что, все эти проблемы завязанны на RTTI? Ведь классы хоть и получаются разного типа для RTTI в отдельно скомпилированных модулях, но код-то идентичен. То есть методы класса имеют один и тот же код. Ну, может, он не идентичен за счет разной оптимизации, но результат его выполнения должен быть абсолютно одинаков.

asmith (2002-11-27 18:01:00) [3]
Простейший пример - апликация с формой и Dll с формой; компилируются раздельно, в коде каждой "живет" класс TForm со своей таблицей виртуальных методов (VMT). Если выполнять в Dll проверку типов (оператором is) экземпляра объекта, созданного в апликации и переданного в Dll, будут просто сравниваться адреса двух VMT, которые не равны в принципе. В этом суть - разные VMT объектов вроде одного типа. Если билдить с run-time packages (кстати, нужно выбрать "правильные", чтобв в них входили те классы, что нас интересуют), то соответствующие VMT будут присутствовать лишь в одном экземпляре - в коде packages. А по поводу того, что "TStringList прекрасно передается" скажу следующее - прекрасно передается, и не только он. Но вот только переданный объект известного типа стает как бы не таким и не того типа. При этом возникают разные побочные эффекты. Об одном здесь идет речь-перестают вызываться ActionListUpdate. Другой такой эффект - из Dll в апликацию подгружаются динамически формы, которые внедряются как дочерние окна в окно апликации, нарушается порядок обхода контролов по Tab. Build with run-time packages решает эти проблемы.

Starkom (2002-11-27 16:19:00) [4]
2 Sergic: почему же эта галочка приводит к очень сильным различиям в поведении проекта?

Sergic (2002-11-27 15:57:00) [5]
Build with run-time pakceges означает, что вместо статического подключения всех модулей к exe или dll, будет использоваться возможность динамического подключения этих пакетов. На практике это означает, что вместе с приложением необходимо распространять пакеты времени выполнения (.bpl). Размер самого exe или dll в этом случае резко уменьшается, но есть одно но! Например вес vcl60 почти 2 Мб.

Starkom (2002-11-27 15:25:00) [6]
2 asmith: и вообще, в чем смысл галочки build with runtime packages? Нигде найти не могу внятного ответа.

Starkom (2002-11-27 13:07:00) [7]
2 asmith: TStringList прекрасно передается. У нас тут все основано на передаче стринглистов.

asmith (2002-11-27 12:52:00) [8]
Можно оставить DLL, но обязатель собрать апликацию и либу с runtime packages (ИМНО достаточно vcl, rtl). Фокусы с передачей ссылок на объекты в Dll не проходят. Попробуйте, например, передать в Dll объект TSomeObject, а потом запросите его тип или проверьте оператором is.

Starkom (2002-11-27 10:40:00) [9]
а зачем, вообще, этот Screen нужен?

Starkom (2002-11-27 10:10:00) [10]
procedure InitLib(App,Scr:pointer);cdecl; begin pApp :=Application; pScr :=Screen; Application :=App; Screen :=Scr; end;
соответственно exports InitLib;
из exe вызываем InitLib(Application, Screen), получаем в Dll при конструировании формы ConvertError TFont to TFont.
exe билдерный.

Юрий Зотов (2002-11-27 09:33:00) [11]
Еще мысль - попробуйте в Dll переопределять не Application.Handle, а весь Application (и Screen заодно). Только перед завершением программы (или выгрузкой Dll) восстановите прежние значения.

Starkom (2002-11-27 09:25:00) [12]
2 Юрий Зотов: в ближайшем будущем, нет :(( Когда-нибудь потом, обязательно, если вообще еще на связке билдер-дельфи останемся.

Юрий Зотов (2002-11-27 09:19:00) [13]
Возможна замена Dll на BPL? Это должно снять проблему.

Starkom (2002-11-27 09:16:00) [14]
2 Юрий Зотов: присваиваю - не помогает.

Юрий Зотов (2002-11-27 08:55:00) [15]
Попробуйте проинициализировать Dll таким образом:

procedure InitDll(AppHandle: THandle);
begin
Application.Handle := AppHandle
end;

exports
InitDll;

И вызов из Exe:
InitDll(Application.Handle);

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »