Здравствуйте, star0ff, Вы писали:
Как тут уже сказали, достаточно создать рантайм пакет (.bpl). Если проект скомпилирован с ключом Use Runitme Packages, то он весь код, который можно, выкинет наружу. Иначе он заимпортирует все dcu внутрь екзешника.
Никаких усилий по переделке классов производить не надо.
Мифы про использование ключевого слова external для импорта методов, а не процедур из DLL считаю байками.

В принципе, возможно также динамическое связывание с классами, вынесенными в DLL (а не BPL), но я бы очень не рекомендовал. Это много геморроя и неожиданных эффектов.

Краткая инструкция по вынесению функциональности в BPL:
1. Выполняем create new / Package
2. Добавляем в свежесозданный пакет интересующие нас юниты (сорц-файлы, ессно
3. Убираем эти юниты из проекта екзешника.
4. Включаем в опциях проекта галку "Use Runtime Packages" и убеждаемся, что наш пакет есть в списке рядом с ней.
5. Компиляем оба проекта.
6. Работаем и радуемся.
7. Если хотим отлаживать bpl, то помимо обычных приседаний (типа включения дебаг инфо), нужно в опциях исполнения пакета(в его проекте!) указать в качестве хоста главный проект и убедиться, что при запуске екзешника грузится именно тот bpl, который указан в настройках аутпута проекта пакета (типичная ошибка — копировать результирующий bpl рядом к екзешнику, и удивляться, почему брекпоинты не работают). После этого можно ставить брекпоинты в коде юнитов, входящих в пакет.
8. Рекомендую создать проджект груп, в которую будет входить сам пакет и екзешник. При этом поставить компиляцию пакета раньше чем екзешника. Поможнет легко переключаться между активными проектами при отладке и не забыть перекомпилять все, что надо, при внесении одновременных изменений.

Здравствуйте, Sinclair, Вы писали:

S>Мифы про использование ключевого слова external для импорта методов, а не процедур из DLL считаю байками.

Все согласны, что BPL=DLL?
Тогда смотрите:

Package1.dpk Uses Unit1
В unit1:

//interface
Type
  MyClass=class
    procedure Message;
    constructor Create;
  end;
//implementation
constructor MyClass.Create;
begin
  messagebox(0,'Text','Caption',mb_ok);
  inherited;
end;

procedure MyClass.Message;
begin
  messagebox(0,'Text','Caption',mb_ok);
end;

Project1.dpr Uses PUnit1
В PUnit1:

//interface
  TMyClass=class
    constructor Create;
    procedure Message;
  end;
//implementation
procedure TMyClass.Message;external 'package1.bpl' name '@Unit1@MyClass@Message$qqrv';
constructor TMyClass.Create;external 'package1.bpl' name '@Unit1@MyClass@$bctr$qqrv';

procedure TForm1.Button1Click(Sender: TObject);
var Obj:TMyClass;
begin
  Obj:=TMyClass.Create;
end;

Понимаю, это не очень практично.
Но похоже ли на миф?

Slicer

А вообще-то, мне больше нравится использовать интерфейсы.
Благо в Delphi это делается проще некуда:

library DllInt;

uses
  SysUtils,
  Classes,
  Windows;

Type IMyInt=interface
       ['{B90E3C5A-50EB-4F9B-BF3D-34A65E6E5B15}'] //Любой новый GUID
       procedure MyFunc;
     end;

     TMyClass=class(TInterfacedObject,IMyInt)
       procedure MyFunc;
     end;

{$R *.res}

{ TMyClass }

procedure TMyClass.MyFunc;
begin
  messagebox(0,'text','caption',MB_OK);
end;

function ReturnInt:IMyInt;
var T:TMyClass;
begin
  T:=TMyClass.Create;
  T.QueryInterface(IMyInt,result);
end;

exports ReturnInt;

begin
end.

А потом юзаем ее так:

//Unit1.pas:
Type IMyInt=interface
  //Копируем определение из исходника DLL (можно, конечно, инклуд или интерфейсный модуль сделать
  // с этим определением внутри (чтобы с Dll поставлять)
       ['{B90E3C5A-50EB-4F9B-BF3D-34A65E6E5B15}']
       procedure MyFunc;
     end;

function ReturnInt:IMyInt; external 'DllInt.dll';

procedure TForm1.Button1Click(Sender: TObject);
var I:IMyInt;
begin
  I:=ReturnInt;
  I.MyFunc;
  I:=nil;
end;

Slicer

Приветствую.

Например, можно создать Run-time BPL (Borland Package Library).
По большому счету, это та же DLL, и она эскпортирует в т.ч. и члены классов.
(Можно запустить DUMPBIN или TDUMP и проверить. Причем TDUMP еще и имена расшифрует )
Так что можно ее через раннее или позднее связывание грузануть и работать.
Но сам я, если честно, не пробовал.
Одно знаю: если в Delphi объявить класс, то вместо его реализации можно написать
(правда, уже не помню- то ли в определение метода внутри определения класса, то ли после определения класса)
... MyMethod(<paramlist>); external 'MyCoolLibrary.dll';
и оно успешно компилится.

Slicer

Здравствуйте, Sinclair, Вы писали:

Абсолютно верно. Но есть возможность не компилить с пакетами. LoadPackage — и грузи пакеты в обычную программу.

Здравствуйте, s.ts, Вы писали:

ST>Здравствуйте, Sinclair, Вы писали:

S>>Здравствуйте, s.ts, Вы писали:
S>>http://www.rsdn.ru/forum/Message.aspx?mid=208322&amp;only=1

Автор: Slicer [Wirkwood]
Дата: 05.03.03

Ну, к тому, что можно не только писать в форумы, но и читать их Вас опередили более чем на полгода.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, s.ts, Вы писали:

ST>>Здравствуйте, Sinclair, Вы писали:

S>>>Здравствуйте, s.ts, Вы писали:
S>>>http://www.rsdn.ru/forum/Message.aspx?mid=208322&amp;only=1

Автор: Slicer [Wirkwood]
Дата: 05.03.03

S>Ну, к тому, что можно не только писать в форумы, но и читать их Вас опередили более чем на полгода.

Полностью стогласен:
http://www.rsdn.ru/Forum/Message.aspx?mid=416127&amp;only=1

Автор: s.ts
Дата: 20.10.03

Опередил Вас более чем на 2 дня.

Здравствуйте,

Возникло желание выгрузить из основной программы мои классы и засунуть их в какую-то библиотеку (DLL)
Подскажите возможные пути решения.

Благодарю.

Здравствуйте, star0ff, Вы писали:

S>Здравствуйте,

S>Возникло желание выгрузить из основной программы мои классы и засунуть их в какую-то библиотеку (DLL)
S>Подскажите возможные пути решения.

S>Благодарю.

В смысле кроме COM Marshalling

Здравствуйте, Slicer [Wirkwood], Вы писали:

S[>Приветствую.

S[>Например, можно создать Run-time BPL (Borland Package Library).
S[>По большому счету, это та же DLL, и она эскпортирует в т.ч. и члены классов.
S[>(Можно запустить DUMPBIN или TDUMP и проверить. Причем TDUMP еще и имена расшифрует )
S[>Так что можно ее через раннее или позднее связывание грузануть и работать.
S[>Но сам я, если честно, не пробовал.
S[>Одно знаю: если в Delphi объявить класс, то вместо его реализации можно написать
S[>(правда, уже не помню- то ли в определение метода внутри определения класса, то ли после определения класса)
S[>... MyMethod(<paramlist>); external 'MyCoolLibrary.dll';
S[>и оно успешно компилится.

S[>Slicer

Не хотелось бы пользоваться BPL, по одной простой причине, возможно это мой грех, но хотелось бы пользоваться DLL, имхо солидней.
Второй вариант интереснее. Постараюсь про него найти инфу.

А теперь то, чего я боялся, так сказать лицом к проблеме.
Все же хочу попробовать COM. Я так понимаю в случае COM потребуется реализовать некоторые интерфейсы.

У меня есть набор каких-то классов. Как мне теперь перевести в DLL, интерфейсы с трудом понимаю

Идеально было бы написать что-то вроде:

...
var
  SomeObject:TSomeClass external 'SomeLib.dll';

Выглядит глупо, но думаю теперь смысл сразу понятен.

Возможно со временем система усложнится, сажем будет еще одна ChildClass.DLL в которой будут сидеть потомки ParentClass.Dll

А пока поломаю голову о книгу Стив Тейксейра, Ксавье Пачеко. Borland Delphi 5 Руководство разработчика, где вроде все это описывается.

Надеюсь Вы мне поможете (кое на что глаза мне уже открыли и на это огромное спасибо) разобраться в этом нелегком, ИМХО, вопросе.

Здравствуйте, Sinclair, Вы писали:

S>Краткая инструкция по вынесению функциональности в BPL:...


Все разжевано по самое не могу.

Здравствуйте, Slicer [Wirkwood], Вы писали:
1. Bpl != dll. Есть некторые нюансы.

SW>Понимаю, это не очень практично.
SW>Но похоже ли на миф?
Фантастика! Мой D5 это съел!
Я худею без баяна. Спасибо, коллега, век живи — век учись!
Если не секрет, откуда догадка? В доке явно не отрицается такая возможность, но и не упоминается...

S>Если не секрет, откуда догадка? В доке явно не отрицается такая возможность, но и не упоминается...
Sinclair, честно, я уже и не помню. Я даже не использовал это никогда, просто зачем-то написал — и
удивился, что скомпилилось Верную фразу Whisperer (если не ошибаюсь) ввернул насчет того, что в
программировании интуиция иногда важнее всего оказывается

Slicer

Здравствуйте, Sinclair, Вы писали:

S>Краткая инструкция по вынесению функциональности в BPL:
...
S>7. Если хотим отлаживать bpl, то помимо обычных приседаний (типа включения дебаг инфо), нужно в опциях исполнения пакета(в его проекте!) указать в качестве хоста главный проект и убедиться, что при запуске екзешника грузится именно тот bpl, который указан в настройках аутпута проекта пакета (типичная ошибка — копировать результирующий bpl рядом к екзешнику, и удивляться, почему брекпоинты не работают). После этого можно ставить брекпоинты в коде юнитов, входящих в пакет.

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

Причём был светлый момент, когда после лазанья по настройкам дебаг вдруг включился. Поработал несколько дней, и как-то сам собой отключился. Понимаю, что звучит глупо, но никаких закономерностей в настройках компилятора и вкл/выкл дебага я не обнаружил. Все условия, приведённые в пред. письме соблюдены...

Здравствуйте, Bulfy, Вы писали:

B>Причём был светлый момент, когда после лазанья по настройкам дебаг вдруг включился. Поработал несколько дней, и как-то сам собой отключился. Понимаю, что звучит глупо, но никаких закономерностей в настройках компилятора и вкл/выкл дебага я не обнаружил. Все условия, приведённые в пред. письме соблюдены...
Могу только посочувствовать. Увы, у Борланд очень странный подход к этому делу: столько неочевидных особенностей, что у людей возникает иллюзия недетерминированного поведения.
Уверяю вас, что на самом деле закономерности есть. Надо просто делать все очень аккуратно. Силишком много есть способов сбить эту тупую оболочку с толку, и она никогда не скажет, в чем же было дело...

Здравствуйте, Slicer [Wirkwood], Вы писали:

Спасибо за примеры, без них ничего не получалось, теперь думается мне разберусь.

Здравствуйте, Sinclair, Вы писали:

S>Мифы про использование ключевого слова external для импорта методов, а не процедур из DLL считаю байками.

Эта байка — не миф. Не вводите народ в заблуждение — ведь поверят же, особенно в обрамлении совершенно правильных фактов.

ИМХО можно так:

type
  TMy = class
    constructor Create;
  end;
<...>

constructor TMy.Create;external '...';//<- тут имя dll

Но все же настоятельно рекомендую воздержаться. Проще импортировать класс целиком. А еще проще использовать bpl.
Для солидности же все-таки рекомендую COM и ActiveX.

S>В принципе, возможно также динамическое связывание с классами, вынесенными в DLL (а не BPL), но я бы очень не рекомендовал. Это много геморроя и неожиданных эффектов.

Хочу добавить, что переносимости это тоже не добавит, т.е. как нельзя эти классы использовать в VB, так и останется.

блин. на даты не посмотрел... и кто этот топик наверх вытащил ??

ST>Хочу добавить, что переносимости это тоже не добавит, т.е. как нельзя эти классы использовать в VB, так и останется.

А так ли это? Self — это просто еще один параметр. Блин, склероз — он до адреса возврата кладется или после, перед всеми параметрами? Если после, что мешает передавать его вручную куда надо?
Правда, это уже не класс будет для VB...

Slicer

Здравствуйте, Slicer [Wirkwood], Вы писали:

SW>Благо в Delphi это делается проще некуда:

SW>

SW>library DllInt;

SW>uses
SW>  SysUtils,
SW>  Classes,
SW>  Windows;

.....................

SW>

А uses ShareMem? Иначе это сродни самоубийству... И вообще, это куча проблем, типа "Can't assign TFont to TFont"... Значит с раздельными пакетами компилить и эти пакеты с собой таскать... Надеяться что срастеться...

А вообще, зачем искать себе приключения, когда есть пакеты? Хоть интерфейсы, хоть классы...

Здравствуйте, Slicer [Mirkwood], Вы писали:


ST>>Хочу добавить, что переносимости это тоже не добавит, т.е. как нельзя эти классы использовать в VB, так и останется.

SM>А так ли это? Self — это просто еще один параметр. Блин, склероз — он до адреса возврата кладется или после, перед всеми параметрами? Если после, что мешает передавать его вручную куда надо?

Всегда сначала в стек запихиваются парметры, а потом адрес возврата. Очищается стек в зависимости от соглашений о вызове. Если сишное — стек чистит вызывающий (что-то типа add sp, ParamsSize ). Если паскалевское, то стек чистит тот, кого вызвали( что-то типа ret ParamSize );
Соответственно, никто не мешает передавать все вручную. Только замороки будут с виртуальными и динамическими методами — там нужно собственно адрес для вызова в VMT искать, формат которого [теоретически] известен только компилятору дельфи. Так или иначе для вызова виртуальных методов из VB без ассемблерных вставок не обойтись
Но это уже писание на ассемблере — там все можно, но не сразу, а немного помучавшись.
ИМХО не стоит овчинка выделки.

Здравствуйте, s.ts, Вы писали:

ST>блин. на даты не посмотрел... и кто этот топик наверх вытащил ??
Я вытащил — появилась новая тема для обсуждения:
http://www.rsdn.ru/Forum/Message.aspx?mid=416319&amp;only=1

Здравствуйте, star0ff, Вы писали:

S>Возникло желание выгрузить из основной программы мои классы и засунуть их в какую-то библиотеку (DLL)
S>Подскажите возможные пути решения.
Единственный правильный путь — использовать пакаджи (кстати, изначально они именно для этого и предназначены)... благо для этого и делать особо ничего не надо — просто галку "Use Runtime Packages" включить... причем, если убрать оттуда стандартные — то они тебе прилинкуются, но лучше так не шутить....

Народ, а кто знает, как в пэкеджах обеспечивается совместимость классов в BPL и основном модуле? Только наличием юнитов для сверки?

Slicer

Здравствуйте, Slicer [Mirkwood], Вы писали:

SM>Народ, а кто знает, как в пэкеджах обеспечивается совместимость классов в BPL и основном модуле? Только наличием юнитов для сверки?
не только... там много чего еще есть...например, есть такой файл .dcp, прилагается к любому .bpl, и без него ты использовать Package не могешь...

вернее — могешь, но не компилятором, а вот подцепить его — таки да... могешь... надо только сделать ручной вызов всех Register... как это делать — отдельная песня, если хочешь — как-нить позже расскажу, могеш напомнить через пару дней (мой мыл есть в профиле).

в .dcp лежат все .dcu...
а в .dcu есть вся RTTI/DebugInfo/TI

Разве ручной вызов Register'ов спасет от несовместимости типов? Тогда — каким образом обеспечивается это спасение на уровне внутрнних механизмов Дельфей? Не модификацией же кода?

Slicer

Здравствуйте, Hacker_Delphi, Вы писали:

H_D>Здравствуйте, star0ff, Вы писали:

S>>Возникло желание выгрузить из основной программы мои классы и засунуть их в какую-то библиотеку (DLL)
S>>Подскажите возможные пути решения.
H_D>Единственный правильный путь — использовать пакаджи (кстати, изначально они именно для этого и предназначены)... благо для этого и делать особо ничего не надо — просто галку "Use Runtime Packages" включить... причем, если убрать оттуда стандартные — то они тебе прилинкуются, но лучше так не шутить....

Интересно поподробнее про эти "шутки"...

Я припоминаю вот что: если в свой пакадж засунуть юниты VCl, все которые нужны, и подключить к проекту только его, то все работает, пока не пытаешься, например, динамически подключить пакадж, который требует другие юниты VCL.

Есть ли еще грабли?

Здравствуйте, Slicer [Mirkwood], Вы писали:

SM>Разве ручной вызов Register'ов спасет от несовместимости типов? Тогда — каким образом обеспечивается это спасение на уровне внутрнних механизмов Дельфей? Не модификацией же кода?
нет... ты не понял... если у тебя есть файл dcp — оно еще при компиляции ругнется — и все...
ручной вызов register нужен тогда, когда есть только bpl и ты точно знаешь, что "вон там" — точно Control.. далее подымаешь пакадж и регистрируешь его (при регистрации все вызова RegisterXXX можно перехватить и узнать про все классы, которые есть)...
а от ошибки несовместимости юнитов не имея ВСЕХ исходников ты не избавишься никак

H_D>а от ошибки несовместимости юнитов не имея ВСЕХ исходников ты не избавишься никак
Дык вот ведь это-то и есть главная проблема, по-моему

Slicer

Кстати, строго говоря, в некоторых случаях можно. Например, если надо Font.Assign(MyPlugin.GetFont()), то можно переписать RTTI-данные того фонта, который из плагина Если, конечно, там именно TFont, а не его потомок

Slicer

The stars so gaily glistened... (Tue, 21 Oct 2003 08:25:24 GMT @392)
...while the fading voice of AlexVinS whispered through the darkness:

A> Я припоминаю вот что: если в свой пакадж засунуть юниты VCl, все которые
A> нужны, и подключить к проекту только его, то все работает, пока не

Ну это нужно если по инету хочешь распространять.
А "на компакте" можно и стандартнуые борландовские выложить.

--
If i had ears, i'd heard none: WinAMP de-instaled.
http://Arioch.nm.ru/FL/Fidolook_SL.png Mail: the_Arioch<at>nm<dot>ru

Здравствуйте, s.ts, Вы писали:
http://www.rsdn.ru/forum/Message.aspx?mid=208322&amp;only=1

Автор: Slicer [Wirkwood]
Дата: 05.03.03

Здравствуйте, Arioch, Вы писали:

A>The stars so gaily glistened... (Tue, 21 Oct 2003 08:25:24 GMT @392)
A>...while the fading voice of AlexVinS whispered through the darkness:

A>> Я припоминаю вот что: если в свой пакадж засунуть юниты VCl, все которые
A>> нужны, и подключить к проекту только его, то все работает, пока не

A>Ну это нужно если по инету хочешь распространять.
A>А "на компакте" можно и стандартнуые борландовские выложить.

Просто не люблю таскать библиотеки которые не необходимы.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, s.ts, Вы писали:
S>http://www.rsdn.ru/forum/Message.aspx?mid=208322&amp;only=1

Автор: Slicer [Wirkwood]
Дата: 05.03.03

Не понял. Это к чему ?