Dev/Docu/ru/User-Man.odc

Подсистема Dev
ENGLISH
Руководство пользователя


Содержание
1КомпиляциямодулейнаКомпонентномПаскале
2Инструментыдляпросмотра
3Загрузкаивыгрузкамодулей
4Выполнениекоманд
5Отладка
6Развертывание
7Кросс-платформенныевопросы


1 Компиляция модулей на Компонентном Паскале
Кроме поглощения сохраненных текстовых документов, компилятор Компонентного Паскаля может компилировать модули из любого места любого открытого текстового документа. Если начало модуля совпадает с началом текста, используйте команду Разработка->Компилировать (Dev>Compile). Если модуль начинается где-либо в середине текста, можно выделить его начало, например, двойным щелчком по ключевому слову MODULE, и затем применить команду Разработка->Компилировать выделенное (Dev->Compile Selection).

Чтобы откомпилировать сразу несколько модулей, необходимо создать список имен модулей в каком-либо документе, например:

 FormModels FormViews FormControllers FormCmds

Выделяя часть списка, которую должен просмотреть компилятор и выполняя команду Разработка->Компилировать список модулей (Dev->Compile Module List), можно последовательно откомпилировать список модулей. Процесс компиляции прервется в случае, если будет встречен модуль с ошибкой. Компилятор докладывает об успехе или неудаче компиляции, выводя сообщения в системный рабочий журнал. Рабочий журнал - это специальный текст, отображаемый во вспомогательном окне. Он может быть открыт командой Инфо->Открыть журнал (Info->Open Log) и очищен командой Инфо->Очистить журнал (Info->Clear Log).

Рабочий журнал является инструментом разработки, так как в основном используется для задач программирования и отладки. Законченные приложения обычно его не отображают. Открывается журнал или нет при запуске BlackBox, определяет конфигурационный модуль Config (в директории System/Mod). Этот модуль может быть изменен программистом по желанию; по умолчанию его процедура Setup содержит только один оператор, который открывает окно журнала.

Разработка->Открыть список модулей (Dev->OpenModuleList) - удобная команда, которая открывает исходные тексты одного или нескольких модулей: выделите имя модуля, например, FormCmds и затем выполните Открыть список модулей. Эта команда может сэкономить вам уйму времени, если вы работаете со многими подсистемами одновременно.

При компиляции заново созданного или измененного модуля рекомендуется прямая компиляция текста программы через Разработка->Компилировать. В добавок к выводу в рабочий журнал, компилятор также вставляет маркеры ошибок в исходный текст и помещает каретку за первым из них, если будут обнаружены синтаксические ошибки. Каждый маркер представляет ошибку, найденную компилятором в исходном тексте. Обычно маркеры показываются в виде накрест перечеркнутых квадратиков. При двойном щелчке на нем маркер раскрывается в соответствующее сообщение об ошибке. Если каретка находится непосредственно за маркером, он может быть раскрыт командой Разработка->Раскрыть маркер ошибки (Dev->Toogle Error Mark), или ее клавиатурным эквивалентом.

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

Команда Разработка->Следующая ошибка (Dev->Next Error) может использоваться для перехода к следующему маркеру. Разработка->Убрать маркеры ошибок (Dev->Unmark Errors) убирает из текста все выставленные маркеры. Однако эта команда требуется редко: компилятор автоматически убирает все старые маркеры после перекомпиляции текста; и при сохранении текста содержащиеся в нем маркеры отфильтровываются, то есть, они их не будет, когда текст будет открыт в следующий раз.

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

Успешная компиляция модуля порождает два файла: символьный и кодовый. Символьный файл содержит информацию об интерфейсе модуля, он используется компилятором для проверки содержимого импортируемых модулей. Кодовый файл содержит генерированный код (Intel386 под Windows, Motorola68020 на Macintosh). Содержимое кодового файла компонуется и загружается динамически при необходимости, таким образом, отпадает надобность в отдельном компоновщике.

