Наши преимущества

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

Пример динамической загрузки диалогов:

Вызов:

Код:
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;
 
Работы будет море - это однозначно, но в случае сложного проекта усилия будут не напрасны. Удачное разделение на dll-ки упростит общую схему проекта, обновление и поддержку, а также позволит избежать множества трудноотловимых глюков многомодульного приложения.
Несколько советов:
1) Чтобы избежать дублирования кода в отдельных библиотеках, проблем с графическим интерфейсом и такими компонентами, как DevExpress, надо обязательно использовать пакеты времени исполнения. Минус - вместе с программой надо распространять все используемые bpl. Плюсы - малый размер библиотек и исполняемых файлов, отсутствие глюков с компонентами и графикой, связанными с дублированием кода в каждом модуле.
2) Строковые параметры необходимо передавать только указателями типа PChar (или PAnsiChar, PWideChar).
3) Есть определенная грань сложности проекта и интерфейсов взаимодействия составляющих его бибилиотек, пересекая которую лучше обратить свой взор в сторону такой технологии, как COM. Она способна значительно упростить жизнь разработчику, взяв на себя часть работы по обеспечению взаимодействия, обратных вызовов и прочих достаточно сложных ньюансов при разработке сложных приложений.
 
реально симпатичное решение предложено и почти целиком описано у Gansmoker-a в блоге
Жаль, что не озвучена авторская идея серверной части для вкладывания форм в плагины ... с пониманием полной идеи было бы проще...
 
Я частенько сую в dll отдельные куски программы - от общих функций до окон и фреймов. Очень удобно, если конечному пользователю поставляешь не "проф" версию, а отдельный набор функциональности. Да и поддерживать проще...
В качестве взаимодействия можно использовать результаты функций, конечно. У меня мои dll (с формами, фреймами) общаются между собой сообщениями. В основной программе обработчик. Это дает какую-то модульность.
 
2) Строковые параметры необходимо передавать только указателями типа PChar (или PAnsiChar, PWideChar).
Можно передавать и WideString - это системные вызовы. для разбивки лучше использовать функциональные модули. У меня в проекте в 5-и местах идет редактирование внешних контактов. Вызываю из DLL. В другом случае: использую технологию COM и динамическую загрузку. Можно пойти дальше .NET - технология, это дальнейшее развитие СОМ технологии. Но начиная с определенного размера - резать все равно придется. Посмотрите на фирменные программы - сколько там библиотек! А когда идет подгрузка можно вывести панельку с часиками - вот уже и нет тормозов.
 
Использовать dll библиотеки есть смысл лишь в том случае когда, вы хотите туда вынести ценую часть кода, для коммерческого распространения или в случае если в сложном проекте предусматривается помодульная модернизация приложения БЕЗ перелинковки всего проекта.

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

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

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


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

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

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

Я б сказал так, если есть время и возможность, то использовать bpl рекомендуется для любого мало мальски большого проекта (пару десятков форм). Плюс советую освоить механизм визуального форм наследования.
 
Последнее редактирование модератором:
Здравствуйте, форумчане, я вот новичок, и хотел бы узнать а MDI приложение можно запихнуть по DLLкам, где каждая форма - мини-программа, имеет свой интерфейс и функции. Если да, то как реализовать
 
А меня больше интересует другой вопрос:
В одной dll - модуль данных с доступам к различным БД (одного формата), используемых одновременно. Во всех остальных dll - различные самостоятельные независимые друг от друга модули программы, каждый из которых содержит от 20 до 100 форм (не считая диалогов и прочего функционала, используемого сразу в нескольких модулях, вынесенного в отдельную dll), где имеются только TDataSource, ссылающиеся на TDataSet в dll с модулем данных.
По сути сейчас в каждой dll - свой модуль данных, задача - вывести его в отдельную dll.
Пока даже браться боюсь, хотя мысль мусолю ухе более года, да только не знаю с какой стороны начать. Жажду мыслей.
 
AlekVolsk, Каждая dll, это ведь отдельно взятый проект. Ты хоть представляешь себе, что значит отладить приложение состоящее их 20-100 окон каждое из которых заключено в dll? Да это гарантированный вынос мозга. А как этот подходж усложнит разработку и написание программы в целом? А как искать ошибки... А как быть если проект не документирован, заброшен хотябы на год, а потом его надо подымать и дорабатывать/дополнять/пределывать..

Лучше без нужды не связыватся с dll-ками.
Отладка сложного приложения и без них, иногда проблемная, так что на отладку отельно взятой подсистемы или даже класса, приходится писать маленькую програмку и там отлавливать все детали и перекосы разрабатываемого подобъекта.
 
Был такой бесплатный компонент TUilPluging потом его купила TMS и на нем построили свой TMS Pluging. меня с помощью него написано достаточно много приложений. Все прекрасно отлаживается.
 
Мне кажется, весь интерфейс пользователя лучше оставить в главной программе, а в библиотеки вынести то, что делает что-то полезное. И проблем меньше, и разделение на интерфес и реализацию будет удобное.
 
Верх