Работа с DLL

← →
minotavr (2003-04-08 17:20) [0]

Привет всем.
Люди помогите.
Есть прога для работы с БД. Хочу сделать DLL но чтобы использовать подключение из вызывающей программы.

А если в общем, как из DLL работать с объектами в вызывающей программе?

С ув. Minotavr.

← →
evvcom (2003-04-09 09:34) [1]

Посмотрите мой ответ на http://delphimaster.net/view/1-1049860557/ Может это поможет.

← →
Minotavr (2003-04-09 17:09) [2]

Спасибо за ответ.
Но это не помогает.

Sharemem - уже прописано.
DLL - выгружаю при завершении главной формы.

Еще пробовал примерно так:

DLL:
Var
BASESAAE: ^TIBDatabase;
….

Procedure createdllform(testdb: TIBDatabase);
…

BASESAAE:=@testdb

И различные вариации

Максимум что я добился выскакивает ошибка типа “нет такой таблицы”

Но некоторые свойства работают, типа:

Caption:= BASESAAE^.datebasename

Или типа того

С ув. Minotavr

← →
evvcom (2003-04-10 02:27) [3]

Понаделал одинаковых топиков...
А здесь http://delphimaster.net/view/1-1049860557/ смотрел?

← →
falcon_k (2003-04-10 02:35) [4]

У меня работает следующая конструкция

В DLL

procedure .... (ddd:Integer)
...
var
DB : TIBDatabase;
...
DB:=TIBDatabase(ddd);
...
Query1.Database:=DB;

В основной проге
qqq:=Integer(Pointer(DM.DB))
передаешь qqq в DLL

← →
evvcom (2003-04-10 02:46) [5]

Я так понял, что TIBDatabase - это класс? Тогда конструкции ^TIBDatabase и BASESAAE:=@testdb - лишние, т.е. в Procedure createdllform(testdb: TIBDatabase) - уже передается указатель на объект, и лишняя адресация/разадресация только путает.
А не работает это вот почему. Я уже писал, что класс TIBDatabase в exe и TIBDatabase в dll - это совершенно разные классы, хотя и имеют одинаковый код! Т.е. передается в dll ссылка на объект, чьи данные и истинные обработчики находятся в exe-файле, а dll пытается обработать этот объект с помощью методов класса, код которого лежит в dll! Элементарная проверка внутри dll: if testdb is TIBDatabase принимает значение False, а внутри exe: True. Разница чувствуется?

← →
evvcom (2003-04-10 08:14) [6]

To falcon_k: и все же это надо бы посмотреть дизассемблером. Если вызываются методы класса exe-модуля, то все нормально (в чем я сильно сомневаюсь), а если вызываются методы класса в dll (что скорее всего так и есть), то такая конструкция работает до поры до времени, и когда она начнет преподносить сюрпризы, заранее никому неизвестно. Но когда это начнется, то всю голову сломаешь, в чем же дело, вчера работало, а сегодня оп-па!

← →
jack128 (2003-04-10 09:17) [7]

evvcom © (10.04.03 08:14)

> Я уже писал, что класс TIBDatabase в exe и TIBDatabase в
> dll - это совершенно разные классы, хотя и имеют одинаковый
> код! Т.е. передается в dll ссылка на объект, чьи данные
> и истинные обработчики находятся в exe-файле, а dll пытается
> обработать этот объект с помощью методов класса, код которого
> лежит в dll!

Код один и тот же и лежит он не в Dll или EXE, а в пакетах..

Из прошлого обсуждения

>Хоть с runtime пакетами, хоть без них. Иначе такую dll можно >будет вызывать только из exe, откомпилированного в той же >версии Delphi!

Это предположеия или доказанный факт??

← →
evvcom (2003-04-10 10:16) [8]

В каких блин пакетах! Речь идет о готовой программе exe и dll. А не о .dcu .bpl .dcp и т.д. Готовый код, уже собранный из всех этих run-time или design-time пакетов. Этот самый пакет (пусть run-time), его код входит после сборки как в exe-файл, так и в dll-файл. И не какое это не предположение. Я сам на этом лопухнулся, когда первый раз несколько лет назад в dll передавал ссылки на объекты-потомки от какого-то базового класса (TWinControl кажется, но это не важно). А потом в dll проверял if Sender is TEdit then ...; if Sender is TComboBox then ...; и т.д. А Sender в результате оказывался не TEdit и не TComboBox, хотя передавал туда точно это. Начал это дело в дизассемблере смотреть, вот тут и понял свою ошибку, что класс вроде как один, но получилось, что в памяти их сидело 2 экземпляра, а is проверяет именно равенство адресов базирования класса Sender в цепочке классов его и его родителей с адресом TEdit, TComboBox и др.
Вывод: если нет желания долго и нудно возиться с поиском ошибки, то я просто не рекомендую передавать в dll классы и там их обрабатывать. Надо ограничиться простыми структурами данных.

