как передать объект из динамически загружеамой dll

← →
SiDimka © (2012-03-28 18:24) [0]

как передать toolbar из dll в coolrar myform?

← →
Дмитрий С © (2012-03-28 18:31) [1]

Экспортируй функцию
function GetToolBar: TToolBar.

И используй ее в программе.

(чувствую ща камней накидают))

← →
SiDimka © (2012-03-28 18:43) [2]

А каким образом?

Заранее спасибо!

← →
Ega23 © (2012-03-28 19:00) [3]

В общем случае - никак.

← →
Дмитрий С © (2012-03-28 19:21) [4]

> А каким образом?

Послушай лучше Ega23.
А вообще если хочется модульности на delphi - изучай механизм пакетов (Package), другими словами BPL файлов.

← →
SiDimka © (2012-03-28 19:26) [5]

Статически все работает, а динамически чгего-от нехватает, наверное дельного экзампла.

← →
Petr V. Abramov © (2012-03-28 19:43) [6]

не слушай Ega23, и так и так нормально работает.
и в exe, и в dll первым в uses должен стоять sharemem
и exe, и dll должны быть скомпилены с рантайм-пакетами
перед выгрузкой библиотеки очень желательно руками уничтожить все объекты, которые в ней созданы
LoadLibrary или LoadPackage - и вперед

← →
Ega23 © (2012-03-28 19:44) [7]

Сериализуй объект в dll, передавай буфер в приложение, создавай объект из стрима.

← →
Ega23 © (2012-03-28 19:45) [8]

> не слушай Ega23, и так и так нормально работает.

Петрович. В общем случае - не получится. В частном, когда и то и то собирается на одной машине с одинаковым менеджером памяти - да, можно.
Только нафига? Есть масса других остроумных способов.

← →
SiDimka © (2012-03-28 19:53) [9]

>Petr V

Длл, загружается и на память ругается. Говорит: "0000000"

← →
CRLF (2012-03-28 20:02) [10]

Господа, среди нас поэт-с!

← →
Petr V. Abramov © (2012-03-28 20:21) [11]

> Петрович. В общем случае - не получится. В частном, когда
> и то и то собирается на одной машине с одинаковым менеджером
> памяти - да, можно.

а если с разными, то как ни остроумничай, рано или поздно получишь

> Длл, загружается и на память ругается. Говорит: "0000000"

если VCL используется, конечно.

← →
Ega23 © (2012-03-28 20:35) [12]

> а если с разными, то как ни остроумничай, рано или поздно
> получишь

Сериализация спасёт Иисуса.

← →
Petr V. Abramov © (2012-03-28 21:02) [13]

> Ega23 © (28.03.12 20:35) [12]

> Сериализация спасёт Иисуса.

а причем тут dll vs bpl, это раз
блобом через базу объект передавать гораздо круче. правда с mssql замучаешься.

← →
CRLF (2012-03-28 21:45) [14]

> блобом через базу объект передавать гораздо круче
А что, это не одна из реализаций сериализации разве?

← →
Ega23 © (2012-03-28 21:48) [15]

> блобом через базу объект передавать гораздо круче

Сериализация в чистом виде.

> правда с mssql замучаешься.

?

← →
Сергей М. © (2012-03-28 21:50) [16]

> SiDimka

Назови хотя бы одну вразумительную причину, по которой для твоей задачи заведомо не подходит bpl)

← →
Ega23 © (2012-03-28 22:45) [17]

> Назови хотя бы одну вразумительную причину, по которой для
> твоей задачи заведомо не подходит bpl)

Я бы даже сказал - не подходит монолитный exe.

← →
DVM © (2012-03-28 23:01) [18]

> А вообще если хочется модульности на delphi - изучай механизм
> пакетов (Package), другими словами BPL файлов.

Интерфейсы, WideString и COM - совместимые типы данных и никаких проблем с DLL. Или вообще COM.

← →
DVM © (2012-03-28 23:07) [19]

