Переход к использованию пакетов Delphi-лучшая практика, пожалуйста?
Я пытаюсь начать делать мои собственные библиотеки avaialble как пакеты до компиляции моих приложений с этими пакетами, следовательно, модульизации моего кода. В течение многих лет я "вроде" понимал пакеты, вздыхая с облегчением, когда я загружаю пакет компонентов и нажимаю "установить", и это происходит. Я понимаю, что процесс установки компонента (или компонентов) заключается в создании BPL, который затем регистрируется в IDE.
где я начинаю теряться, это как сделать файлы доступно, чтобы я мог скомпилировать либо с пакетом, либо с предварительно скомпилированным dcu (как это делают сторонние поставщики) и без указания моего проекта на исходный код все время. Я могу создать пакет со следующими параметрами:
где я указал, что все мои выходные данные будут идти в 'c:scratchwow". После сборки я нахожу тест.БПЛ ТЕСТ.DCP и много DUC's. Теперь, когда я указываю другой проект в этой папке для использования DCU, я получаю отсутствующую ошибку DFM (один из единиц есть форма). Должен ли я вручную копировать необходимые DFM в эту выходную папку? DPK знает об этой форме, так почему бы мне не скопировать DFM для меня? Я предполагаю, что с помощью теста.БПЛ этот файл содержит все, но я хочу работать в двух режимах. Конечно, я могу обойти это, включив исходную папку в мой путь поиска проекта, чтобы найти DFM, но сторонние библиотеки, похоже, уже имеют DFM в своей выходной папке. Они установили их там, используя установщик? Спасибо
вместо
4 ответов
Да, вы должны скопировать .dfm в каталог со скомпилированными единицами (.dcus), если это единственный каталог, который вы хотите в своем пути поиска. В BPL, конечно, будет содержаться .dfms, и вам нужно .dcp, чтобы иметь возможность связать BPL с вашим приложением.
сторонние инструменты должны были поставить .УФМС вместе с .dcus в каталоге, используя их установщик, действительно.
Как говорят другие, вы можете использовать события после сборки для копирования файлов DFM на место. Другие люди используют одноразовый внешний пакетный файл, который копирует DFMs в папку DCU.
лично я вижу очень мало пользы в создании пакетов для вещей, которые не разработаны также как многоразовые компоненты. Я также вижу очень мало пользы в разбиении существующего приложения на пакеты, когда вам не нужно использовать один и тот же подраздел или пакет более одного раза или в время разработки.
вещи, которые я бы положил в пакеты:
визуальные и невизуальные компоненты Delphi.
вещи, которые обязательно должны быть подключены во время выполнения, или оставили. Например, предположим, что я продаю MetaWare Light и MetaWare Pro, и вместо того, чтобы использовать компилятор IFDEFs для создания другого двоичного файла, я предпочел по какой-то причине просто не отправлять ADVANCEDFEATURE.BPL с моим системный.
вещи, чтобы остерегаться с пакетами:
Я столкнулся с множеством ошибок компилятора при объединении пакетов с дженериками. Я также столкнулся с сбоями и блокировками IDE в Delphi 2009, 2010, XE и XE2. (Я считаю, что XE3 лучше)
вы должны узнать немного о BorlandMM.dll и управление общей памятью в мире BPL, прежде чем перейти к нему. Есть некоторые премудрости.
пакеты ограничивают способность компоновщика решать, что удалить. На самом деле, это в значительной степени разрушает его. Пакеты содержат все, что связано с ними, и ничего общедоступного не может быть удалено.
после того, как вы создали двоичный пакет и отправили его даже одному клиенту, вам довольно сложно изменить контракт (этот BPL содержит определенную подпись или двоичный интерфейс приложения), вы должны быть осторожны в будущем, чтобы никогда не менять их, или смешивать и сопоставлять их. Остерегайтесь DLL hell, даже среди ваших собственных клиентов, и будьте готовы использовать управление версиями на ваших пакетах. Так же, как пакеты delphi имеют суффикс версии, я рекомендую вам использовать суффиксы версии в ваших собственных пакетах сразу же и ударять их всякий раз, когда двоичная совместимость изменилась.
Delphi обрабатывает зависимости сборки между пакетами примерно так же, как можно было бы надеяться, что это менее хорошо, чем единого монолитного приложения. В приложениях, которые я имею, которые сильно используют пакеты, я нахожу группы проектов, содержащие кучу пакетов, которые зависят друг от друга, очень трудно управлять и быстро создавать. На самом деле, я испытал, что как компиляции, так и сборки медленнее и более разочаровывают, чем в отдельном мегапроекте 750Kline.
Мне действительно интересно, если вы не в области пакета Delphi (вы вздыхаете с облегчением всякий раз, когда компонент delphi фактически строит и устанавливает без проблем?) если вы действительно хотите полностью перейти в мир пакетов. Конечно, вы должны экспериментировать. Но я бы не стал ставить на это ферму. Сначала узнайте больше.
вместо копирования *.DFM вручную вы можете использовать событие после сборки (Project / Options / Build Event), например:
copy “$(PROJECTDIR)\Unit1.DFM” “c:\Scratch\wow\Unit1.DFM”
Я нашел способ сделать это, не двигаясь .ПДФ файлы в каталог .dcu файлы, так что вы можете иметь каталог для .dcu файлы только один для .только файлы dcp и другое для .только файлы bpl.
все, что вам нужно сделать, это создать другой каталог в вашей хорошей структуре, как и я. Каталог называется RES и в нем должны быть размещены все файлы ресурсов (.файлы res, нет .файлы dcr), которые используются приложениями, скомпилированными с помощью ваших пакетов (компонентов). В Делфи Путь к Библиотеке, вы должны включить в дополнение к каталогу DCU (вы уже должны иметь) каталог с именем RES.
на вашем компоненте (время разработки) делайте все, что хотите с формой (проектируйте ее, ставьте другие компоненты и т. д.). В исходном коде устройства вы заменяете {$R *.dfm} с {$R UnitName.ДФМ.} При этом сохраните все и закройте DPK. Теперь двигай .dfm файл (не копировать, переместить!) в папку RES (the .файл dfm-это файл ресурсов для Delphi. Директива {$R} является доказательством!) и после этого снова откройте DPK, чтобы понять, что изменилось.
сначала поймите, что вы не можете открыть форму (F12) из своего устройства, хотя Delphi не выдал ошибку "DFM отсутствует".
теперь сделайте сборку на своем пакете, а затем установите его. Снова понял? Ошибки не отображаются! Это произошло потому, что вы указали местоположение .dfm-файл в пути поиска библиотеки Delphi (каталог RES).
готово! Вы можете использовать свой компонент, и dfm будет найдено, когда компонент включен в приложение.
многие из вас теперь могут сказать, что таким образом я больше не смогу визуально редактировать форму во время разработки компонента. Да, это правда, но если задуматься, зачем мне так часто менять форму на компонент, который на практике следует только использовать и слегка редактировать? Делайте собственные выводы;)