Символьные файла нужны только в процессе разработки (используются компилятором и браузером интерфейса), но не нужны для запуска модулей. Символьный файл содержит в специальной кодировке интерфейс модуля, то есть, экспортированные константы, переменные, типы и процедуры. Если интерфейс модуля изменился и модуль перекомпилирован, то на диск записывается новый символьный файл. При компиляции модуля компилятор считывает символьные файлы всех импортируемых модулей. Эта информация используется для генерации кода, а также для проверки типов импортируемых идентификаторов.
После того, как интерфейс модуля изменен, все модули, которые его импортируют (то есть, его клиенты) должны быть перекомпилированы. Нужно перекомпилировать только те модули, которые действительно используют изменившиеся характеристики. Простое добавление новых элементов не мешает клиентам модуля: если вы экспортируете, например, еще одну процедуру, клиенты не нуждаются в перекомпиляции. Это также касается констант, переменных, типов, но не методов. Добавление метода считается не расширением, а модификацией интерфейса и требует перекомпиляции клиентов.
Кодовые файлы порождаются, но никогда не считываются при компиляции. Они необходимы для запуска модулей, то есть, динамический (редактирующий связи) загрузчик может их считывать. К ним можно относиться как к специальным облегченным DLL (библиотека динамической загрузки, dynamic link library).

См. также модули DevCompiler, DevCmds и DevMarkers.


2 Инструменты для просмотра
Основная причина ошибок времени компиляции - это неправильное использование интерфейсов. Для быстрого извлечения действительных объявлений элементов, экспортируемых модулями, можно использовать браузер. Интерфейс модуля показывается при выделении его имени и выполнении Инфо->Клиентский интерфейс (Info->Client Interface). Чтобы увидеть объявление отдельного элемента, например тип процедуры, следует выделить квалифицированное имя этого элемента, например, module.item, и выполнить ту же команду. Браузер покажет результат в окне, которое может быть использовано для дальнейшего просмотра. Команда Инфо->Клиентский интерфейс показывает только часть интерфейса модуля, которая имеет значение для клиентов, то есть, она не затрагивает методы, экспортированные только для реализации, и аналогичные элементы, которые имеют значение только при реализации объектных типов. Для этого существует команда Инфо->Расширяемый интерфейс (Info->Client Interface), которая показывает полный интерфейс.

Две связанных команды, Инфо->Исходный текст и Инфо->Документация (Info->Source и Info->Documentation), позволяют просматривать определения элементов в исходном файле или в сопроводительной документации, соответственно. Обе команды работают с выделенными именами модулей и с именами вида module.item так же, как команда Инфо->Интерфейс.

Основные команды текстового поиска - Инфо->Поиск в исходных текстах и Инфо->Поиск в документации (Info->SearchinSources и Info->SearchinDocu) ищут выделенную строку в доступных исходных файлах и, соответственно, файлах документации. Для исходных файлов это - глобальная директория Mod и директория Mod каждой подсистемы. Для файлов документации - глобальная директория Docu и директория Docu каждой подсистемы. Результатом этих команд является новый текст, который содержит гиперссылки на каждый файл, где была найдена строка, и количество вхождений для этого файла. Когда пользователь щелкает по ссылке, открывается соответствующий файл и выделяется первое вхождение искомой строки. Командой Текст->Искать снова (Text->Find Again) ищется следующее вхождение. Эти команды могут занять несколько минут.

См. также модули DevBrowser, DevReferences, DevSearch и DevDependencies.

3 Загрузка и выгрузка модулей
После того, как модуль успешно пройдет компиляцию, он может быть загружен в систему и использован. Загрузчик BlackBox динамически компонует и загружает модуль во время выполнения. Кодовый файл в основном представляет собой специфичную для языка облегченную DLL (dynamic link library). Загрузчик может быть запущен из программы вызовом процедуры Dialog.Call. Эта процедура принимает параметром имя команды. Она загружает модуль команды, если он еще не загружен. После этого она выполняет процедуру команды. Например,

	Dialog.Call("DevDebug.ShowLoadedModules", "", res)

