Delphi dcp файл что это

Обновлено: 03.07.2024

Следует ожидать переводов разделов справочной системы Delphi, компиляций из учебников, переводы статей, "путевые заметки" и прочие интересности. Блог прежде всего ориентирован на студентов, но опытных людей я тоже буду рад видеть;-)

воскресенье, 13 марта 2011 г.

Обзор языка Delphi

Программная организация

Программы Delphi обычно делятся на части, которые называются модулями. Большинство программ начинается с заголовка program, который определяет имя программы. За заголовком программы обычно следует раздел подключения модулей (Uses clause), затем блок объявлений. В разделе подключения модулей перечисляются модули, связываемые с программой. Эти модули могут использоваться совместно несколькими программами, каждая из которых может иметь свой собственный раздел подключения модулей.

Раздел подключения модулей обеспечивает компилятор информацией о зависимостях между модулями. Поскольку эта информация хранится в самих модулях, большинство программ на Delphi не требуют make-файлов, заголовочных файлов или файлов с директивами "include".

Исходные файлы Delphi

Компилятор ожидает обнаружить исходный код в файлах трех типов:

Файлы программных модулей (*.pas)
Файлы проектов (*.dpr)
Файлы пакетов (*.dpk)

Файлы модулей содержат большую часть кода приложения. Каждое приложение имеет один файл проекта и несколько файлов модулей. Файл проекта, который соответствует программному файлу в традиционном Pascal, организует файлы модулей в приложение. Инструментарий разработки Embarcadero автоматически обрабатывает файлы проектов во всех приложениях.

Если вы компилируете программу из командной строки, вы можете поместить весь исходный код в файлы .pas. Если вы пользуетесь IDE для сборки приложения, она будет автоматически создавать файл проекта.

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

Прочие файлы, используемые при создании приложений.

В дополнение к модулям с программным кодом, продукты Embarcadero используют для построения приложений несколько типов файлов, не содержащих программный код Pascal. Эти файлы автоматически обрабатываются IDE:

Файлы VCL форм (*.dfm)
Файлы ресурсов (*.res)
Файлы опций проекта (*.dof)

В дополнение к файлам форм VCL, каждый проект имеет файл ресурсов (.res), который содержит пиктограмму приложения и прочие ресурсы (например, строки). По умолчанию этот файл имеет тоже имя, что и файл проекта (.dpr).

Файл опций проекта (.dof) хранит настройки компилятора и линковшика, информацию о путях поиска и так далее. Каждый проект имеет связанный с ним файл опций проекта, который имеет такое же имя, что и файл проекта (.dpr). Обычно опции, хранящиеся в этом файле устанавливаются при помощи диалогового окна опций проекта (Project Options dialog).

Различные инструменты в IDE хранят информацию в файлах других типов. Файлы настроек рабочего стола (.dsk) хранят информацию об организации окон и прочие опции конфигурации. Файлы настроек рабочего стола могут быть определены для проекта или действовать для среды разработки в целом. Эти файлы напрямую не влияют на компиляцию.

Файлы, генерируемые компилятором

Когда вы в первый раз компилируете приложение или пакет, компилятор для каждого модуля в вашем проекте создает файл скомпилированного модуля (.dcu под Win32). Все .dcu файлы в вашем проекте затем линкуются для создания одного исполняемого файла или пакета. Когда вы в первый раз компилируете пакет компилятор создает файл для каждого модуля, входящего в состав пакета и, затем, создает файл пакета и файл .dcp. Если вы используете переключатель GD, линковщик создает .map файл и .drc файл, который содержит строковые ресурсы и может быть скомпилирован в файл ресурсов.

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

Фактически, вам не нужен файл с исходным кодом модуля до тех пор, пока компилятор может найти файл скомпилированного модуля или модули, от которых зависит этот модуль, не изменятся.

Примеры программ

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

Простое консольное приложение

Первая строка объявляет программу, названную Greetings. Директива говорит компилятору, что это консольное приложение, предназначенное для запуска из командной строки. Следующая строка объявляет переменную с именем MyMessage, которая содержит строку. (Delphi имеет настоящие строковые типы данных). Далее программа присваивает значение "Hello world!" переменной MyMessage и отправляет ее содержимое в стандартный вывод, используя процедуру WriteLn. Процедура WriteLn объявлена в модуле System, который компилятор автоматически подключает к каждому приложению.

