Класс в DLL

← →
TPA (2006-06-03 11:34) [0]

Здравствуйте!
У меня появилась проблема. Есть класс, ну допустим
TMyButton = class(TButton)
Если я это класс помещу в DLL, как мне его использовать в моей программе?

← →
Loginov Dmitry © (2006-06-03 11:37) [1]

Никак. Помести этот класс в основной программе, и используй его сколько влезет.

← →
Юрий Зотов © (2006-06-03 11:40) [2]

Или в BPL, тоже проблем не будет. А с DLL - могут быть проблемы.

← →
TAK (2006-06-04 11:25) [3]

Проблемы нас не пугают:) Вот где бы найти идею?
Неужели не возможно сделать что-то типа Parent := Self после создания экземпляра TMyButton, но Self должен быть THandle или HWND :(((((

← →
Leonid Troyanovsky © (2006-06-04 11:33) [4]

> TAK (04.06.06 11:25) [3]

> Проблемы нас не пугают:)

Зато, они пугают нас.

--
Regards, LVT.

← →
TAK (2006-06-04 11:37) [5]

Сочувствую, но ЮМОР заценил :) Может легче сказать НЕ ЗНЮ?

← →
Leonid Troyanovsky © (2006-06-04 11:38) [6]

> TAK (04.06.06 11:37) [5]

> Может легче сказать НЕ ЗНЮ?

Может быть и легче, но я сказал то, что хотел сказать.

--
Regards, LVT.

← →
TAK (2006-06-04 11:51) [7]

Удалено модератором

← →
Leonid Troyanovsky © (2006-06-04 12:07) [8]

> TAK (04.06.06 11:51) [7]

Не надо проецировать свои проблемы с пониманием на других.
И, вообще, извини, но я с агрессивными анонимами не общаюсь.

--
Regards, LVT.

← →
sniknik © (2006-06-04 12:45) [9]

да уж, достали доморощенные "психологи", со своими подначками "на слабо". хотя... некоторые "ведутся", иначе давно бы уже изжил бы себя подобный стиль "общения" как безрезультатный.

> Проблемы нас не пугают:)
ясное дело не пугают, ты же их сходу на других пытаешся переложить, сам даже не попытался решить. а другим то как раз твои проблемы до фени, они знают что можно без них, как правильно, и так и делают, про что и тебе сказали, но....

← →
Loginov Dmitry © (2006-06-04 13:44) [10]

Юрий Зотов © (03.06.06 11:40) [2]
Или в BPL, тоже проблем не будет

Юрий, вы не могли бы дать ссылочку на материал по хранению классов в BPL. А то я ну никак не могу понять, чем собственно отличается хранение классов в DLL от хранения классов в BPL. Где вообще есть подробная информация о работе с пакетами?

← →
Юрий Зотов © (2006-06-04 14:32) [11]

> Loginov Dmitry © (04.06.06 13:44) [10]

Дык... а какая там документация нужна? Создаем run-time пакет, в нем пишем все, что угодно и компилируем в каталог Exe, либо в каталог, доступный через Path. Сама программа пишется обычным образом, но в ее опциях указываем, что ее надо компилировать с этим run-time пакетом. Cамо собой, BPL должен поставляться юзеру вместе с программой. Вот и вся документация.

А чем отличается - тем, что DLL и Exe компилируются ОТДЕЛЬНО друг от друга и друг о друге ничего не знают. В каждом из них СВОЯ VMT каждого класса (даже если это фактически один и тот же класс, то это все равно получатся РАЗНЫЕ классы), СВОИ глобальные объекты (Application, Screen, Sessoin и др.), СВОИ значения глобальных переменных (DecimalSeparator и др.) - и т.п. В итоге получаем несостыковку и дублирование кода VCL.

А в случае BPL экзешник компилируется с его учетом, поэтому дублирования нет и все прекрасно стыкуется.

Вообще, DLL ведь изначально задумывались именно как библиотеки функций или ресурсов. Служить библиотеками классов (тем более, дельфишных) им как-то несвойственно - так зачем же желать странного и возлагать на них функции, для которых они изначально не предназначены? Это примерно то же самое, что есть суп вилкой - в принципе, можно, но с некоторыми затруднениями.

← →
DrPass © (2006-06-04 19:05) [12]

> А то я ну никак не могу понять, чем собственно отличается
> хранение классов в DLL от хранения классов в BPL.

Ничем не отличается. BPL - это самая обычная DLL, только для нее компилятор автоматически генерирует функции-оболочки для методов/свойств класса, функции-указатели на его VMT, указатели на секции инициализации-финализации, т.е. избавляет программиста от кучи рутинной работы.
Главный недостаток - для избежания вот этого
> В итоге получаем несостыковку и дублирование кода VCL.

общие глобальные модули для пакетов и приложения должны быть где-то вынесены отдельно. Отдельно - читай "тоже в BPL". А следовательно, если ты используешь свою BPL, тебе уже не отвертеться и от многомегабайтных vcl***.bpl, rtl***.bpl.

← →
Loginov Dmitry © (2006-06-04 22:52) [13]

Все это я уже знаю (в Интернете про это к счастью пишут). Интересует следующий момент: что значит

> BPL - это самая обычная DLL,
> только для нее компилятор автоматически генерирует
> функции-оболочки для методов/свойств класса

?

Как заставить BPL "служить библиотекой классов"?
Подозреваю, что придется все-таки описывать прототипы (или интерфейсы, как правильно?) всех классов, используемых в пакете. Как в этом случае описывать классы. Автоматизирует ли этот процесс Delphi.
В общем, дополнительная литература бы не помешала.

← →
Юрий Зотов © (2006-06-04 23:11) [14]

> Loginov Dmitry © (04.06.06 22:52) [13]

> Как заставить BPL "служить библиотекой классов"?
> Подозреваю, что придется все-таки описывать прототипы (или
> интерфейсы, как правильно?)

При статической загрузке BPL - не придется. Просто пишете в Uses юнитов программы нужные юниты из BPL, как обычно - и все. Вы же ничего специально не описываете, когда компилите обычную программу с run-time пакетами VCL? Нет. А она использует соотвеисивующие BPL - и все работает.

А при динамичесткой загрузке BPL - да, придется описывать. Но чтобы не делать этого специально, все классы, которые используются и Exe и BPL, можно вынести в отдельный пакет.

← →
Loginov Dmitry © (2006-06-04 23:38) [15]

Ясно! Спасибо!

← →
saxon (2006-06-05 11:05) [16]

> TPA
Может механизм интерфейсов подойдет?

У меня трабл с пакетами. Загнал Matrix в пакет - получилось 2 файла: Matrix70.bpl и Matrix70.dcp.

Далее пытаюсь откомпилировать компонент, использующий Matrix. Компилирует с нехорошим сообщением: "Unit "Matrix" implicitly imported into package "EKGVisio7"".
Без пакетов компиляция проходит нормально, но с подключением пакетов проект не компилится - пишет
[Error] Packeges "EKGVisio7" and "Matrix70" both contain unit "Matrix" [Fatal Error] Could not compile package "EKGVisio7"

Почему Delphi включает код Matrix"a в пакет EKGVisio7? Как этого избежать?

Сам дошел по истины :)

Оказывается, перед компиляцией пакета EKGVisio7 в поле Request нужно было добавить Matrix70.

Если я это класс помещу в DLL, как мне его использовать в моей программе?

Без проблем. Только обычные DLL для этого не катят, надо создавать обьекты автоматизации (ActiveX называется, если не ошибаюсь). Тоже получаются DLL и можно создавать свои обьекты с этой DLL.

Loginov Dmitry © (05.06.06 11:36) [17]
Почему Delphi включает код Matrix"a в пакет EKGVisio7
затем, что ТЫ так указал.

Loginov Dmitry © (05.06.06 11:36) [17]
Как этого избежать?
Добавить в секцию requires пакет EKGVisio7 - пакет Matrix

бр. не дочитал тему до конца :-) извени.

Класс в DLL Найти похожие ветки