В дочерних окнах из DLL не работают

← →
Алексей Петров (2001-12-20 13:02) [7]

О моих изысканиях все никак руки не доходят написать статью :)

Вкратце смысл следующий:
Все объекты имеют системную часть VMT. Для D5 это 76 байт. Эта часть используется, в первую очередь, для поддержки RTTI. Среди всего прочего в ней прописан предок объекта. С помощью этого поля выстраивается связанный список с помощью которого можно добраться от любого класса через всех предков до TObject. именно этим полем пользуется функция TObject.ParentClass.

Все VMT, включая системную часть хранятся в сегменте кода каждого модуля (DLL, EXE, BPL).

Если Run-time пакеты не используются, в каждом модуле свой TObject, ничего не знающий о других. Соответственно иерархии объектов в каждом из модулей никак не связаны.

При использовании Runtime packs - общий TObject лежит в пакете vcl50.bpl и соответственно проблем не возникает.

Уточню утверждение: Безопасно использоване одного экземпляра в нескольких модулях только в том случаи, если объект описан в BPL, подключенном ко всем модулям, использующим объект.

Т.к. системный код и структуры системных данных, в exe и dll, если они скомпелированы одной версией Delphi, совпадает - то часто указанные проблемы не проявляются и вылезают только в редких местах, как у Вас, например.

Для справки:
TApplication, TScreen, TForm и Co описаны в vcl50.bpl. Во многих случаях достаточно подключать только один этот пакет.

Когда система уже почти готова, переделывать так врядли есть смысл, но на будующее:
Для систем, подобной вашей, чтоб обеспечить возможность дочерним окнам корректно обращаться к MDIFrame - есть смысл создать пакет, содержащий главное окно и абстрактного предка для всех MDIChild-ов.
При этом exe-шник становится минимальным - он загружает главный пакет и все.
А каждый из пакетов с MDIChild формами уже смело работает с главной формой. За счет общности VCL-ного кода, все работает так, как-будто все в одном exe-шнике сидит.

В дочерних окнах из DLL не работают Найти похожие ветки