Вы можете набрать эту программу в файл greeting.pas или greeting.dpr и скомпилировать ее, введя dcc32 greeting для создания исполняемого файла Win32.

Более сложный пример

Следующий пример демонстрирует программу, разделенную на два файла: файл проекта и файл модуля. Файл проекта, который вы можете сохранить как greeting.dpr выглядит следующим образом:

Первая строка объявляет программу, названную Greeting, которая снова является консольным приложением. Раздел подключения содержит Uses Unit1;, что говорит компилятору, что программа Greetings зависит от модуля Unit1. Наконец программа вызывает процедуру PrintMessage, передавая ей строку 'Hello World!'.

Процедура PrintMessage определена в Unit1. Далее приведен исходный код Unit1, который должен быть сохранен в файле с именем Unit1.pas:

Unit1 определяет процедуру PrintMessage которая принимает одну строку как аргумент и посылает ее в стандартный вывод. (В Delphi подпрограммы, которые не возвращают значения называются процедурами. Подпрограммы, которые возвращают значение, называются функциями). Обратите внимание, что PrintMessage объявлена дважды. Первое объявление находится под зарезервированным словом interface, делает процедуру PrintMessage доступной другим модулям (таким, как Greetings), которые используют Unit1. Второе объявление под зарезервированным словом implementation действительно определяет PrintMessage.

Теперь вы можете скомпилировать Greetings из командной строки, введя

для создания исполняемого файла Win32.

Приложение VCL

Программа включает в себя файл проекта и два новых файла модулей. Сначала приведем файл проекта:

Снова наша программа называется Greeting. Она использует три модуля: Forms, который является частью VCL; Unit1, который связан с главной формой приложения (Form1); и Unit2, который связан с еще одной формой (Form2).

Программа производит несколько вызовов объекта Application, который является экземпляром Forms.TApplication , класса, объявленного в модуле Forms. (Каждый проект имеет автоматически генерируемый объект Application). Два из этих вызовов включают метод CreateForm класса Forms.TApplication. Первый вызов CreateForm создает Form1, экземпляр класса TForm1, определенного в Unit1. Второй вызов CreateForm создает Form2, экземпляр класса TForm2, объявленного в Unit2.

Unit1 выглядит следующим образом:

Unit1 создает класс TForm1 (наследуемый от Forms.TForm) и экземпляр этого класса Form1. TForm1 включает в себя кнопку Button1, экземпляр StdCtrls.TButton и процедуру Button1Click, которая вызывается, когда пользователь нажимает кнопку Button1. Button1Click скрывает Form1 и выводит на экран Form2 (вызов Form2.ShowModal).

Важно: В этом примере Form2.ShowModal полагается на использование экранных форм создаваемых автоматически. Такое использование хорошо для примера, но для разработки реальных приложений этот способ не слишком пригоден.
Form2 объявлена в Unit2:

Unit2 создает класс TForm2 и экземпляр этого класса Form2. TForm2 включает кнопку (CancelButton, экземпляр StdCtrls.TButton) и метку (Label1, экземпляр StdCtrls.TLabel). Вы не сможете видеть этого без исходного кода, но Label1 показывает надпись Hello world! , что обозначено в файле формы Form2 Unit2.dfm.

TForm2 объявляет и определяет метод CancelButtonClick, который будет вызываться, в любой момент, когда пользователь будет нажимать CancelButton. Эта процедура (также как и TForm1.Button1Click в Unit1) называется обработчиком события поскольку она реагирует на событие, которое случается в процессе выполнения приложения. Обработчики назначаются определенным событиям в файлах форм Form1 and Form2.

Когда программа Greetings запускается, Form1 выводится на экран, а Form2 невидима. (По умолчанию только первая созданная в файле проекта форма становится видимой при запуске. Она называется главной формой проекта.) Когда пользователь нажимает кнопку на Form1, Form2 показывает приветствие Hello world!. Когда пользователь нажимает CancelButton или кнопку закрытия на заголовке окна, Form2 закрывается.

Вы когда ни будь задумывались о том, что создает Дельфи в папке с исходниками проекта? Да и нужен ли весь этот абсолютно бесполезный, для рядового программиста, "мусор"? Пора призадуматься. В этой мини-статье я расскажу о назначении таких файлов.

Вступление прочитали, сразу к делу. По правде говоря, я опишу не только те файлы, которые создаются в папке с исходниками, но и некоторые другие, что, думаю, будет интересно всем. Буду описывать в алфавитном порядке. Итак, пристегнулись? Поехали!