← →
jack128 (2003-04-10 22:41) [9]

Мда.. Я вот попытался в DLL"ке проверить протестить класс - оказалось, что Кнопка это Tform...

← →
Fantasist. (2003-04-11 01:47) [10]

> Этот самый пакет (пусть run-time), его код входит после
> сборки как в exe-файл, так и в dll-файл

И какой же он после этого run-time? Run-time он на то и run-time, что код его должен подгружаться в момент выполнения программы, а не на этапе линковки. Иначе он привращается в обычный static link.

> если нет желания долго и нудно возиться с поиском ошибки,
> то я просто не рекомендую передавать в dll классы и там
> их обрабатывать

А я бы просто не реккомендовал налегать на RTTI. В VCL он на высоком уровне, по-моему, не используется, а значит проблемы вы можете внести только сами.
Может, правда, возникнуть популярная проблема совместимости версий ("dll hell"), когда код используемый для компилирования длл, окажется отличным от кода c которым компилировался екзешник. Частично ее можно предотвратить используя и передавая не сами объекты, а интерфейсы к ним.

← →
evvcom (2003-04-11 08:17) [11]

Фантазеру:
И какой же он после этого run-time? Run-time он на то и run-time, что код его должен подгружаться в момент выполнения программы, а не на этапе линковки. Иначе он привращается в обычный static link.
И откуда же он у тебя подгружается? Сделай такой exe, перенеси его одного на другую машину, и запусти. Только не используй всякие лишние dll, не нужны они для такого теста. И посмотри как он у тебя будет прекрасно работать без якобы подгрузки какого-то run-time кода.
run-time - это код который выполняется во время нормальной работы программы и линкуется он нормальным образом, т.е. статически. А design-time - как раз тот код, который нужен для фунциклирования во время разработки. Вот он сидит в файлах bpl, которые по структуре являются dll. Но все методы в этом случае вызываются из bpl, и все твои компоненты являются объектами этой библиотеки.

← →
Fantasist. (2003-04-11 17:40) [12]

> evvcom © (11.04.03 08:17)

Эх-ех... Ну а почему по твоему, используются run-time package"и вообще? Вот VCL иногда предлагают использовать в виде run-time package. Зачем? Говорят, скомпилированный код становиться меньше. Да ты бы и сам попробывал, отметь в Project->Options галочку Build with run-time package и сделай ребилд. Экзешник с 400 кб уменьшится до 60. А куда же остальной код делся? Правильно, все эти пакеты, которы обычно линкуются статически, стали линковатся динамически. То есть код не был включен в екзешник, а остался в пакетах, которые подгружаются при старте программы (как ты сам заметил - это те же длл), и они естественно должны присутсвовать на машине, где программа выполняется.

← →
evvcom (2003-04-14 08:49) [13]

Да, прошу прощения. Попробовал, посмотрел секцию импорта, действительно там стали присутствовать bpl. C run-time packages особо никогда не возился - не было нужды. Поэтому все мои рассуждения применимы только к статической линковке.
Во Борланд накуролесил! А по идее использование того или иного метода линковки не должно бы влиять на качество кода.

← →
АлексейК (2003-04-14 09:24) [14]

В случае если форма модальная. С немодальной немного сложнее.
procedure CreateDllForm(db:TIBDataBase, aHandle:THandle);
var MyDllForm:TMyDllForm;
begin
Application.Handle:=AHandle;
MyDllForm:=TMyDllForm.Create(Application);
with MyDllForm do
begin
IBQuery.DataBase:=db;
..........
ShowModal;
end;
FreeAndNil(MyDllForm);
end;
При вызове нужно передавть Application.Handle. И неважно какие параметры передавать в DLL.

← →
EthernalWonderer (2003-04-14 11:14) [15]

А можно ещё для упрощения вообще развязать создание форм и прочие операции в dll c "подключением".
Для этого экспортировать из вызывающей программы фунцию типа
Function GetDS(IntName: String): TIBDataSet; export; Begin //поиск по имени или ещё как-нибудь ... Result := найденный MainExeDataSet; End;
и "подключать" DataSet в dll:
Function GetDS(IntName: String): TIBDataSet; stdcall; external "mainexe.exe"; ... ExternalDataSet := GetDS("DATASET1");
Так можно "подключать" что угодно. Но вот проверять "это" при помощи RTTY не следует - это верно.

← →
NVB (2003-04-14 11:21) [16]

В случае FIB:

uses
... IBase ...
....
вызов ListDB(Database.Handle)
...

в DLL

Procedure ListDB(DBHandle: TISC_DB_HANDLE); StdCall;
Begin
..
Database.Handle := DBHandle;
..
End;

PS. В свойствах Database
DesignDBOptions [
ddoIsDefaultDatabase = False
ddoStoreConnected = False

Работа с DLL Найти похожие ветки