Передача классов в Dll

← →
askall (2002-09-18 20:02) [0]

Возникла такая требл. Прошу помощи.
Есть описание классов и в DLL и в основном модуле, например:
TObject -> class TLine -> TWLine.Какие-то методы и поля
есть поле Art : TObject;
есть метод Calulate
TObject -> class TArc -> TWArc.Какие-то методы и поля
есть поле Art : TObject;
есть метод Calulate

Передаю в Dll для обработки списком -> R.Count = 4;

В ходе выполнения проверяю (пробовал двумя способами!!!)
1. ClassRef:=TObject(R.Items[1]).ClassType;
if ClassRef=TWLine then ...
"..." не выполняется!!!!!!!!
(Значение ClassRef= в отладчике TWLine!!!!!)
2. if TObject(R.Items[1]) is TWline then ...
"..." не выполняется!!!!!!!!

А при обращение к методу, например:
TWline(R.Items[1]).Calculate;
begin
x:=TObject(Art).Name (Для примера)
end;

Проблемы:
1. Почему не определяется Classtype или возможно таких действий
нельзя выполнять в Dll?
2. Почему неполучается обратиться к полям?

← →
askall (2002-09-18 20:04) [1]

А при обращение к методу, например:
TWline(R.Items[1]).Calculate;
begin
x:=TObject(Art).Name (Для примера)
end;

Вываливает AcsessViolation в Dll?!

← →
Юрий Зотов (2002-09-18 21:25) [2]

EXE и DLL компилируются, как два независимых проекта. Поэтому таблица классов в каждом из них своя и класс TWLine в каждом из них - тоже свой. То есть, с точки зрения программы, это РАЗНЫЕ классы. Поэтому и не срабатывает ни сравнение классов, ни IS.

Самое простое и самое лучшее - вместо DLL используйте BPL. То есть, вместо DLL создайте run-time пакет и компилируйте EXE с включенной птичкой в опциях. Снимает все проблемы подобного рода.

← →
Dimedrol (2002-09-18 22:34) [3]

Я тоже решал проблему передачи данных в ДЛЛ.
Остановился на передаче УКАЗАТЕЛЯ в ДЛЛ через Messages.
Строил большую структуру данных, правдв это был большой
record, потом брал на него указатель и передавал
его библиотеке, к-рая разумеется, имела переменную
в точности такого же типа.

Как тебе такое ?

← →
Юрий Зотов (2002-09-18 22:36) [4]

Передача данных и передача объектов - вещи разные.

← →
askall (2002-09-19 10:48) [5]

>Самое простое и самое лучшее - вместо DLL используйте BPL.
Нет такоt мне не подходит. У меня одни объекты, а реализация методов различны и заложены в dll -> соответственно объект один реализация методов столько сколько dll, можно дописывать dll и будет новая релизация метода (dll регистрируется в основном модуле)
>Остановился на передаче УКАЗАТЕЛЯ в ДЛЛ через Messages.
Не подходит нужно работат с методами и полями объектов, а они обрабатывают ещё свои поля...

при инициализации передаю ссылки на основные коллекции классов
Там все нормально, но там не происходит определение какой это класс

А каким образом можно теоретически решить кроме BPL?

← →
Andre V. (2002-09-19 11:01) [6]

Опиши абстрактный класс в BPL и включай энтот в основной модуль и в DLL. А реализации на его основе сделай разные...
Так таблицы функций будут совпадать

← →
Старый Паскалист (2002-09-19 11:06) [7]

Теоретически, можно предпринять некоторые шаги, чтобы
классы в ДЛЛ со скрипом работали.

Не используй в методах RTTI: is, as, Assign.
Не используй в них же глобальных переменных.
Ещё лучше - чтобы ЕХЕ и ДЛЛ имели описание только абстрактных
объектов.
Уничтожай объекты там, где их создал - менеджер памяти в
ЕХЕ и в ДЛЛ может быть разный.
И ещё чего-нибудь, что я забыл.

Но всё это, ИМХО, изврат.

При этом запросто может получиться, что в ЕХЕ и в ДЛЛ объекты
будут рзных версий - долго потом глюки искать будешь.

PS А чем тебе bpl-то не нравятся? - ты объясни,
может, окажется, что ты в bpl чего-то не понимаешь.

← →
AlexT1000 (2002-09-19 12:10) [8]

вопрос в дополнение.
а как думаете если в ДЛЛ Sharemem включить. могут таблицы объектов быть одними о теми же?
ведь память одна .

мож ему это поможет?!

← →
Старый Паскалист (2002-09-19 12:16) [9]

AlexT1000 (19.09.02 12:10)
Нет.

← →
Mystic (2002-09-19 12:21) [10]

интерфейсы

← →
Юрий Федоров (2002-09-19 13:07) [11]

Интерфейсы для этого и сделаны, так что вариант всего один

← →
Юрий Зотов (2002-09-19 13:16) [12]

Интерфейсы - это, конечно, бесспорно. Но вариант не единственный, можно и с BPL.

1. Делаем run-time пакет с каким-то (можно абстрактным) классом. Передаваемые объекты будут наследниками этого класса.
2. И Exe, и все DLL компилим с этим пакетом.

← →
REA (2002-09-19 14:09) [13]

Можно немного поподробнее про BPL?
А то с DLL у меня работает, но со скрипом, а интерфейсы почему-то неохота делать.
Будут ли у BPL и приложения общие RTTI и VMT?

← →
Юрий Зотов (2002-09-19 16:48) [14]

Да, будут. Это и есть самое главное преимущество BPL перед DLL. Второе важное преимущество - не дублируется код. Третье - можно свободно работать со строками, динамическими масивами, GetMem-FreeMem и пр. То есть все точно так же, как будто это один обычный проект.

Недостаток BPL - заточены только под Delphi-программы.

← →
REA (2002-09-19 17:03) [15]

Если планируешь передавать классы, то последний недостаток значения не имеет (а хочется именно это).
А какой аналог GetProcessAddress и Exports в BPL?

← →
Юрий Зотов (2002-09-20 00:54) [16]

А никакого. Просто указывате в Uses нужный юнит и все, что нужно, юзаете напрямую. Как в простой программе. Остальное разрулит компилятор.

В опциях проекта нужно проставить галку "compile with run-time packages" и добавить в список нужный пакет (или несколько пакетов). Все остальное - как обычно. И никаких Exports в BPL не нужно, достаточно вынести в секцию interface. Хоть классы, хоть процедуры, хоть типы, переменные, или константы. То есть все, как обычно.

← →
REA (2002-09-20 10:22) [17]

Это все зашибись работает, если статически линкуешь, а вот если надо использовать LoadPackage, то Exports и GetProcAddress работают как в обычной DLL, только вот и RTTI тоже как в обычной DLL - разные. При попытке добавить из DLL кнопку на форму фозникает "Cannot assign TFont to TFont". Есть варианты?

Передача классов в Dll Найти похожие ветки