Форум: "Прочее";
Текущий архив: 2013.03.22;
Скачать: [xml.tar.bz2];
Внизкак передать объект из динамически загружеамой 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 а использовать функции в СИ стиле либо интерфейсы, причем с четким соглашением - интерфейс не меняем, а только расширяем и дополняем.
← →
Сергей М. © (2012-03-28 23:41) [23]
> DVM © (28.03.12 23:36) [22]
> от несовпадения версий общих пакетов используемых программой
> и этим вот пакетом не застрахован он
Не застрахован если "суперпрофессионал" не подсуетился и не предпринял адекватных ситуации мер.
А ситуация эта совсем несложно разруливается прямо в теле DllMain()
← →
DVM © (2012-03-28 23:47) [24]
> Сергей М. © (28.03.12 23:41) [23]
> не подсуетился и не предпринял адекватных ситуации мер.
Каких?
← →
Сергей М. © (2012-03-28 23:53) [25]
> Каких?
Тех самых - проверку текущих и требуемых версий общих пакетов на соответствие.
При несоответствии либо бросать внятное исключение либо возвращать INIT_FAIL результатом DllMain
← →
Petr V. Abramov © (2012-03-28 23:55) [26]
> Ega23 © (28.03.12 21:48) [15]
>
>
> > блобом через базу объект передавать гораздо круче
>
>
> Сериализация в чистом виде.
>
распятие более быстрее и менее болезненнее
← →
DVM © (2012-03-29 00:14) [27]
> Тех самых - проверку текущих и требуемых версий общих пакетов
> на соответствие.
Если бы с версиями все так просто было. Пакеты сторонние могут быть и гарантий соблюдения версионности может не быть. Если все пакеты свои и там нумерация ведется тогда проблем конечно нет. С DLL та же ситуация.
Вот например, недавно столкнулся, библиотеки FFMPEG такой зоопарк с версиями развели, причем в разных версиях постоянно меняются структуры передаваемые в функции, функции исчезают и добавляются, меняют значение константы (!). Соответственно меняются хидеры сишные. В самих dll версий в привычном понимании нет. Там есть зашитые константы и функция возвращающая номер версии. Проверять версии конечно можно, но тогда программа будет работать только с той версией dll, что использовалась при ее сборке, что тоже не совсем верно, у пользователя могут быть более новые dll. Короче, FFMPEG - пример того как не надо делать интерфейс библиотеки.
← →
Сергей М. © (2012-03-29 00:30) [28]
> С DLL та же ситуация
Так и я о том же : что с bpl что с dll - проблемы с версионностью были, есть и будут, от них никуда не деться.
Но если bpl при прочих равных условиях предлагает ощутимое упрощение коммуникаций с хостом, сокращение времени разработки и стирание граней различий между статикой и динамикой, то зачем отказываться от этих преимуществ ?
← →
DVM © (2012-03-29 00:34) [29]
> то зачем отказываться от этих преимуществ ?
а я и не предлагаю отказываться
← →
SiDimka © (2012-03-29 00:49) [30]Всем огромное спасибо !!! Все работает, и отлично.
1) нужно это для индивидуалиных пректов, чтобы не переносить кучу кода и не тянуть Юниты из других версий.
2) не лопатить ехешник при изменениях(которые бывают очень часто), а ковырять отдельную длл.
3) в ином случае в зависимости от условий на одном и том же событии открываются окна с отличающимся содержимым (из разных длл). Иначе получается перегуженый интерфес.
← →
NkzAlex © (2012-03-29 07:58) [31]Тогда лучше bpl
Страницы: 1 вся ветка
Форум: "Прочее";
Текущий архив: 2013.03.22;
Скачать: [xml.tar.bz2];
Память: 0.52 MB
Время: 0.078 c