Причем тут разные менеджеры памяти в Dll и основном приложении? Тут тупо классы разные, даже если и там и сям TMyClass.

А если DLL и основное приложение собрано в разных версиях делфи то никто не гарантирует, что какой то стандартный класс не поменялся. Поменялся - получим AV а может и не получим, а может потеряем вообще данные. А может нет.
В случае пакетов проблема разных версий делфи кстати не отпадает, а вообще такие пакеты опасными становятся для основной программы.

← →
CRLF (2012-03-28 23:17) [20]

> Поменялся - получим AV а может и не получим, а может потеряем
> вообще данные. А может нет.
Да-да, удалённо отлаживать экзешник, скомпиленный в D6 и обменивающийся данными с дллкой, скомпиленной в D4, при том, что TDataSet менялся, -- было очень весело.

← →
Сергей М. © (2012-03-28 23:29) [21]

> пакеты опасными становятся для основной программы

Не опасней чем любой иной загружаемый модуль, сляпаный с бодуна кривыми ручонками и к тому же долдным образом не документированный)

← →
DVM © (2012-03-28 23:36) [22]

> Сергей М. © (28.03.12 23:29) [21]

> Не опасней чем любой иной загружаемый модуль, сляпаный с
> бодуна кривыми ручонками

Да пакет может быть написан супер профессионально, но от несовпадения версий общих пакетов используемых программой и этим вот пакетом не застрахован он. То же и если в DLL передаются классы.
Так что либо не юзать классы в DLL а использовать функции в СИ стиле либо интерфейсы, причем с четким соглашением - интерфейс не меняем, а только расширяем и дополняем.

> DVM © (28.03.12 23:36) [22]

> от несовпадения версий общих пакетов используемых программой
> и этим вот пакетом не застрахован он

Не застрахован если "суперпрофессионал" не подсуетился и не предпринял адекватных ситуации мер.
А ситуация эта совсем несложно разруливается прямо в теле DllMain()

> Каких?

Тех самых - проверку текущих и требуемых версий общих пакетов на соответствие.
При несоответствии либо бросать внятное исключение либо возвращать INIT_FAIL результатом DllMain

> Ega23 © (28.03.12 21:48) [15]
>
>
> > блобом через базу объект передавать гораздо круче
>
>
> Сериализация в чистом виде.
>

распятие более быстрее и менее болезненнее

> Тех самых - проверку текущих и требуемых версий общих пакетов
> на соответствие.

Если бы с версиями все так просто было. Пакеты сторонние могут быть и гарантий соблюдения версионности может не быть. Если все пакеты свои и там нумерация ведется тогда проблем конечно нет. С DLL та же ситуация.

Вот например, недавно столкнулся, библиотеки FFMPEG такой зоопарк с версиями развели, причем в разных версиях постоянно меняются структуры передаваемые в функции, функции исчезают и добавляются, меняют значение константы (!). Соответственно меняются хидеры сишные. В самих dll версий в привычном понимании нет. Там есть зашитые константы и функция возвращающая номер версии. Проверять версии конечно можно, но тогда программа будет работать только с той версией dll, что использовалась при ее сборке, что тоже не совсем верно, у пользователя могут быть более новые dll. Короче, FFMPEG - пример того как не надо делать интерфейс библиотеки.

> С DLL та же ситуация

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

> то зачем отказываться от этих преимуществ ?

а я и не предлагаю отказываться

Всем огромное спасибо !!! Все работает, и отлично.

1) нужно это для индивидуалиных пректов, чтобы не переносить кучу кода и не тянуть Юниты из других версий.

2) не лопатить ехешник при изменениях(которые бывают очень часто), а ковырять отдельную длл.

3) в ином случае в зависимости от условий на одном и том же событии открываются окна с отличающимся содержимым (из разных длл). Иначе получается перегуженый интерфес.

Тогда лучше bpl

как передать объект из динамически загружеамой dll Найти похожие ветки