Приложение разбитое на dll

sunzh

Турист
Регистрация
13 Янв 2011
Сообщения
10
Реакции
0
Credits
18
Пример динамической загрузки диалогов:

Вызов:

Код:
procedure TForm1.Button11Click(Sender: TObject);
var
  ExecDialog:TExecDialog;
  HLib:THandle;
  P:pchar;
  S:string;
begin
  HLib:=0;
  try
    HLib:=LoadLibrary('FirstLib.dll');
    if HLib>0 then begin
      ExecDialog:=GetProcAddress(HLib,'ExecDialog');
      if Assigned(ExecDialog) then begin
        if ExecDialog(Application.Handle,P) then begin
          S:=P;
          Caption:=S;
        end;
      end else ShowMessage('Method with name ExecuteDialog was not found');
    end else ShowMessage('Can not load library FirstLib.dll');
  finally
    Application.ProcessMessages;
    if HLib>0 then FreeLibrary(HLib);
  end;
end;

Функция в DLL:

Код:
function ExecDialog(AppHandle:THandle; var PictName:pchar):boolean; stdcall; export;
var
  FDialog:TForm1;
begin
  FDialog:=nil;
  PictName:=nil;
  Result:=False;
  Application.Handle:=AppHandle; {Two icons are arisen at taskbar without this operator. Warning while dynamic loading!}
  try
    FDialog:=TForm1.Create(Application);
    if FDialog.ShowModal=mrOK then begin
      FillMemory(@C[0],1000,0);
      if length(FDialog.Edit1.Text)>0 then StrPCopy(C,FDialog.Edit1.Text);
      PictName:=@C[0];
      Result:=True;
    end;
    FDialog.Release;
    FDialog:=nil;
    {!!! Case dynamic loading, one has to use method Free instead of Release!}
  except
    On E:exception do begin
      ShowMessage(E.Message);
      if Assigned(FDialog) then FDialog.Release;
    end;
  end;
  Application.ProcessMessages;
  Application.Handle:=0;
end;
 

ProDIGY

Турист
Регистрация
15 Фев 2010
Сообщения
1
Реакции
0
Credits
2
Работы будет море - это однозначно, но в случае сложного проекта усилия будут не напрасны. Удачное разделение на dll-ки упростит общую схему проекта, обновление и поддержку, а также позволит избежать множества трудноотловимых глюков многомодульного приложения.
Несколько советов:
1) Чтобы избежать дублирования кода в отдельных библиотеках, проблем с графическим интерфейсом и такими компонентами, как DevExpress, надо обязательно использовать пакеты времени исполнения. Минус - вместе с программой надо распространять все используемые bpl. Плюсы - малый размер библиотек и исполняемых файлов, отсутствие глюков с компонентами и графикой, связанными с дублированием кода в каждом модуле.
2) Строковые параметры необходимо передавать только указателями типа PChar (или PAnsiChar, PWideChar).
3) Есть определенная грань сложности проекта и интерфейсов взаимодействия составляющих его бибилиотек, пересекая которую лучше обратить свой взор в сторону такой технологии, как COM. Она способна значительно упростить жизнь разработчику, взяв на себя часть работы по обеспечению взаимодействия, обратных вызовов и прочих достаточно сложных ньюансов при разработке сложных приложений.
 

maremora

Турист
Регистрация
10 Окт 2009
Сообщения
10
Реакции
0
Credits
21
реально симпатичное решение предложено и почти целиком описано у Gansmoker-a в блоге
Жаль, что не озвучена авторская идея серверной части для вкладывания форм в плагины ... с пониманием полной идеи было бы проще...
 

ColdS

Местный
Регистрация
26 Май 2008
Сообщения
7
Реакции
3
Credits
76
Я частенько сую в dll отдельные куски программы - от общих функций до окон и фреймов. Очень удобно, если конечному пользователю поставляешь не "проф" версию, а отдельный набор функциональности. Да и поддерживать проще...
В качестве взаимодействия можно использовать результаты функций, конечно. У меня мои dll (с формами, фреймами) общаются между собой сообщениями. В основной программе обработчик. Это дает какую-то модульность.
 

vovag3074

Местный
Регистрация
16 Янв 2010
Сообщения
54
Реакции
84
Credits
562
2) Строковые параметры необходимо передавать только указателями типа PChar (или PAnsiChar, PWideChar).
Можно передавать и WideString - это системные вызовы. для разбивки лучше использовать функциональные модули. У меня в проекте в 5-и местах идет редактирование внешних контактов. Вызываю из DLL. В другом случае: использую технологию COM и динамическую загрузку. Можно пойти дальше .NET - технология, это дальнейшее развитие СОМ технологии. Но начиная с определенного размера - резать все равно придется. Посмотрите на фирменные программы - сколько там библиотек! А когда идет подгрузка можно вывести панельку с часиками - вот уже и нет тормозов.
 