.BPG - Borland Project Group: это разновидность файла сборки.

.BPL - Borland Package Library: этот файл есть ничто иное как обыкновенная (или нет?) DLL, которая включает в себя компоненты VCL. Что такое компоненты, я думаю, объяснять не стоит.

.CFG - Файл конфигурации: содержит параметры проекта, аналог файлов .DOF

.DCP - Delphi Component Package: грубо говоря, это исходники компонента. Скомпилированные компоненты содержатся в .BPL.

.DCU - Delphi Compiled Unit: наверное самый часто встречающийся тип файлов. Он содержит откомпилированный код юнита, с помощью него ускоряется компиляция.

.DDP - Delphi Diagram Portfolio: вы заглядывали на вкладку Diagramm в окне редактирования кода? Вот эти файлы содержат как раз эти схемы, которые можно создавать в том окне.

.DFM - Delphi Form File: здесь в двоичном виде хранится описание формы и компонентов, которая эта форма содержит

DF - Резервная копия файла формы: в большинстве случаев она бесполезна, зря засоряет винчестеры. Так что гнать в шею! (точнее отключить в настройках :)

.DOF - Delphi Options File: содержит (в текстовом виде) текущие параметры проекта.

.DPK - Delphi PacKage: исходник проекта пакета.

.DPR - Delphi PRoject: исходник проекта проекта, точнее файл с исходным текстом проекта вашей программы

DP - Резервная копия DPR: см. .

.DSK - DeSKtop: файл с настройками рабочей среды Дельфи.

.DSM - Delphi Symbol Module: имеет сомнительную полезность.

.DCI - Delphi Code Templates: шаблоны кода дельфи. Помоему в комментариях не нуждается.

.DRO - Delphi Object Repository: репозитарий обьектов (Tools - Repositary).

.DMT - Delphi Menu Templates: шаблоны менюшек дельфи.

.DCT - Delphi component Temlates: шаблоны компонентов дельфи.

.OBJ - OBJect: обьектный файл, который применяется в C/C++. Он используется в том случае, если вы хотите скомпилировать программу с скомпилированным кодом (из OBJ файла) из C/C++

.PAS - PAScal: исходник модуля (юнита)

PA - Резервная копия PAScal: см. .

.RES .RC - ResourCe: двоичный файл ресурсов программы, таких как картинки, иконки, формы и прочее.

.TODO - TODO: файл списка To-Do (сделать) списка. Обычно полезен в том случае, если программа разрабатывается коллективом программистов.

Если вам помог материал сайта кликните по оплаченной рекламе размещенной в центре

Проект Delphi состоит из форм, модулей, установок параметров проекта, ресурсов и т.д. Вся эта информация размещается в файлах. Многие из этих файлов автоматически создаются Delphi, когда вы строите ваше приложение. Ресурсы, такие, как битовые матрицы, пиктограммы и т.д., находятся в файлах, которые вы получаете из других источников или создаете при помощи многочисленных инструментов и редакторов ресурсов, имеющихся в вашем распоряжении. Кроме того, компилятор также создает файлы. Давайте бегло познакомимся с некоторыми из этих файлов, так как знание того, какие файлы какую информацию содержат, не раз поможет вам в трудных ситуациях.

Когда вы проектируете ваше приложение, Delphi создает следующие файлы:

