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

← →
Starkom (2002-11-27 08:43) [0]

Есть панелька инструментов на форме. Все enabled обновлялись через ActionListUpdate. Все работало. Затем форму завернули в Dll, и ActionListUpdate перестал вызываться тогда, когда нужно!
Помогите, пожалуйста!

← →
Юрий Зотов (2002-11-27 08:55) [1]

Попробуйте проинициализировать Dll таким образом:

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

exports
InitDll;

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

← →
Starkom (2002-11-27 09:16) [2]

2 Юрий Зотов: присваиваю - не помогает.

← →
Юрий Зотов (2002-11-27 09:19) [3]

Возможна замена Dll на BPL? Это должно снять проблему.

← →
Starkom (2002-11-27 09:25) [4]

2 Юрий Зотов: в ближайшем будущем, нет :(( Когда-нибудь потом, обязательно, если вообще еще на связке билдер-дельфи останемся.

← →
Юрий Зотов (2002-11-27 09:33) [5]

Еще мысль - попробуйте в Dll переопределять не Application.Handle, а весь Application (и Screen заодно). Только перед завершением программы (или выгрузкой Dll) восстановите прежние значения.

← →
Starkom (2002-11-27 10:10) [6]

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 билдерный.

← →
Starkom (2002-11-27 10:40) [7]

а зачем, вообще, этот Screen нужен?

← →
asmith (2002-11-27 12:52) [8]

Можно оставить DLL, но обязатель собрать апликацию и либу с runtime packages (ИМНО достаточно vcl, rtl). Фокусы с передачей ссылок на объекты в Dll не проходят. Попробуйте, например, передать в Dll объект TSomeObject, а потом запросите его тип или проверьте оператором is.

← →
Starkom (2002-11-27 13:07) [9]

2 asmith: TStringList прекрасно передается. У нас тут все основано на передаче стринглистов.

← →
Starkom (2002-11-27 15:25) [10]

2 asmith: и вообще, в чем смысл галочки build with runtime packages? Нигде найти не могу внятного ответа.

← →
Sergic (2002-11-27 15:57) [11]

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

← →
Starkom (2002-11-27 16:19) [12]

2 Sergic: почему же эта галочка приводит к очень сильным различиям в поведении проекта?

← →
asmith (2002-11-27 18:01) [13]

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

← →
Fantasist (2002-11-27 20:39) [14]

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

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

← →
asmith (2002-11-27 21:27) [15]

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

проблема с TActionList.OnUpdate в Dll Найти похожие ветки