yahont

Местный
Регистрация
31 Июл 2007
Сообщения
14
Реакции
24
Credits
16
Использовать dll библиотеки есть смысл лишь в том случае когда, вы хотите туда вынести ценую часть кода, для коммерческого распространения или в случае если в сложном проекте предусматривается помодульная модернизация приложения БЕЗ перелинковки всего проекта.

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

kapguokog

Турист
Регистрация
4 Июн 2008
Сообщения
1
Реакции
0
Credits
2
Не так давно писал проект на Delphi, выручило использование BPL в качестве плагинов к основной программе. Удобный механизм, прост в освоении.
 

delphialex

Местный
Регистрация
18 Май 2008
Сообщения
4
Реакции
14
Credits
8
Не совсем ясно, чем не устраивает единственный exe.
При разбиении продукта на части усложнится его сопровождение и
добавится проблема отслеживания версий этих частей.

Dll имеет смысл писать, если только планируется их вызов из других языков.
Понятно, что при возможности таких вызовов придется отказаться от
использования специфичных для Delphi типов данных (например, длинных строк).

Если все-таки тянет на эксперименты, то bpl - разумная альтернатива dll в Delphi.
 

vovag3074

Местный
Регистрация
16 Янв 2010
Сообщения
54
Реакции
84
Credits
562
Например, программа должна работать под разными операционками
 

FILLrate

Местный
Регистрация
17 Июн 2010
Сообщения
10
Реакции
1
Credits
15
Не понимаю, в чем проблема отладки приложения, разбитого на модули?
У меня таких несколько проектов - никаких проблем. То ж самое с помещением туда графики.


Второй вопрос, почему вместо "родных" bpl надо использовать dll?

Добавлено через 11 минут
Использовать dll библиотеки есть смысл лишь в том случае когда, вы хотите туда вынести ценую часть кода, для коммерческого распространения или в случае если в сложном проекте предусматривается помодульная модернизация приложения БЕЗ перелинковки всего проекта.
Глупости!

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

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

kemash

Турист
Регистрация
2 Ноя 2010
Сообщения
5
Реакции
1
Credits
6
Здравствуйте, форумчане, я вот новичок, и хотел бы узнать а MDI приложение можно запихнуть по DLLкам, где каждая форма - мини-программа, имеет свой интерфейс и функции. Если да, то как реализовать
 

AlekVolsk

Местный
Регистрация
7 Апр 2011
Сообщения
16
Реакции
8
Credits
32
А меня больше интересует другой вопрос:
В одной dll - модуль данных с доступам к различным БД (одного формата), используемых одновременно. Во всех остальных dll - различные самостоятельные независимые друг от друга модули программы, каждый из которых содержит от 20 до 100 форм (не считая диалогов и прочего функционала, используемого сразу в нескольких модулях, вынесенного в отдельную dll), где имеются только TDataSource, ссылающиеся на TDataSet в dll с модулем данных.
По сути сейчас в каждой dll - свой модуль данных, задача - вывести его в отдельную dll.
Пока даже браться боюсь, хотя мысль мусолю ухе более года, да только не знаю с какой стороны начать. Жажду мыслей.
 

yahont

Местный
Регистрация
31 Июл 2007
Сообщения
14
Реакции
24
Credits
16
AlekVolsk, Каждая dll, это ведь отдельно взятый проект. Ты хоть представляешь себе, что значит отладить приложение состоящее их 20-100 окон каждое из которых заключено в dll? Да это гарантированный вынос мозга. А как этот подходж усложнит разработку и написание программы в целом? А как искать ошибки... А как быть если проект не документирован, заброшен хотябы на год, а потом его надо подымать и дорабатывать/дополнять/пределывать..

Лучше без нужды не связыватся с dll-ками.
Отладка сложного приложения и без них, иногда проблемная, так что на отладку отельно взятой подсистемы или даже класса, приходится писать маленькую програмку и там отлавливать все детали и перекосы разрабатываемого подобъекта.
 

wix

Турист
Регистрация
25 Янв 2011
Сообщения
5
Реакции
0
Credits
6
Был такой бесплатный компонент TUilPluging потом его купила TMS и на нем построили свой TMS Pluging. меня с помощью него написано достаточно много приложений. Все прекрасно отлаживается.
 

svtpro

Турист
Регистрация
24 Май 2010
Сообщения
5
Реакции
0
Credits
8
Мне кажется, весь интерфейс пользователя лучше оставить в главной программе, а в библиотеки вынести то, что делает что-то полезное. И проблем меньше, и разделение на интерфес и реализацию будет удобное.