Файлы резервных копий (.-dp, .

Следующая группа файлов создаётся компилятором:

Это двоичный файл, содержащий заголовок пакета и список принадлежащих ему файлов

И, наконец, другие файлы Windows, которые могут использоваться Delphi:

Главной частью вашего приложения является файл проекта (.dpr), содержащий код на языке Object Pascal, с которого начинается выполнение вашей программы и который обеспечивает инициализацию других модулей. В большинстве случаев вы можете создать законченное приложение Delphi, так и не взглянув на этот файл. Он создается и модифицируется Delphi автоматически в процессе вашей разработки приложения. Имя, которое вы даете файлу проекта, когда сохраняете его, становится именем исполняемого файла.

Приведенный ниже код является примером того, как выглядит файл проекта в случае, если вы, начав новый проект, не изменяли в нем имен файлов и форм.

program Project1
uses
Forms,
Unit1 in 'unit1.pas' ;

Этот код содержит всего два выполняемых оператора. Первый из них создает форму Form1, а второй запускает выполнение приложения.

Все изменения файла проекта при добавлении новых форм, изменении имен форм и т.п. поддерживаются Delphi автоматически. Если вам необходимо посмотреть исходный файл проекта, надо выполнить команду View | Project Source. Но обычно это вам не требуется.

Не следует без нужды изменять файл проекта. Это может привести к несогласованности используемых имен и к прочим неприятностям.

Информация о формах Delphi хранится в двух файлах. В файле с расширением .dfm хранится информация о внешнем виде формы, ее размерах, местоположении на экране и т.д. В текстовом файле с расширением .pas хранится код модуля, соответствующего данной форме. Имена обоих этих файлов одинаковы. Вы задаете это имя, когда в первый раз сохраняете ваш модуль.

В версиях Delphi, предшествующих Delphi 5, файл формы .dfm был двоичным. Для того чтобы посмотреть его в текстовом виде, надо было щелкнуть на форме правой кнопкой мыши и из всплывшего меню выбрать раздел View as Text. Тогда в окне Редактора Кода появлялся текстовый файл формы. При желании его можно было редактировать. Для возврата к графическому представлению формы надо было на тексте файла щелкнуть правой кнопкой мыши и выбрать команду View As Form.

Все эти возможности сохранены и более новых версиях. Но, начиная с Delphi 6, пользователю предоставляется возможность выбрать, в каком виде он предпочитает сохранять файл формы: текстовом или двоичном. Если вы щелкнете на форме правой кнопкой мыши, то увидите во всплывшем меню индикатор Text DFM. По умолчанию он включен и файлы форм хранятся в текстовом виде. Если выключить этот индикатор, то файлы форм будут храниться в двоичном виде. Вы можете создавать модули, не привязанные к конкретным формам. Например, в большом приложении полезно иметь модуль, содержащий константы, переменные, процедуры и функции, используемые в различных модулях. Наличие такого модуля позволяет сократить число взаимных ссылок различных модулей.

К тому же подобный модуль может использоваться в разных ваших проектах. Чтобы создать в вашем проекте новый модуль, не связанный с какой-либо формой, надо выполнить команду File | New | Other и в открывшемся окне New Items на странице New щелкнуть на пиктограмме Unit.

Теперь надо сказать несколько слов о выполняемом файле .ехе и о файлах пакетов. В Delphi можно разрабатывать прикладные программы двух видов — автономные выполняемые файлы .ехе и программы с поддержкой пакетов (packages) времени выполнения. В последнем случае размер выполняемого файла заметно сокращается, но зато вы должны поставлять пользователю не только выполняемый модуль, но и файлы поддерживающих его пакетов. В следующих уроках будут рассмотрены достоинства и недостатки использования пакетов времени выполнения. Не останавливаясь сейчас на этих вопросах, отметим, что во время отладки, пожалуй, всегда имеет смысл включать поддержку пакетов времени выполнения. Это существенно сократит размеры выполняемых файлов и сбережёт вам немало дискового пространства.

Для использования этой возможности выполните команду Project | Options. В открывшемся окне опций проекта выберите страницу Packages и на странице Packages включите индикатор Built with runtime packages. Одновременно полезно включить в том же окне индикатор Default, что обеспечит статус этой установки как установки по умолчанию для всех ваших будущих проектов.

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

Компания, в которой я работаю, разрабатывает систему на Delphi, которая содержит десятки модулей exe, и каждый из них в определенной степени идентичен исходному коду. К сожалению, никто никогда не заботился об использовании библиотек для размещения совместно используемого кода. Это означает, что каждый раз, когда в коде, совместно используемом всеми этими модулями, появляется исправление ошибки, программист должен вносить исправления во все из них по отдельности! На это всегда уходит столько времени .

Я решил найти способ поместить общий код в библиотеки. Я рассматривал библиотеки DLL и BPL. В этом случае BPL казались намного более удобными для программистов и гораздо менее хлопотными, особенно потому, что код используется только в нашем программном обеспечении и только в Delphi.

Я поместил весь код, используемый всеми модулями exe, в BPL, и все вроде нормально, но есть некоторые вещи, которых я не понимаю и был бы признателен, если бы вы мне их объяснили.

После разделения кода на BPL я ожидал, что будет достаточно развернуть exe-файлы с созданными мной BPL. Но оказалось, что им нужны еще и rtl100.bpl, и vcl100.bpl. Почему это так? Я хочу использовать только бывших и моих BPL. Я не хочу предоставлять конечным пользователям кучу библиотек, поставляемых Borland и сторонними компаниями :). Я хочу, чтобы они компилировались в exes, как раньше компилировались. Возможно ли это?