приводит к загрузке модуля DevDebug (если необходимо) и выполнению его процедуры ShowLoadedModules.

При попытке загрузки могут произойти следующие ошибки:

Кодовый файл не найден (Code file not found)
Не найден кодовый файл модуля.
Например, для загрузки модуля FormCmds требуется кодовый файл Form/Code/Cmds.

Поврежденный кодовый файл (Corrupted code file)
Кодовый файл модуля существует, но его внутренний формат неверен.

Объект не найден (Object not found)
Модуль пытается импортировать некоторый объект (константу, тип, переменную, процедуру) из другого модуля, в котором этот объект не экспортирован.

Противоречивый импорт объекта (Obect is inconsistently imported)
Модуль импортирует некоторый объект (константу, тип, переменную, процедуру) из другого модуля, где этот объект экспортирован, но с другой сигнатурой.
	Такие противоречия обычно происходят, если интерфейс модуля изменяется (например, процедура приобретает дополнительный параметр), но после этого не все клиентские модули перекомпилируются. Другой причиной может быть то, что модуль, интерфейс которого изменился, не был перезагружен после компиляции. В этом случае все должно работать нормально, после того как он будет выгружен (или после перезапуска BlackBox).

Циклический импорт (Cyclic import)
Модули не могут импортировать друг друга циклически. Например, недопустимо, чтобы модуль А импортировал модуль В, модуль В импортировал модуль С, а модуль С импортировал модуль А.

Недостаточно памяти (Not enough memory)
Не хватает памяти для загрузки модуля.

Однажды загружен, модуль остается в системе, если не будет выгружен явно. Список загруженных в настоящий момент модулей выводит команда Инфо->Загруженные модули (Info->Loaded Modules). 

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

Команда Разработка->Выгрузить (Dev->Unload) воспринимает имеющий фокус исходный текст модуля и пытается выгрузить соответствующий кодовый файл. Команда прерывается, если модуль в настоящий момент используется, то есть, если он импортирован по меньшей мере одним другим модулем, который тоже загружен. (В общем, модули могут освобождаться только сверху вниз.) Команда Разработка->Выгрузить список модулей (Dev->Unload Module List) воспринимает выделение, которое должно содержать последовательность имен модулей. Вы можете непосредственно использовать текст, созданный командой Загруженный модули.

См. также модуль DevDebug.


4 Выполнение команд
Есть несколько способов выполнить команды (то есть, процедуры, экспортированные модулями на Компонентном Паскале и предназначенные для прямого исполнения пользователями) из BlackBox. Имя команды может быть записано как текст, в форме "module.procedure", выделено и выполнено командой Разработка->Выполнить. Проще вставить коммандер перед именем команды, используя Инструменты->Вставить коммандер. При щелчке на коммандере строка, следующая за ним, интерпретируется как последовательность команд, например:

  "Dialog.Beep; DevDebug.ShowLoadedModules"

Если строка содержит только одну команду, не имеющую параметров, ограничители строки могут быть опущены, как здесь:

  Dialog.Beep

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

Список допустимых параметров для команд документирован в модуле StdInterpreter.

BlackBox Component Framework пытается вызывать команду Config.Setup при запуске. Вы можете изменить Config, чтобы создать вашу собственную загрузочную конфигурацию.

См. также модули DevDebug и Config.


5 Отладка
Когда случаются ошибки времени выполнения, например, деление на нуль или нарушение некоторого утверждения, открывается окно ловушки (trap window). Такое окно содержит текст, который показывает содержимое стека в момент сбоя. Извлечение из такого текста показано ниже:

	index out of range

 ObxTrap.Do   [00000049H] 
	i	INTEGER	777
	str	Dialog.String	"String"
	v	Views.View	[85D29730H] 
 StdInterpreter.CallProc   [00000BC1H] 
	i	Meta.Item
	 .obj	SHORTINT	4
	 .typ	SHORTINT	20
	 .vis	SHORTINT	4
	 .adr	LONGINT	-2034827097
	 .mod	undefined: 	86B60000H
	 .desc	undefined: 	00000004H
	 .ptr	Meta.ArrayPtr	[85CDF4B0H] 
	mn	Meta.Name	"ObxTrap"
	mod	StdInterpreter.Ident	"ObxTrap"
	ok	BOOLEAN	TRUE
	parType	INTEGER	0
	pn	Meta.Name	"Do"
	proc	StdInterpreter.Ident	"Do"
 StdInterpreter.Command   [0000187EH] 
	left	StdInterpreter.Ident	"ObxTrap"
	ptype	INTEGER	0
	right	StdInterpreter.Ident	"Do"


В первой строке приводится исключение или номер ловушки, например, "Индекс вышел за границы" или "TRAP 0". Ниже выводится последовательность активаций процедур, например, последней активной процедурой (где произошла ошибка) была ObxTrap.Do, которая была вызвана из StdInterperetter.CallProc, которая вызвана из StdInterpretter.Command и т.д. Каждая процедура помечается маленьким ромбиком слева от ее имени. Щелчок на ромбике дает новое окно, которое показывает глобальные переменные модуля, в котором объявлена процедура, например:

  ObxTrap

	global	INTEGER	13


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

А теперь вернемся к дисплею стека. Строка под именем процедуры показывает параметры и локальные переменные процедуры, упорядоченные по алфавиту. Следующий пример

	str	Dialog.String	"String"

означает, что локальная переменная str  типа Dialog.String имеет значение "String" в момент сбоя. Если имя переменной показано курсивом, это означает параметр-переменную (то есть, представляющий другую переменную).
После переменной-указателя, значок ромбика позволяет проследовать по указателю к записи, на которую он указывает, например, указатель v

	v	Views.View	[85D29730H] 

может быть отслежен до записи
	ObxTrap.Do:v^

[85D29730H]	TextViews.StdViewDesc
	 .context	Models.Context	[85D29CC0H] 
	 .era	LONGINT	3
	 .guard	LONGINT	0
	 .bad	SET	{}
	 .model	Containers.Model	[85D29780H] 
	 .controller	Containers.Controller	[85D29A20H] 
	 .alienCtrl	Stores.Store	NIL
	 .text	TextModels.Model	[85D29780H] 
	 .org	LONGINT	0
	 .dy	LONGINT	0
	 .defRuler	TextRulers.Ruler	[85D29AD0H] 
	 .defAttr	TextModels.Attributes	[85D29BD0H] 
	 .hideMarks	BOOLEAN	TRUE
	 .cachedRd	TextSetters.Reader	[85D1A470H] 
	 .trailer	TextViews.Line	[85D20390H] 
	 .bot	LONGINT	2339975
	 .setter	TextSetters.Setter	[85D29BF0H] 
	 .setter0	TextSetters.Setter	[85D29BF0H] 


Такие дисплеи открываются в новом окне. Поля записи предваряются ".". В первой строке показан путь, которым вы пришли к записи. Если сделано более одного шага по ссылке, то ромбик на правом краю позволяет шаг за шагом вернуться назад.

Элементы массивов и поля записей скрыты в складках (см. StdFolds), которые могут открываться или закрываться щелчком мыши. Свертывание структурных типов данных позволяет легче ориентироваться в сложных ситуациях.

Заметьте, что отладчик находит исходные тексты только в том случае, если они расположены в правильном месте и имеют правильные имена, в соответствии с их подсистемами. Например, для модуля "FormViews", отладчик ищет файл Form/Mod/Views. Если файл находится где-либо еще, или имеет другое название, отладчик будет искать открытое окно с исходным текстом модуля. Если и это не удастся, будет выведено диалоговое окно, в котором пользователь сможет указать отладчику, где искать необходимый файл.

Когда сбой происходит в реализации отображения, например, в его процедуре Restore, произошедшая ошибка может привести позже к новой ошибке, например, из-за того, что процедура Restore при развертывании отображения будет вызвана снова. В худшем случае это может привести к нескончаемому потоку ошибок. BlackBox предупреждает такие ситуации, частично отключая сбойное отображение. Такое отображение накрывается светло-серым прямоугольником; его содержимое не будет обновляться. Однако в остальном поведение отображения остается в целости, то есть, оно может быть сохранено в файл. Если сохранение вызовет сбой, то отображение будет превращено в нелегальное (alien); при этом оно крест накрест перечеркивается. Однако остальная часть контейнерного документа все еще может быть сохранена.


BlackBox различает три категории сбоев в отображении:
 при обновлении: сбой в процедурах Restore или RestoreMarks
 при сохранении: сбой процедурах Internalize или Externalize
 другие: сбой в какой-либо другой процедуре отображения.

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


Это значит, что сбойные отображения "изящно деградируют", замораживая только то поведение, которое виновато в сбое. Если имеются причины, чтобы "разморозить" отображение, можно использовать команду Dev->Revalidate View.

Бесконечный цикл можно прервать нажатием ctrl-break (Windows 95/NT) / command-option-. (Mac OS).

The following standard traps may occur at run-time (depending on the platform, some of these errors don't occur):
Во время выполнения могут происходить следующие стандартные ошибки:

	недопустимый WITH 	invalid WITH
	недопустимый CASE	invalid CASE
	функция без возврата значения	function without return
	охрана типа	type guard
	значение вне допустимых границ	value out of range
	индекс вне допустимых границ	index out of range
	строка слишком длинная	string too long
	переполнение стека	stack overflow
	переполнение целого типа	integer overflow
	деление на нуль	division by zero
	бесконечный действительный результат	infinite real result
	потеря значимости действительного типа	real underflow
	переполнение действительного типа	real overflow
	неопределенный действительный результат	undefined real result
	не является числом	not a number
	прерывание с клавиатуры	keyboard interrupt
	разыменование NIL	NIL dereference
	недопустимая инструкция	illegal instruction
	разыменование NIL (чтение)	NIL dereference (read)
	недопустимое чтение памяти	illegal memory read
	разыменование NIL (запись)	NIL dereference (write)
	недопустимая запись в память	illegal memory write
	вызов процедуры по NIL	NIL procedure call
	недопустимое выполнение	illegal execution
	недостаточно памяти	out of memory
	ошибка шины	bus error
	ошибка адреса	address error
	ошибка сопроцессора	fpu error
	исключение	exception

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

Не занято	ЏЏ0 .. Џ19
Предусловия	Џ20 .. Џ59
Постусловия	Џ60 .. Џ99
Инварианты	100 .. 120
Зарезервировано	121 .. 125
Пока не реализовано	         126
Зарезервировано	         127

Вы можете свободно использовать коды 0..19 в ваших программах, обычно в качестве временных точек останова при отладке. По соглашению, остальные коды сбоев генерируются различными проверками условий (assertions), то есть, операторами, которые проверяют определенное условие и прерывают выполнение, если условия нарушены. Условия, которые должны быть соблюдены при входе в процедуру, называются предусловиями, условия, которые должны быть соблюдены при выходу из процедуры - постусловия, а условия, которые должны соблюдаться во время выполнения, называются инвариантами. Большинство процедур  в BlackBox Component Framework проверяют некоторые предусловия. Номер заказного сбоя уникален внутри процедуры. Таким образом, в случае сбоя обратитесь к документации (или исходному тексту, если он доступен) сбойной процедуры. Там вы сможете получить больше информации о причине сбоя.
Разработчик может также предоставить текстовое описание причины сбоя в файле ресурсов подсистемы: имя модуля без префикса подсистемы, затем "." затем имя процедуры, ".", номер сбоя. Например: 

Math.Power.23	Pre: x # 1.0  OR  ABS(y) # INF

Views.View.CopyFrom.20	Views.CopyFrom and Views.CopyFromModelView must not both
	be overwritten
Если существует такой ресурс, то соответствующий текст выводится в окне сбоя.

Следует заметить, что никогда во время отладки нет нужды покидать обычную среду BlackBox Component Builder, нет никакого специального "режима отладки" или "отладочной среды", все интегрировано вместе!

Пример: ObxTrapdocu

Отладчик BlackBox - это нечто среднее между "посмертным отладчиком" и отладчиком "времени выполнения". Он срабатывает после того, как команда вызвала сбой (посмертно), но не прерывает работу окружения BlackBox (время выполнения). Некоторые средства, такие как Инфо->Показать состояние (Info->View State), которые позволяют отслеживать структуры данных, начиная с выделенного отображения, обычно ассоциируются только с отладчиками времени выполнения.

Это типично для объектно-ориентированных программ, когда их управляющие потоки внезапно сворачиваются и становятся сложными для исследования. Следовательно, выполнение программ шаг за шагом (пошаговое), по сообщениям или по вызовам процедур на практике становится непрактичным при отладке сложных систем. Вместо этого BlackBox предлагает более эффективную стратегию отладки:

Пусть ошибка сообщит о себе как можно больше.

Вместо ожидания какой-либо ошибки и дальнейших попыток найти путь назад - к ее причине, позволим ошибке сигнализировать о своей причине, насколько это возможно. Только этот путь действительно экономит время отладки. Реализация языка следует этой стратегии, проверяя индексы и границы при доступе к массивам, разыменование указателей со значением NIL, и т.д. В дополнение к таким встроенным проверкам, Компнентный Паскаль предоставляет стандартную процедуру ASSERT, которая позволяет проверить соблюдение любых условий. Если условие нарушено, открывается окно сбоя. Процедуры BlackBox Component Framework последовательно применяют проверки условий (assertions), например, в начале процедуры для проверки, верны ли переданные значения параметров. Это предпочительнее, чем позволить процедуре, получившей неверные значения, поставить под угрозу работу системы.

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

См. также модуль DevDebug.

6 Развертывание
Если вы разрабатываете добавочные компоненты (например, новые подсистемы) для BlackBox, развертывание сводится к простому распространению копии директории вашей подсистемы. Вы можете не желать распространять исходные тексты, в целях защиты ваших прав на интелектуальную собственность. В этом случае вам не следует помещать исходные тексты в распространяемые копии. Вы можете не желать делать один или несколько ваших интерфейсов модулей открытыми, или никаких вообще, если ваше приложение не предусматривает расширяемости. В этом случае вам не следует помещать соответствующие символьные файлы в распроняемые копии. Однако для каждого открытого модуля вам следует поместить файл документации в директории Docu подсистемы. Например, для модуля FormCmds файл будет называться Form/Docu/Cmds.
Традиционно в директорию Docu помещается файл Sys-Map. Этот текст-карта содержит список всех открытых модулей; элементы списка являются гиперссылками.
Если подсистема реализует элементы пользовательского интерфейса, такие как отображения или команды, должно быть предоставлено руководство пользователя. Этот документ называется User-Man и тоже размещается в директории Docu.
Если подсистема задумана для использования программистами и если не достаточно документации к отдельным модулям, директория Docu должна содержать обзорный текст, называемый Dev-Man.

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

1) Этот метод предназначен для приложений, которые часто расширяются и обновляются: вы предоставляете нескомпонованные кодовые файлы вашего приложения и среды BlackBox, вместе с минимальным компонованным приложением для загрузки полной программной системы.
Чтобы сделать неупакованную и некомпонованную отдельную версию, вам необходимо скопировать некоторые файлы и директории из BlackBox в новую директорию. Вот что вам нужно (и позволено) скопировать:
все стандартные директории BlackBox с их поддиректориями Code и Rsrc, за исключением Obx и Dev, директории ваших собственных подсистем; и файл BlackBox.exe, который можно переименовать в соответствии с названием вашего нового приложения.

2) Этот метод предназначен для приложений, которые закрыты или постепенные обновления и расширения относительно редки: вы упаковываете содержимое директории BlackBox в один большой исполняемый файл. В отличие от компоновщика (linker), упаковщик не ограничен только кодовыми файлами; им также можно упаковывать ресурсы, документацию и любой другой вид файлов в приложении. В отличие от метода 1), пользователь не может легко повредить приложения удалением части кода или ресурсных файлов. См. подробности в документацииупаковщика.

3) Этот метод больше всего подходит для традиционных приложений (то есть, приложений на Компонентном Паскале, которые не используют среду BlackBox) и для компонованных библиотек (DLL под Windows): вы используете компоновщик, чтобы собрать несколько кодовых файлов в один файл приложения.
Для компонованной версии вам необходимо использовать компоновщик, чтобы запаковать ваши кодовые файлы вместе с кодовыми файлами BlackBox в единое приложение. См. детали в документациикомпоновщика. После компоновки вам нужно копировать новое приложение в новую директорию. Вам также нужно скопировать поддиректори Rsrc подсистем Form, Host, Std, System, Text  и ваших собственных подсистем. Если отсутствуют файлы ресурсов, приложение все же будет работать, но утратит все связи строк, все разметки диалоговых окон и все собственные меню.

Для всех методов:
В дополнение вы можете создать вашу собственную версию файла описания меню и диалогового окна О программе... / About... (System/Rsrc/Menus System/Rsrc/About). Если для ваше приложение задумано расширяемым, вам также следует копировать символьные файлы (Sym/Abc) всех модулей, интерфейсы которых должны быть открытыми. Это может касаться или не касаться стандартных модулей BlackBox. Убедитесь, что структура ваших новых директорий соответствует структуре поддиректорий в исходной директории BlackBox!

Windows:
Адаптируйте подходящим образом меню Помощь и соответствующий текст.

Mac OS:
Отредактируйте текст Help в директории System/Rsrc подходящим образом.

Windows:
В тексте readme в директории Dev/Install описывается коммерческая установочная программа, которая используется дистрибутивом BlackBox. Вы можете захотеть использовать установочный скрипт BlackBox как основу для вашего собственного. Когда вы используете этот инструмент, большинство ручных копирований, описанных выше, становится ненужными.
Заметим, что все равно имеет смысл создавать упрощенную копию вашей рабочей среды (для испытания в реалистичных условиях), даже если вы используете инструмент компилятора.


Для распространения программного обеспечения в электронном виде по каналам, которые не поддерживают двоичные данные, например, по e-mail, доступен стандартныйASCII-кодировщик.


7 Кросс-платформенные вопросы
Если вы используете BlackBox и на Mac OS, и на Windows, вы будете постоянно переносить документы между двумя платформами. Кодовые файлы не могут быть перенесены, так как их форматы непортируемы. Чтобы упростить перенос документов, вам следует настроить доступные инструменты (например, программу Apple PCExchange), чтобы они могли переводить тип файла MacOS ("oODC") и конструктор файла ("obnF") в расширение имени файла Windows ".odc" и наоборот.

Кроме того, вы можете захотеть использовать шрифты, которые доступны на обоих платформах, шрифты TrueType или PostScript, если имеется Adobe Type Manager. Если эквивалентных шрифтов на обоих платформах нет, вы все же сможете прочитать текст с другим, корректно замененным шрифтом. Вероятно, это приведет к неудовлетворительным результатам.


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

Подобно любому другому документу, диалоговые окна могут переноситься между двумя платформами. Однако для лучшего результата вы должны хорошо подобрать размещение элементов управления в диалоговых окнах перед тем, как их распространять.

Чтобы минимизировать проблемы с установкой, рекомендуется ограничивать имена модулей максимум восемью символами  (без учета префикса подсистемы, который сам может состоять из восьми символов) и не использовать имена модулей, которые отличаются только прописными и строчными буквами.