Всем привет!

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

Вообщем, если кто знает как это сделать, то поделитесь, плиз.

Заранее благодарен.

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

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

Код DLL:

Код

library Alex; { Important note about DLL memory management: ShareMem must be the  first unit in your library's USES clause AND your project's (select  Project-View Source) USES clause if your DLL exports any procedures or  functions that pass strings as parameters or function results. This  applies to all strings passed to and from your DLL--even those that  are nested in records and classes. ShareMem is the interface unit to  the BORLNDMM.DLL shared memory manager, which must be deployed along  with your DLL. To avoid using BORLNDMM.DLL, pass string information  using PChar or ShortString parameters. } uses  ShareMem, SysUtils, Classes; {$R *.RES} var GV: real; function AddInt(a, b: integer): integer; begin  Result := a + b; end; function AddReal(c, d: real): real; begin  Result := c + d; end; function AddString(e, f: string): string; begin  Result := e + f; end; function DoSomething(): integer; begin  Result := 1; end; exports  AddInt,  AddReal,  AddString name 'AddStringFromDLL';   begin end.

Код проекта, подключающего DLL:

Код

unit Loader; interface uses ShareMem,  Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,  StdCtrls; type  TForm1 = class(TForm)    e1: TEdit;    e2: TEdit;    e3: TEdit;    ee1: TEdit;    ee2: TEdit;    ee3: TEdit;    re1: TEdit;    re2: TEdit;    re3: TEdit;    b1: TButton;    b2: TButton;    b3: TButton;    procedure b1Click(Sender: TObject);    procedure b2Click(Sender: TObject);    procedure b3Click(Sender: TObject);  private    { Private declarations }  public    { Public declarations }  end; var  Form1: TForm1; implementation {$R *.DFM} function AddInt(a,b:integer): integer;  external 'Alex.dll'; function AddReal(c,d:real): real;  external 'Alex.dll'; function AddStringFromDll(e,f:string): string;   external 'Alex.dll'; procedure TForm1.b1Click(Sender: TObject); begin  re1.text := IntToStr(AddInt(StrToInt(e1.text), StrToInt(ee1.Text))); end; procedure TForm1.b2Click(Sender: TObject); begin  re2.text := FloatToStr(AddReal(StrToFloat(e2.text), StrToFloat(ee2.Text))); end; procedure TForm1.b3Click(Sender: TObject); begin  re3.text := AddStringFromDLL(e3.text, ee3.Text); end; end.

Использование string в dll нежелательно, так как могут возникать проблемы с разделением памяти, вместо этого нужно целесообразней использовать PChar. Что и написано в тексте сгенеренного Дельфи проекта.

Цитата(Dapo @ 27.5.2003, 04:58)

Использование string в dll нежелательно, так как могут возникать проблемы с разделением памяти, вместо этого нужно целесообразней использовать PChar. Что и написано в тексте сгенеренного Дельфи проекта.

Согласен.

Народ, может я не так высказался, но то что вы написали всё понятно, проблема в другом, возможно ли каким бы то нибыло образом вынести классы (включая их определения) в DLL.
То что можно все методы данного классы туда вынести - это понятно, но хотелось бы вынести САМ КЛАСС!

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

Цитата

Народ, может я не так высказался, но то что вы написали всё понятно, проблема в другом, возможно ли каким бы то нибыло образом вынести классы (включая их определения) в DLL.

Можно, а в чем проблема?

Да проблема то в том как импортировать - экспортировать метод - понятно, а как это применить к классу???

ты хочешь создавать наследников от этого класса?

Да нет просто использовать его, хотя наследование не исключено

Самый простой пример - TForm. По аналогии для любого другого класса. И, возможно, ты путаешь класс и экземпляр класса? Есть модуль в котором описан какой-то класс. Включи его в длл и в свою прогу. Ну и юзай его.

Цитата(Dapo @ 28.5.2003, 05:04)