То, что я сделал до сих пор, было:

Я поместил все блоки общего доступа в BPL. Каждый BPL содержит модули, принадлежащие к одной и той же категории, поэтому программистам ясно, какой код ожидать в данной BPL.
Каждый BPL - это библиотека "времени выполнения и времени разработки".
Каждая BPL «явно перестраивается». Два последних параметра являются настройками проекта по умолчанию для BPL.

А если речь идет о проектах exe:

Я удалил все блоки, которые ранее помещал в BPL.
Я установил свои BPL из меню "Инструменты" -> "Установить пакет" в BDS 2006.
В настройках моего exe-проекта я проверил опцию «сборка с пакетами времени выполнения» и перечислил все свои пакеты BPL в поле редактирования ниже (только мои пакеты, так как я удалил все остальные, которые там появлялись).

Это все, что я сделал. Проекты exe компилируются правильно, но у меня нет доступа к исходному коду BPL (я не могу перейти к этому коду из моих проектов exe), хотя все BPL хранятся вместе с файлами исходного кода. Почему? Мне это кажется странным.

Я всегда стараюсь писать длинные описания - извините за это :). Буду признателен за вашу помощь. Мне просто нужно несколько слов пояснить упомянутые моменты: развертывание exe только с моими BPL, правильность того, что я делал в целом, и невозможность навигации по исходным кодам BPL. Заранее большое спасибо!

Всем спасибо за обсуждение. Некоторые говорили, что выбранный мной подход не был хорошей идеей. Наше программное обеспечение состоит из более чем 100 модулей (большинство из них являются чем-то вроде драйверов для разных устройств). Большинство из них используют один и тот же код - в большинстве случаев классы. Проблема в том, что эти классы не всегда помещаются в отдельные автономные блоки pas. Я имею в виду, что общий код часто помещается в блоки, содержащие код, специфичный для модуля. Это означает, что когда вы исправляете ошибку в общем классе, недостаточно скопировать модуль pas, в котором он определен, во все программные модули и перекомпилировать их. К сожалению, вам придется копировать и вставлять фиксированные фрагменты кода в каждый модуль, один за другим, в соответствующий модуль и класс. На это уходит много времени, и это то, от чего я хотел бы избавиться, выбрав правильный подход - пожалуйста, помогите мне.

Я думал, что использование BPL было бы хорошим решением, но, как некоторые из вас упомянули, у него есть некоторые недостатки. Наихудшая проблема заключается в том, что если каждому EXE требуется несколько BPL, сотрудники нашей службы технической поддержки должны будут знать, какие EXE нужны какие BPL, а затем предоставить конечным пользователям соответствующие файлы. Пока у нас нет средства обновления программного обеспечения, это будет очень полезно как для наших технических специалистов, так и для конечного пользователя. Они обязательно заблудятся и рассердятся: - /.

Также могут возникнуть проблемы с совместимостью - если один BPL используется многими EXE, модификация одного BPL может быть хорошей для одного EXE и плохой для некоторых других - @Warren P.

Что мне тогда делать, чтобы быстрее исправлять ошибки в таком большом количестве проектов? Я думаю об одном из следующих подходов. Если у вас есть идеи получше, дайте мне знать.

Поместите общий код в отдельные и автономные блоки pas, поэтому, когда в одном из них есть исправление ошибки, достаточно скопировать его во все проекты (перезаписать старые файлы) и перекомпилировать все из них.

Создайте BPL для всего общего кода, но свяжите их с EXE-файлами, чтобы EXE-файлы были автономными.

На мой взгляд, сейчас это лучшее решение, но есть несколько минусов. Если я исправлю ошибку в BPL, каждому программисту придется обновить BPL на своем компьютере. Что, если они забудут? Но все же я думаю, что это небольшая проблема. Если мы позаботимся об информировании друг друга об изменениях, все должно быть в порядке.

@CodeInChaos: Не знаю, правильно ли я вас понял. Вы имеете в виду совместное использование файлов pas между проектами? Как это сделать? Исходные коды храним в SVN. Это означает, что нам придется хранить общий код в отдельной папке и заставлять все проекты искать этот код там, верно? И загрузите из SVN проект и все папки, от которых он зависит .

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

Читайте также: