Мой совет — когда уровни взаимодействия плагинов и основной программы заранее нельзя четко определить и взаимодействие может быть очень сложным, то в этом случае, на мой взгляд, лучшее решение — встраивать в программу какую нибудь скриптовую машину, например тот же FastScript и выполнять "позднее связывание" на скриптах, которые сами по себе могут быть очень просты.
При таком подходе нужно экспортировать в скриптовую машину возможные интерфейсы (классы, объекты, переменные, функции) основной программы. Загружаемые плагины должны при инициализации выполнять экспорт своих интерфейсов в скриптовую машину, которая конечно же должна быть общей у программы и плагинов. После чего можно загрузить и выполнить скрипт инициализации программы, который и выполнит необходимое связывание функционала. В этом случае нет необходимости на этапе проектирования кропотливо прорабатывать интерфейсы — все можно будет сделать потом и, главное, тонко "подстроить" программу непосредственно на клиенте.
vvu>Exe-шник вырос до 7 метров и решил я дальнейший функционал делать плагинами. Остановился на bpl после прочтения статьи Дмитрия Полщанова "Еще раз о Plugin's…", Трофимова Игоря "Подгружаемые модули (plugins) в Delphi" и других, и долгих раздумий и взвешиваний между dll и bpl.
vvu>Вопрос такой: можно ли, как-то заставить bpl видеть и работать с уже загруженным (главной прогой) модулем данных 
vvu>Буду очень благодарен за помощь в этом вопросе, т.к. уж жутко лень реализовывать интерфейсы или хотя бы, если уж никак без них не обойтись, пожалуйста, подскажите их необходимый минимум.
Свет, всем!
Exe-шник вырос до 7 метров и решил я дальнейший функционал делать плагинами. Остановился на bpl после прочтения статьи Дмитрия Полщанова "Еще раз о Plugin's…", Трофимова Игоря "Подгружаемые модули (plugins) в Delphi" и других, и долгих раздумий и взвешиваний между dll и bpl.
Вопрос такой: можно ли, как-то заставить bpl видеть и работать с уже загруженным (главной прогой) модулем данных
Буду очень благодарен за помощь в этом вопросе, т.к. уж жутко лень реализовывать интерфейсы или хотя бы, если уж никак без них не обойтись, пожалуйста, подскажите их необходимый минимум.
Ниже, на всякий случай, более-менее детально описал, что и как:
Мой плагин (bpl) содержит одну форму в которой реализуется некоторый функционал.
bpl я загрузил и форму показал, но через ошибку доступа к БД. Как передать коннект через интерфейсы я понял из статьи, но ситуация немного другая:
в bpl я юзаю модуль из основной проги с описанием класса, который при создании заполняет некоторые поля значениями из БД, через FIBDataSet в DataModule (DM). Т.е., когда стартует программа, то DM создается автоматом и открывает запрос и при создании моего класса в программе поля нормально заполняются значениями из БД:
FNo := DM.ds1.DataSet.FieldByName('NO').AsInteger;
FName := DM.ds1.DataSet.FieldByName('NAME').AsString;
Но, когда класс креатится из формы в bpl, то DM = nil и конечно возникает AV.
В статье вычитал: "При загрузке пакета в память автоматически устанавливаются связи с уже загруженными пакетами". Но к модулям, я так понял, это, видимо, не относится. И, если DM (с FIBDatabase1 и кучей ДатаСетов) вынести в отдельный пакет, например, DM.bpl, то мой плагин.bpl сможет работать с Модулем Данных без реализации интерфейсов для коннекта и запросов (наборов данных, которые они возвращают)
Здравствуйте, Softwarer, Вы писали:
S>Да, разделяемые модули следует также вынести в пакет. Вообще, в нормальной программе с плагинами в основном exe должен быть абсолютный минимум кода.
А у меня сейчас все в одном exe. Буду потихоньку выносить в отдельные bpl, спасибо. Хотя была надежда, что можно малой кровью обойтись.
S>Кроме того, чувствуется необходимость глубже понять механику — как модули связываются между собой, как это работает в случае плагинов.
А не посоветуете, куда нырнуть, чтобы понять