Самый простой пример - TForm. По аналогии для любого другого класса. И, возможно, ты путаешь класс и экземпляр класса? Есть модуль в котором описан какой-то класс. Включи его в длл и в свою прогу. Ну и юзай его.

Да ничего я не путаю.
Как делается наследование - я знаю. ПРОБЛЕМА В ТОМ, ЧТОБЫ КЛАСС БЫЛ ОПИСАН В DLL!!!

Цитата(Dapo @ 28.5.2003, 05:04)

Самый простой пример - TForm. По аналогии для любого другого класса. И, возможно, ты путаешь класс и экземпляр класса? Есть модуль в котором описан какой-то класс. Включи его в длл и в свою прогу. Ну и юзай его.

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

наследовать (в классическом виде) не получиться однозначно...
а чем не устраивает ActiveX?

Да там как я понимаю надо описывать TLB.
А в это TLB все параметры имеют весьма экзотичный тип.
Да иего надо регистрить в реестре, что тоже снижает привлекательность.

В качестве ДЛЛ можно использовать пакеты Дельфи (BPL), поскольку они на самом деле являются ДЛЛ, но обладают большими возможностями при использовании классов. Какими точно я не помню - все ето я мельком просматривал в книге Марко Кенту "Delphi 6 для профессионалов". Так что поищи материальчик про их юзание.

Это сообщение отредактировал(а) <Spawn> - 29.5.2003, 14:51

1. TLB Дельфя тебе может написать сама для любой Dll (если ты ее попросишь)
2. "Экзотические типы" придется использовать однозначно (деректива stdcall это какрас для конвертации праметров процедур из "экзотического" (нравиться мне слово) типа в паскалевский)
3. Наверное BPL для тебя и вправду лучший вариант, но хорошо ли ты себе представляешь задачу? расскажи почему возникла необходимость "делить" проект? почему нельзя пользоваться общей библиотекой классов?

Короче ситуация такова:
Есто проект. Этот проект постоянно совершенствуется и обновляется. Тянуть из инета каждый раз по 3 метра не очень. Вот и разбиваю, чтобы вытягивать только новое.

можно написать библиотеку классов (набор исходников) и при внесение изменений в тот или иной класс обновлять соответствующий исходник и перекомпилять проект (для меня это лучший вариант, я тоже не доверяю ole типам и мне очень нравиться наследовать). Если приложение не распределенное и используются восновном невизуальные компоненты, то очень даже неплохо. В остальных ActiveX, но это уже фенкциональная часть приложения (не класс! а экземпляры) унаследовать от которой нихрена не получиться...

Цитата

и перекомпилять проект

Вот это-то и оно. Ради того, чтобы сам exe не перекомпиливать это всё и затеено!!!

ну и ладноть...
так какие проблемы то, давай сделаем на ActiveX...
расскажи что конкретно хочешь, пока время есть вместе замусолим...;)

Цитата

В качестве ДЛЛ можно использовать пакеты Дельфи (BPL), поскольку они на самом деле являются ДЛЛ, но обладают большими возможностями при использовании классов.

Если ваша программа включает VisualCLX компоненты, Вы должны использовать пакеты вместо DLL. Только пакеты могут управлять запуском и закрытием Qt

Cashey Спасибо, друг...
ты ответил на мой извечный вопрос: "почему не регистрятся некоторые Dll?..." спасибо...

Цитата(altarasjuk @ 29.5.2003, 17:27)

Цитата и перекомпилять проект Вот это-то и оно. Ради того, чтобы сам exe не перекомпиливать это всё и затеено!!!

Unregistered
Я может неправильно выразился, но всё это для того, чтобы НЕ ПЕРЕКОМПИЛИВАТЬ ПРОЕКТ, А ТОЛЬКО ОДИН МОДУЛЬ!

По мне так если прога не распределенная и средство разработки одно то кроме гемороя с этой модульностью ничего не получиться. Компоненты писать безусловно надо, но зачем их в dll прятать...?

То есть если я понял то есть только один вариант - компоненты. Но в них есть недостаток - расширение.
Не хотелось бы, чтобы народу с первого взгляда было понятно на чём писано... Да и DLL как-то попривычней для взгляда... Ну если тока так - то буду разделять на компоненты.
А вот по поводу гемороя - тут никуда ни денешся.

Честно говоря, до сих пор не понял проблему. Что значит "экспортировать классы"? Как ты это себе предствляешь? Если ты используешь эти классы в екзешнике, то описание этих классов тебе все равно надо включить в код екзешника, а для этого вполне подойдут обыкновенные исходники. А уж указатель на экземпляр класса передать вообще нет никаких проблем. В хорошой реализации это будет выглядеть так:

mobj_ifc.pas

Код

interface   IMObj=interface      procedure Method1;      procedure Method2;   end;

mobj_imp.pas

Код

interface uses   mobj_ifc;   TMObj=class(TInterfacedObject,IMObj)      procedure Method1;      procedure Method2;   end; implementation //implementation of  TMObj ......

mobj_dll.dpr

Код

uses  mobj_imp, mobj_ifc; function CreateMObj:IMObj; stdcall; begin   Result:=TMObj.Create; end; exports  CreateMObj;

main_exe.pas

Код

uses   mobj_ifc; interface function CreateMObj:IMObj; stdcall; implementation function CreateMObj;  external 'mobj_dll.dll' name 'CreateMObj';

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

Да вообщем то спасибо, народ.
Вообщем я решил остановиться на компонентах.

Цитата

1. неплохо было бы в маинехе в интерфейсе хотябы описать интерфейс имобж

main_exe.pas

Код

uses  mobj_ifc; ....

На это вам стоило бы обратить внимание.

Цитата

2. у длл и приложения разные адресные пространства и хз что за указатель получиться

Ничего подобного - адресное пространство одно и то же, указатель передавать вполне можно.

Цитата

Для идентификации интерфейсов используют гуид, а для получения экземпляра по интерфейсу - фабрику классов...

GUID добавить не проблема - Shift+Сtrl+G. Фабрикой классов как раз и выступает функция CreateMObj. Делать отдельный объект+интерфейс совершенно необязательно.

Прошу прощения за неточности (а точнее говоря бред) который написал выше (был пьян)
однако, нельзя ли вместо uses mobj_ifc; использовать только гуид интерфейса? если длл зарегистрирована на др. машине можно ли будет пользоваться указателем на интерфейс (CreateMObj Result)?

продолжая тему...

вот скажем выстовил я в опциях проекта, что все надо раскидывать по пакетам (*.bpl). Как мне узнать теперь те пакеты, которые использует мое приложение. Т.е. получить название файла пакета, например vcl70.bpl для стандартных VCL компонентов или там inet70.bpl. Я вот честно говоря не очень уверен, что TBitBtn находится в vcl70.bpl... т.е. я хочу создать дистриб проги... ну не лазить же мне по её импортам что б определить какой пакет нужен

И еще: только ли классы помещаются в пакеты, скажем просто функция может быть помешена в *.bpl ?Как осуществляется контроль версий пакета ?

Не знаю способа, лично я лажу через фар - ExeInfo по exe или dll или ещё там что...

Цитата

однако, нельзя ли вместо uses mobj_ifc; использовать только гуид интерфейса? если длл зарегистрирована на др. машине можно ли будет пользоваться указателем на интерфейс (CreateMObj Result)?

Только гуид ничего не даст - описание интерфейса все-равно нужно (как ты его иначе использовать будешь?)

Другая машина - это совсем другой разговор, как и другой процесс. Здесь передавать адреса на прямую не имеет смысла, ибо адресные пространства разные, здесь необходим маршалинг, не говоря уже о службе создания удаленных объектов, но это отдельный разговор.