Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ISRP / litra / Лекции ИСРП русс.doc
Скачиваний:
140
Добавлен:
10.03.2016
Размер:
813.57 Кб
Скачать

Тема 4.Физическое проектирование программ.(8час)

Лекция 7Процедура физического проектирования – порядок, инструменты, ресурсы, документы

Фаза разработки текста программного продукта – фаза физического проектирования.

Выбор инструмента разработки. Определение возможностей инструмента и сравнение с потребностями разработки. Поиск готовых компонент для использования в проекте. Парадигма повторного использования. Работа препроцессора, трансляция, связывание, загрузка, исполнение программ. Фазы преобразования программ. Файлы проекта визуального построителя и их получение в процессе разработки. Автоматическое и ручное создание файла ресурсов. Редактор ресурсов. Макросы и их использование в проекте.

«(C++Builder Глава 4.) Препроцессор и особенности компилятора

..о некоторых ключевых словах C++Builder, которые не укладываются в стандарт ANSI. Кроме того, мы расскажем о диалоге Project | Options, в котором задаются различные параметры, управляющие компиляцией программы.

Директивы препроцессора

Препроцессорная обработка представляет собой первую фазу того процесса, что именуется компиляцией программы на C/C++. Компилятор C++Builder не генерирует промежуточного файла после препроцессорной обработки. Однако, если хотите, можно посмотреть на результат работы препроцессора, запустив отдельную программу срр32.ехе из командной строки: срр32 myfile.c

Макроопределения

Макроопределения, называемые в просторечии макросами, определяются директивой препроцессора #define. Можно выделить три формы макросов #define: простое определение символа, определение символической константы и определение макроса с параметрами. Простое определение выглядит так: #define NDEBUG

После такой директивы символ NDEBUG считается определенным. Не предполагается, что он что-то означает; он просто — определен (как пустой). Можно было бы написать: #define NDEBUG 1

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

Как вы могли бы догадаться, #define может определять не только константы. Поскольку препроцессор выполняет просто текстовую подстановку, можно сопоставить символу и любую последовательность операторов, как показано ниже:

#define SHUTDOWN printf("Error!"); \ return -1

if (ErrorCondition()) SHUTDOWN; // "Вызов" макроса.

Обратная дробная черта (\) означает, что макрос продолжается на следующей

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

Определенный ранее макрос можно аннулировать директивой #undef:

#undef NDEBUG

После этого макрос становится неопределенным, и последующие ссылки на него будут приводить к ошибке при компиляции.

Предопределенные макросы

Компилятор C++Builder автоматически определяет некоторые макросы. Их можно разбить на две категории: макросы ANSI и макросы, специфические для C++Builder. Сводки предопределенных макросов даны соответственно в таблицах 4.1 и 4.2.

Таблица 4.1. Предопределенные макросы ANSI

Макрос Описание

DATE Литеральная строка в формате “mmm dd yyyy”, представляющая дату

обработки данного файла препроцессором.

FILE Строка имени текущего файла (в кавычках).

LIME Целое, представляющее номер строки текущего файла.

STDC Равно 1, если установлена совместимость компилятора со стандартом

ANSI (ключ -А командной строки). В противном случае макрос не определен.

TIME Строка в формате “hh:mm:ss”, представляющее время препроцессорной

обработки файла.

Значения макросов _file_ и _line_ могут быть изменены директивой #line (см. далее).

Таблица 4.2. Предопределенные макросы C++Builder

Макрос Значение Описание

ВСОРТ 1 Определен в любом оптимизирующем компиляторе.

BCPLUSPLUS 0х0540 Определен, если компиляция производится в режиме C++. В

последующих версиях будет увеличиваться.

BORLANDC 0х0540 Номер версии.

CDECL 1 Определен, если установлено соглашение о вызове cdecl; в противном случае не определен.

CHARUNSIGNED 1 Определен по умолчанию (показывает, что char по умолчанию есть unsigned char). Можно аннулировать ключом -К.

CONSOLE Определен при компиляции консольных приложений.

CPPUNWIND 1 Разрешение разматывания стека; определен по умолчанию. Для аннулирования можно применить ключ -xd-.

cplusplus 1 Определен при компиляции в режиме C++.

DLL 1 Определен, если компилируется динамическая библиотека.

FLAT 1 Определен при компиляции в 32-битной модели памяти.

MIХ86 Определен всегда. Значение по умолчанию — 300. (Можно изменить значение на 400 или 500, применив соответственно ключи /4 или /5 в командной строке.)

MSDOS 1 Целая константа.

MT 1 Определен, если установлена опция -WM. Она означает, что будет

присоединяться мультили-нейная (multithread) библиотека.

PASCAL 1 Определен, если установлено соглашение о вызове Pascal.

TCPLUSPLUS 0х0540 Определен, если компиляция производится в режиме C++ (аналогично bcplusplus ).

TEMPLATES 1 Определен для файлов C++ (показывает, что поддерживаются шаблоны).

TLS 1 Thread Local Storage. В C++Builder определен всегда.

TURBOC 0х0540 Номер версии (аналогичен BORLANDC ).

WCHAR T 1 Определен только в программах C++ (показывает, что wear t — внутренне определенный тип.

WCAR T DEFINED 1 То же, что и WCHAR Т.

Windows Определен для кода, используемого только в Windows.

WIN32 1 Определен для консольных и GUI-приложений.

Как видите, многие предопределенные макросы C++Builder отражают те или иные установки параметров компиляции, задаваемые в командной строке (при ручном запуске компилятора Ьсс32.ехе). Те же самые установки могут быть выполнены и в интегрированной среде через диалог Project Options, который мы еще будем рассматривать в этой главе.

Макросы с параметрами

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

#define PI 3.14159265

#define SQR(x) ( (x) * (x) )

#define AREA(x) (PI * SQR(x))

#define MAX(a, b) (<a)>(b) ? (a): (b))

circleArea = AREAfrl + r2);

cMax = MAX(i++, j++);

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

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

#define SQR(x) х*х binom = -SQR(a + b) ;

При расширении макроса получится: binom = -a + b*a + b;

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

Управление генерацией текста исходного модуля - макрогенерация. Построение макрорасширения и средства управления макрогенерацией. Параметры генерации и их определение и использование. Проверка результатов работы препроцессора (визуальный контроль).

Фазы трансляции. Сканирование исходника. Лексическая фаза работы транслятора. Синтаксическая фаза. Генерация кода. Входная и выходная информация на каждой фазе – таблицы транслятора. Оптимизация кода. Формат исполняемых (загрузочных) файлов. Задачи загрузчика и представление информации в загрузочном файле. Размещение информации в файле и движение загрузчика по информации.

Опции транслятора (компилятора) и компоновщика (линкера). Управление трансляцией и компоновкой через опции в тексте программы. Список опций и его применение. Настройка компилятора и компоновщика – вкладки Compiler,Linkerдиалогового окнаProjectOptions.

Создание файлов управления работой инструментов – командных файлов. Компоновка разно языковых программ.

Промежуточные формы представления программ. Таблицы транслятора, редактора связей, загрузчика, исполнителя (диспетчер задач). Структура объектных модулей. Распараллеливание исполняемых модулей на этапах компоновки, загрузки и реализации. Настройка инструментов преобразования программ на гиперконвейерные возможности микропроцессора. Turbo-оболочки - текстовой редактор, отладчик, компилятор, построитель заданий - maker, редактор связей. Покомандное построение текста. Организация работы текстовых редакторов. Стандартный набор функций редактора. Ускорение работ по написанию программ. Дополнительные инструменты турбо оболочек.

Visioпостроители , дизайнеры. Состав инструментария визуального проектирования. Настройка свойств визуальных компонент. Понятие «фокус» и принцип его использования в визуальном проектировании. Программная замена свойств объектов. Многообразие визуальных построителей, их классификация и сравнимые характеристики.

Библиотеки объектов. Инструменты работы с библиотеками и объектами. Набор стандартных и системных компонент. Пакетирование компонент. Дополнительные наборы компонент. Создание библиотек динамической загрузки. Пакетирование и встраивание компонент. Пакеты времени проектирования и времени исполнения. Использование пакетов. Методика встраивания пакета или отдельных компонент в библиотеку визуального построителя и используемый инструмент.

Основная литература: 4 осн.[135-144,194-215,240-250]

Контрольные вопросы:

  1. Этапы преобразования программы после создания исходного модуля?

  2. Что делает препроцессор?

  3. Что делает компилятор?

  4. Какие шаги составляют процесс компиляции, что является результатом компиляции и какие

таблицы строит компилятор?

  1. Что делает компоновщик и с какими объектами он работает?

  2. Когда необходим maker, что и как он экономит?

  3. Чем и в чем отличаются текстуальное и визуальное программирование?

  4. Зачем нужны пакеты и в чем их преимущества?

  5. Зачем нужны командные файлы и какова их роль в применении программного

инструментария?

Лекция 8. Средства визуального программирования –MSVisualStudio,BorlandDelphiи др.

Визуальное проектирование программ. Визуальные среды (Delphi,C++Builder, Power Builder(SY Base), Designer, Developer(Oracle), Visual Basic, Visual C++ и.др). Организация визуальной среды проектирования.RAD- редактор, отладчик, конструктор форм. Оценка продуктивностиRADчерез возможности: визуальной среды разработки, языка программирования, библиотеки шаблонов проектирования, компилятора, объектов хранения данных и инструментов работы с ними, объектов и инструментов сетевого программирования. 10 важнейших функций графической средыBorlandDelphi. Состав меню. Назначение и глубина построения отдельных пунктов меню. Дерево разделов меню.Coздание, открытие, сохранение проекта или группы проектов и их элементов. Функции, исполняемые разделами и пунктами меню. Раздел инструментов – дерево инструментов разработки. Внутренние и внешние инструменты. Image Editor, Win Sight, BDE, BDE Administrator, BD SQL Links, SQL Builder, SQL Monitor, Data Pump, Team Source, Code Insight, Repository и др. Панель горячих клавиш и ее использование. Панель объектов для использования в проекте - состав, группы компонент и набора групп, настройка панели на индивидуального проектировщика, пакетирование компонент. Панель визуального редактора – инспектора объектов. Организация доступа к свойствам компонент. Страница событий и ее использование для построения событийной картины взаимодействия компонент. Понятие фокуса. Активизация (фокусирование) объекта при проектировании и при исполнении программ обработки данных. Панель формы – контейнер проекта. Одно и многостраничные проекты. Переключение форм и панелей при проектировании и при исполнении. Модальность.

Типы файлов Delphi. Файлы форм (*.dfm), ресурсов (*.res), пакетов(*.bpl), проектов(*.dpr), приложений – модулей (unit’s) кадров, компонентов, общего доступа (*.pas), опций проекта и установок рабочего стола (*.dof, *.dsk), резервных копий – структура, назначение, инструменты создания и редактирования. Менеджер проектов и библиотека разработки. Список расширений имен файлов, связанных с пакетированием вDelphi:

bpl-пакетruntime, .dllфайл ОС адаптированный кlDelphi. Основное имя берется из .dpkили .dpkwsourceфайла.

Dcpбинарный образ, который содержит заголовок пакета и конкатенацию всех .dcuфайлов пакета, включая символы потребные компилятору.Простойdcpfileсоздается для каждого пакета. Основное имя из .dpkисточника. При использовании пакетов .dcpфайлы обязательно существуют.

dcu and pas- бинарные образы файлов модулей, входящих в пакет. Необходимы для каждогоunit.

dpk and dpkw– файлы источники, созданные программистом .dpkи .dpkwпакеты идентичны, ноdpkwрасширение используется для кросс-платформенных приложений, которые включают компоненты только изCLXбиблиотеки. Обычно используют компоненты иVCLиCLXбиблиотек.

Исходный модуль программы включает: заголовочную часть, где перечисляются подключаемые пакеты (uses); интерфейсную часть, где описаны используемые типы данных, в том числе и классы: исполнительную часть – имплементацию, - где описаны действия над информацией. При программировании в С++ заголовочные (.h-header)файлы описывают классы, а .с++ файлы -действия над экземплярами класса. Связывание модулей осуществляется командой #include.

Компиляция и связывание программ. Директивы компилятора.

«Процесс построения программы ( С++ Builder/ Гл1)

В этом разделе мы опишем “классический” процесс подготовки и трансляции программы на языке высокого уровня (в нашем случае это C++') в исполняемый файл, содержащий машинные инструкции и все остальное, что необходимо для работающей программы системы Windows. В C++Builder, как мы увидим в дальнейшем, детали этого процесса в основном скрыты от программиста и, кроме того, имеются дополнительные моменты, обусловленные спецификой визуального подхода к программированию. Создание программы на языке C++ выглядит примерно так. Прежде всего, программист с помощью того или иного текстового редактора готовит файлы исходного кода на C/C++. После этого происходит построение программы, в котором можно выделить такие этапы:

  • Компиляциюисходных файлов в файлыобъектного кода(с расширением .obj).

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

  • Компоновку ресурсов(ресурсы включают в себя битовые матрицы, курсоры, строковые таблицы, пиктограммы и т.п.). Это завершающий этап, на котором формируется конечный ехе-файл, запускаемый на выполнение. Этот процесс иллюстрируется рис. 1.1.

 

Рис. 1.1 Упрощенная схема построения программы

1. Source1.cpp 2. Source2.cpp 3. Source3.cpp 4. Компилятор

5. Source1.obj 6. Source2.obj 7. Source3.obj 8. Addon.lib

9. Код запуска 10. Исполнительная библиотека 11. Ресурсы App.res 12. Компоновщик

13. Компоновщик ресурсов

14. Приложение App.exe

Некоторые системы (и в том числе C++Builder) сразу выполняют компоновку объектных файлов с ресурсами, совмещая два последних этапа. Что касается первого шага — компиляции — то здесь возникает одна проблема, которую стоит обсудить.

Проблема раздельной компиляции

Когда-то давно программа для машины вроде БЭСМ-4, написанная на языке Алгол-60 или FORTRAN, состояла из одного-единственного файла, а точнее, являлась просто одной “колодой” перфокарт. Также и первые версии языка Pascal для PC (например, Turbo Pascal 2) допускали, по существу, компиляцию только программ, состоящих из единственного исходного файла. Компилятор “видел” сразу весь текст программы и мог непосредственно проконтролировать, например, количество и тип фактических параметров в вызове процедуры, — соответствуют ли они тем, что указаны в заголовке ее определения (формальным параметрам). Компилятор транслировал программу сразу в машинный код (исполняемый файл). С ростом сложности и объема программ пришлось разбивать их на несколько файлов исходного кода. Соответственно трансляция программы распалась на два этапа — компиляции, на котором каждый из исходных файлов транслируется в файл объектного кода, и компоновки, в результате которой из нескольких объектных файлов получается конечный исполняемый файл. При этом необходимо произвести, как говорят, разрешение адресных ссылок, когда, например, основной файл программы обращается к вспомогательной процедуре, находящейся в другом файле.

Компилятор C/C++ генерирует стандартные объектные файлы с расширением .obj. (Их формат определен фирмой Intel и не зависит от конкретной операционной системы.) Файлы эти содержат машинный код, который снабжен дополнительной информацией, позволяющий компоновщику разрешать ссылки между объектными модулями. Так, в начале файла формируются две таблицы: таблица глобальных символов (это имена объектов, определяемых в данном файле, на которые могут ссылаться другие модули программы) и таблица внешних ссылок (имена объектов в других файлах, к которым обращается данный модуль). Пользуясь информацией этих таблиц, компоновщик модифицирует код, подставляя в него соответствующие адреса.

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

Вязыке Turbo Pascal (и позднее — в Delphi) эта проблема была решена благодаря определению специального формата промежуточных файлов. Эти “объектные” файлы (в Delphi они имеют расширение ,dcu) содержат, помимо всего прочего, информацию о параметрах процедур и функций, об определяемых в модуле типах данных (классах) и т.д.

C/C++ был задуман как максимально универсальный язык, и потому он не может использовать нестандартный формат объектных файлов. Это сделало бы невозможным, например, создание файлов подпрограмм, которые могли бы включаться в программы, написанные на других языках. Возможность раздельной компиляции обеспечивается в C/C++ применением заголовочных файлов, присоединяемых к компилируемым исходным файлам на этапе препроцессорной обработки. Заголовки содержат прототипы функций, объявления типов и другую информацию, необходимую для раздельной компиляции исходных модулей программы. Заголовочные файлы (они имеют расширение .h или .hpp) подключаются к компилируемому файлу исходного кода (.с или .срр) с помощью директивы препроцессора #include, за которой следует имя заголовочного файла в кавычках или угловых скобках, например:

#include <stdlib.h> или #include "myfile.h"

Препроцессор заменяет директиву #include содержимым указанного файла; после завершения препроцессорной обработки полученный текст передается компилятору, который транслирует его в объектный код.

Во многих системах программирования на C/C++ препроцессор составляет единое целое с компилятором (это верно и для C++Builder). Тем самым ускоряется компиляция исходных файлов, и нет необходимости создавать промежуточный файл, содержащий обработанный препроцессором код. Однако в C++Builder имеется отдельный препроцессор срр32.ехе, запускаемый из командной строки. Вы можете им воспользоваться, если нужно просмотреть текст, получаемый в результате препроцессорной обработки; это может быть полезно, например, при отладке макросов препроцессора. Директивы препроцессора будут подробно рассматриваться в 4-й главе.

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

О библиотеках

Выше мы уже упоминали о библиотеках, не объясняя, впрочем, что они собой представляют. Конкретнее, мы имели в виду библиотеки объектных модулей; такая библиотека является просто собранием модулей объектного кода, скомпонованных в одном файле с расширением lib, своего рода архивом. На рис. 1.1 показана гипотетическая библиотека пользователя Addon.lib. Она могла бы быть создана из нескольких объектных модулей путем обработки их библиотекарем tlib32.exe.

На рисунке показаны также код запуска и исполнительная библиотека языка C/C++. Это необходимые элементы компоновки любой программы на С. Код запуска исполняется перед тем, как управление будет передано на входную точку вашей программы (функцию main, WinMain и т. п.). Среди задач, им выполняемых, можно указать следующие:

  • инициализация исполнительной библиотеки

  • конструирование глобальных объектов C++

  • завершение программы при отсутствии необходимых ресурсов.

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

  • управление файлами

  • управление памятью

  • преобразование данных и многое другое.

Что касается динамически присоединяемых библиотек — DLL, — то во многих случаях они, с точки зрения программиста, мало чем отличаются от обычных, статически компонуемых библиотек объектных модулей. Функция, которая находится в DLL, вызывается так же, как и всякая другая функция. Правда, “снаружи” динамическая библиотека выглядит скорее как исполняемый файл; эти библиотеки создаются не библиотекарем, а компоновщиком. Вообще-то вопросы разработки и использования DLL выходят за рамки этой книги, но в следующей главе мы приведем пример простейшей DLL, чтобы читатель получил представление о том, как это делается в C++Builder. Каждая библиотека, как правило, сопровождается своим заголовочным файлом (их может быть и несколько), который определяет интерфейс ее функций и других элементов. Исходный код библиотеки может быть и недоступен для программиста. Но в ее заголовочном файле (или файлах) имеется все необходимое для использования библиотеки в прикладной программе.»

Результаты компиляции Список опций компилятора и компоновщика. «Управление компилятором (С++Builder)В этом разделе мы рассмотрим установки диалога Project Options, имеющие отношение к программам на С. В основном это будет касаться страниц Compiler и Advanced Compiler этого диалога. Он открывается выбором Project | Options в главном меню.

Страница Compiler показана на рис. 4.1. В нижней части страницы вы видите две кнопки: Full debug и Release. Первая из них выполняет все установки параметров, позволяющие в полной мере использовать возможности отладчика C++Builder; вторая запрещает генерацию какой-либо отладочной информации и оптимизирует код для получения максимальной скорости выполнения. При изучении языка вам лучше всего воспользоваться кнопкой Full debug и не задумываться больше об установках, влияющих на отладку и эффективность кода.

  • Группа радиокнопок Code optimizationпозволяет полностью отключить оптимизацию, задать оптимизацию по скорости или выбрать отдельные опции оптимизации, включив радиокнопку Selected и нажав Optimizations. При этом откроется окно диалога со списком опций, в котором, кстати, показаны эквивалентные ключи командной строки, управляющие оптимизацией.

  • Группа Warningsуправляет выдачей предупреждений. Включив соответствующую радиокнопку, можно запретить все, разрешить все предупреждения или управлять выдачей отдельных предупреждений. Диалог Compiler Warnings также показывает ключи командной строки. Я бы советовал вам разрешить выдачу всех предупреждений. Грамотно написанный код должен транслироваться не только без ошибок, но и без всяких замечаний со стороны компилятора.

  • Раздел Pre-compiled headersуправляетпрекомпиляцией заголовочных файлов.

Объем кода заголовочных файлов, включаемых в модуль исходный модуль, может достигать тысяч, если не десятков и сотен тысяч строк. К тому же часто эти заголовочные файлы включаются в каждый модуль проекта. Поскольку при разработке программы заголовочные файлы приходится изменять сравнительно редко (а стандартные заголовки вообще не меняются), имеет смысл компилировать все необходимые заголовки один раз и создать файл специального вида, который будет содержать всю необходимую “заголовочную” информацию в форме, обеспечивающей максимально быстрый доступ к ней. Компилятор C++Builder может генерировать такие файлы (с расширением .csm), •во много раз ускоряющие повторное построение проектов. Недостатком их можно считать разве что весьма большой размер — типичный файл прекомпилируемых заголовков может занимать от пяти до десяти мегабайт.

Кнопка None запрещает использование прекомпилируемых заголовков. Кнопка Use pre-compiled headers разрешает генерацию и использование файла компилированных символов (это другое название файлов .csm). Кнопка Cache pre-compiled headers заставляет компилятор кэшировать прекомпилируемые заголовки, т. е. хранить их информацию в памяти, а не загружать csm-файл заново, когда в этом возникает необходимость. Это полезно, когда вы транслируете сразу несколько файлов, но может и замедлять компиляцию, если память

Рис. 4.1 Страница Compiler диалога Project Options

  • В поле редактирования File name задается имя файла компилированных символов.

  • В поле Stop after можно ввести имя файла, после компиляции которого генерация прекомпилируемых заголовков прекращается. Это должен быть файл, включаемый в исходный модуль непосредственно, а не в другом заголовке (как, например, windows.h включает массу других заголовочных файлов)

  • Раздел Debuggingуправляет включением отладочной информации в объектные файлы, создаваемые компилятором (флажки Debug information и Line numbers). Кроме того, флажок Disable inline expansions позволяет запретить расширения inline-функций, т. е. непосредственную вставку кода функции на месте ее вызова. Это упрощает отладку.

Если вы хотите отлаживать программу, то должны убедиться, что флажок Create debug information на странице Linker также установлен.

  • Раздел Compilingуправляет общими аспектами компиляции. При помеченном флажке Merge duplicate strings компилятор сопоставляет встречающиеся литеральные строки и, если две или более строк совпадают, генерирует только одну строку. Это делает программу несколько более компактной, но может приводить к ошибкам, если вы модифицируете одну из строк. При установке флажка Stack frames компилятор генерирует стандартныекадры стекафункций, т. е. стандартный код входа и возврата. Этот флажок должен быть установлен, если вы хотите отлаживать 'функции модуля. Если флажок сброшен, то для функций, не имеющих параметров и локальных переменных, будет генерироваться нестандартный, сокращенный код. При установке Treat enum types as ints компилятор отводит под перечисления 4-байтовое слово. Если флажок сброшен, отводится минимальное целое (1 байт, если значения перечислимого типа лежат в диапазоне 0-255 или -128-127). Show general messages разрешает выдачу общих сообщений компилятора (не являющихся предупреждениями или сообщениями об ошибках). Флажок Extended error information разрешает выдачу расширенных сообщений об ошибках компилятора (вплоть до контекста синтаксического анализатора и т. п. — простому человеку ни к чему).

Страница Advanced Compiler Эта страница (рис. 4.2) позволяет управлять деталями генерации объектного кода.

Рис. 4.2 Страница Advanced Compiler диалога Project Options

  • Группа радиокнопок Instructionset задает тип процессора целевой системы. Установки этой группы эквивалентны ключам командной строки -3, -4, -5 и -6.

  • Группа Data alignmentуправляет выравниванием данных в памяти. Выравнивание может отсутствовать (Byte), либо данные могут располагаться по адресам, кратным 2, 4 или 8 байтам. В структурах, если необходимо, вводятся байты заполнения. Установки группы эквивалентны ключам командной строки-an,гдеп —1, 2, 4 или 8.

  • Группа Calling conventionзадает соглашение о вызове, применяемое по умолчанию. (Register обозначает соглашение _fastcall.) Эквивалентные ключи командной строки — -рс (или -р-), -р, -рг и -ps.

  • Группа Register variablesуправляет созданием регистровых переменных. None запрещает их использование. Automatic разрешает компилятору размещать переменные в регистрах там, где это целесообразно, и Register keyword разрешает размещать в регистрах только переменные, объявленные как register. Радиокнопки соответствуют ключам -г-, -г и -rd.

  • Раздел Output имеет два флажка: Autodepedency information и Generate

  • underscores. Первый из них определяет, будет ли включаться в объектный файл информация о зависимостях между исходными файлами (необходимо для работы команды Make). Второй флажок указывает, что имена функций _cdecl должны снабжаться начальным символом подчеркивания. Установленные флажки соответствуют ключам -Х- и -и.

  • Раздел Floating pointуправляет генерацией кода арифметики с плавающей точкой. None показывает, что ваш код не использует чисел с плавающей точкой. Fast исключает промежуточные преобразования типов при арифметических вычислениях, как явные, так и неявные;

при сброшенном флажке все преобразования выполняются в строгом соответствии с правилами ANSI С. Correct Pentium FDIV генерирует код, исключающий возможность ошибки из-за дефекта в ранних версиях процессора Pentium. Соответствующие ключи командной строки — -f-, -ff и -fp.

  • Группа радиокнопок Language complianceзадает версию языка, с которой совместим компилируемый исходный код. Вы можете выбрать стандартный ANSI С, С с расширениями Borland, “классическую” версию Кернигана-Ричи и язык Unix V. При написании приложений Windows имеет смысл выбрать либо ANSI, либо Borland, если вы хотите использовать какие-либо ключевые слова из расширенного набора, описанного в этой главе. Флажкам соответствуют ключи -A (ANSI), -AT или -A- (Borland), -АК (К & R) и -AU (Unix V).

  • Раздел Sourceуправляет некоторыми аспектами интерпретации исходного кода. Флажок Nested comments разрешает вложенные С-комментарии, т. е. конструкции вида /*.../*...*/...*/. MFC compatibility позволяет транслировать код библиотеки MFC, используемой компилятором Microsoft Visual С. Поле Identifier length задает максимальное число значимых символов в идентификаторах языка С (в C++ длина идентификаторов не ограничивается).

Страница Directories/Conditionals. На этой странице диалога Project Options (рис. 4.3) расположены несколько полей редактирования, позволяющих задавать стандартные каталоги по умолчанию — библиотек, заголовочных файлов и т. д. Нас на этой странице интересует сейчас только раздел Conditionals.

В поле Conditional defines можно определять символы C/C++, языка Object Pascal и компилятора ресурсов, которые будут, например, управлять директивами условной компиляции в исходных файлах. Для присвоения символам значений используется знак равенства. Можно ввести в это поле сразу несколько определений, отделяя их друг от друга точкой с запятой, например:

NDEBUG;ххх=1;yyy-YES

Для ввода определений можно также воспользоваться редактором строк, отрывающимся при нажатии кнопки с многоточием. В командной строке символы определяются с помощью ключа -D:bcc32 -DNDEBUG -Dxxx=l -Dyyy=YES ...

Мы немного рассказали о ключах командной строки компилятора не столько для того, чтобы вы умели запускать bcc32.ехе вручную, а чтобы дать вам некоторыег начальные сведения, которые помогут вам разбираться в Ьрг-файлах проектов C++Builder. Полное руководство по запуску компилятора из командной строки вы можете найти в оперативной справке в разделах command-line compiler и command-line options.

Рис. 4.3 Страница Directories/Conditronals

Возможности управления компиляцией и связыванием. Защита от повторного запуска приложений. Инструменты VisualStudioих назначение и использование. Дерево возможностейMSVisualStudio.MS Visual Studio(MSV) ( Source Safe, Enterprise Tools, Tools, Language (Basic, C++, Fox Pro, Interdev)) – назначение каждого раздела и его состав. Особенности сетевого проектирования.

Основная литература: 5осн.[ 3,4]C++Buildergl1,2,14Delphi7gl1

Контрольные вопросы:

  1. Состав визуального построителя программ?

  2. Какие визуальные среды построения ПП Вам известны?

  3. Чем характерны сетевые среды разработки и реализации программ?

  4. Как настраивать среду разработки на разработчика?

  5. Как реализуется событийная составляющая в программах?

  6. Как минимизировать повторные работы при отладке ПП?

  7. Чем отличается запись объектов в DelphiиC++?

  8. Что такое библиотека компонент?

  9. Как структурирована библиотека компонент?

  10. Какие технологии позволяют вести визуальное построение ПП?

  11. Какие файлы входят в состав визуально созданного проекта ПП?

Лекция 9Подбор и редактирование компонент, разработка компонент.OpenТOOLsAPI.

Организация визуальной среды - инспектора свойств, событий и их использование. Методика доступа и изменения свойств объектов во время проектирования и исполнения программ. Списки значений свойств. Свойства, отображающие поведение и визуализацию объекта. TObject(TPersistent(TComponent(TControl(TGraphicControl,TWinControl)))) – дерево компонент.

MAKE.EXE– утилита для управлениякомпиляцией и линковкой в процессе отладки программы. РаботаMAKEоснована на временных и информационных зависимостях между исходными и объектными файлами. При повторной компиляции и связыванииMAKEизменяет ( компилирует, связывает) только те файлы, которые модифицируются при отладке, что существенно снижает время подготовительной работы. Необходимость перекомпиляции файла определяется по временным меткам, т.е. если время изменений файла и время текущей компиляции проекта совпадают, производится перекомпиляция В текстеMAKEпрограммы записаны правила перестройки программ проекта и источники для выполнения этих работ. Синтаксис для MAKE программ:

MAKE [options...] [target[target]]

options

are MAKE options that control how MAKE works

target

is the name of the target listed in the makefile that you want to build

Набор стандартных компонент разработки. Графические компоненты. Палитра компонент, предоставляемая разработчику – состав, назначение страниц палитры, визуальные и не визуальные компоненты (свойство видимости), изменение представления и места размещения компоненты на форме (свойства визуализации).При работе с графикой используются два термина - drawingandpainting.Drawingиспользуется при создании элементарных графических объектов (линии, фигуры) в кодовом представлении. Для этого используется панель отрисовки - палитра (objectcanvas) и методы объектаcanvas.Painting– понятие, которое означает манипулирование элементарными графическими объектами. Следующий список действий дизайнера позволяет упростить работу с графикой.

Refreshing the screen (Перерисовка экрана)

Types of graphic objects (Типы объектов)

Common properties and methods of canvases (Общие свойства и методы палитры)

Handling multiple drawing objects in an application (Ручное рисование в приложении)

Drawingonabitmap(Рисование на битовом поле)

Loadingandsavinggraphicsfiles(Загрузка и сохранение графических файлов)

Using the clipboard with graphics (Использование буфера для графики)

Rubber banding example (Пример)

Создание компонент и пакетов компонент, их использование. Методика визуального проектирования компонент. Подключение и разработка собственных компонент. Можно создать новый компонент двумя способами – вручную или с использованием мастера компонент (Componentwizard). Можно создать компонент с минимальной функциональностью и инсталлировать его на палетту компонент. Затем протестировать его вdesigntimeandruntime. Затем можно дополнять компонент свойствами, событиями методами, проводя тестирование. Основные шаги разработки:

1 Create a unit for the new component. (Создать модуль для нового компонента)

2 Derive your component from an existing component type. (Определить родительский тип)

3 Add properties, methods, and events. (Добавить свойства, методы, события).

4 Register your component with the IDE. (Регистрировать компонент)

5 Create a bitmap for the component. (Создать ярлык)

6 Create a package (a special dynamic-link library) so that you can install your component in the IDE.

7 Create a Help file for your component and its properties, methods, and events. (Создать помощь).

По завершению работ вы получите следующие файлы:

Apackage(.BPL)orpackagecollection(.DPC)file(файлы пакета или коллекции)

A compiled package (.DCP) file (файл компиляции)

A compiled unit (.DCU) file (объектный файл)

A palette bitmap (.DCR) file (файл ярлыка)

A Help (.HLP) file (файл помощи)

Интерфейсы OpenToolsAPIПостроение мастеров. Все функции инструментария -ToolsAPI- продекларированы в одном модуле,ToolsAPI. Для использования модуль вставляют в пакет разработки, что приводит к появлению добавляемогоdesign-timepackageили созданиюDLL, вставляемого вruntimepackages.

Основной интерфейс для написания инструментов - ToolsAPI– сосредоточен вIOTAWizard, т.е. большинствоIDEadd-ins(добавок-вставок) вызываются мастерами. МастераC++BuilderиDelphi, для большинства инструментов интероперабельны (переносимы, межплатформенны), т.е. можно создатьwizardinDelphi, а затем использовать его вC++Builder.

Для использования ToolsAPI, пишутсяwizardclasses, которые имплементируют интерфейсы, определенные вToolsAPIunit. Мастер использует сервисы, которые предлагаетToolsAPIКаждый сервис – интерфейс, который представлен группой функций. Имплементация интерфейса скрыта вIDE.ToolsAPIделают доступным только интерфейс но не его имплементацию. Переменные сервисов делают доступными редактор исходников,дизайнер форм, отладчик и т.д.(sourceeditor,formdesigner,debugger,andsoon.See Obtaining Tools API services for information about using the interfaces that expose services to your wizard).

Сервисы и другие интерфейсы разделены на две категории, что зафиксировано в префиксах - NTAиOTA.NTA(nativetoolsAPI) обеспечит прямоц доступ к действующимIDEобъектам, таким, например, какTMainMenu. Когда используется такой интерфейс, мы привязываемся к специфической версииIDE. Результат может быть представлен какdesign-timepackageили какDLLфайлruntimepackages.OTA(opentoolsAPI) не требует пакетирования и доступа кIDEтолько через интерфейс. Теоретически, можно написатьwizardна любом языке, который поддерживаетCOMинтерфейсы.OTAинтерфейсы не гарантируют полный доступ кIDE, но обеспечат полноту функций доступных черезOTAinterfaces. Еслиwizardиспользует толькоOTAinterfaces, возможно написатьDLLкоторые не зависят от специфических версийIDE.

ToolsAPIпорождает два вида интерфейса, тот, который имплементирует программист и тот, который имплементируетIDE. Большинство последних определяют возможностиIDE, но скрывают имплементацию возможностей. Наследники интерфейсов которые имплементируете вы делятся на три категории: мастера (wizards), описатели (notifiers), создатели (конструкторы,creators):

Как сказано ранее, wizard classимплементируетIOTAWizardинтерфейс и измененные интерфейсы. Описатели (notifier) – другой вид интерфейсов, которыеIDEиспользует для определения обратного вызова к скрытым объектам. Пишется класс, который имплементируетnotifierinterface, который затем регистрируем черезToolsAPI, и затем используется обратный вызов для открытия файлов, редактирования исходного кода, старта сессии отладчика и т.п.. Описатели скрыты в описанииIDEсобытий.

Конструктор (creator) другой тип интерфейсов, который необходимо имплементировать. Используется для создания новых модулей, проектов и других файлов, или для открытия существующих.

Связывание объектов программ. Построение отчетов. Менеджеры, редакторы, мастера (wizards). Мастер построения компонент -Componentwizard–упрощает создание нового компонента. Для создания необходимо: 1) определить родительский класс (Theclassfromwhichthecomponentisderived.); 2) дать имя новому классу (Theclassnameforthenewcomponent.); 3) определить страницу палетты компонент, на которую будет установлен новый (TheComponentpalettepagewhereyouwantittoappear.); 4) определить имя модуля, в котором создается компонент (Thenameoftheunitinwhichthecomponentiscreated.); 5) указать путь к модулю – полное имя (Thesearchpathwheretheunitisfound.); 6) определить имя пакета, где размещается новый компонент (Thenameofthepackageinwhichyouwanttoplacethecomponent.).

Мастер компонент (Componentwizard) реализует 3 задачи, при создании компонента вручную: создание модуля (Creatingaunit); изменение компонента (Derivingthecomponent): регистрация (Registeringthecomponent). Мастер не может добавить компонент в существующий модуль. Необходимо вручную добавлять компонент в существующий модуль.

Основная литература: 5 осн. [3]C++Вuilder–gl15

Контрольные вопросы:

  1. Как можно создать собственный компонент?

  2. Какие программные инструменты используются при создании компонент?

  3. Чем отличаются категории интерфейсов и сервисов с префиксами NTAиOTA?

  4. Какова последовательность действий разработчика компонент?

  5. В чем различается работа при создании исполняемых файлов компонент вида dllиexe?

Лекция 10. Построение интерфейса программы. Принципы разработки инструментария. Инструментальные средства и методы построения интерфейса.

« (Delphi7, гл.8)Компонент TActionList , это — централизованное хранилище, где воздействия со стороны пользователя связываются с реакциями на них.

Действием (Action) будем именовать операцию, которую пользователь хочет произвести, воздействуя на элементы интерфейса. Тот компонент, на который он хочет воздействовать, называется целью действия (Action target). Компонент, посредством которого действие инициировано (кнопка, пункт меню), — клиент действия (Action client). Таким образом, в иерархии классов Delphi действие TAction — это невизуальный компонент, который играет роль "черного ящика", получающего сигнал от одного или нескольких клиентов, выполняющих действия над одной (или разными) целями.

Примечание  Действия могут работать только будучи объединенными в список компонентов TActionList или TActionManager. Вне этих компонентов применение действий невозможно.

Спроектировав на бумаге пользовательский интерфейс, начните работу с помещения на форму компонента TActionList. Он находится в Палитре компонентов на первой странице Standard (вот видите какое ему уделяется внимание!). После этого следует запустить редактор списка действий двойным щелчком мышью на компоненте или с помощью контекстного меню .

Добавление действий. Для программиста предусмотрен набор типовых, наиболее часто встречающихся действий, которые описаны в следующем разделе. Помимо них можно вставить и обычное действие, которое получит имя Action1. Итак, что же из себя представляет действие? ..

События, связанные с действиями Компонент TAction реагирует на три события: OnExecute, OnUpdate И OnHint.

Первое — и самое главное — должно быть как раз реакцией на данное действие. Это событие возникает в момент нажатия кнопки, пункта меню — короче, при поступлении сигнала от клиента действия. Здесь — как правило—и пишется обработчик. Почему "как правило"? Потому что схема обработки сигнала 4-этапная:

1. Сначала вызывается обработчик события OnExecute списка действий

TActionList:

property OnExecute: TActionEvent; TActionEvent = procedure (Action: TBasicAction; var Handled: Boolean)

of object;

Если обработчик этого события вами не предусмотрен, или в параметре Handled он вернул значение False, происходит генерация следующего события — шаг 2.

2. Вызывается обработчик события onActionExecute глобального объекта Application (тип события тот же — TActionEvent). Если и оно не обработало сигнал действия, переходим к следующему шагу.

3. Вызывается обработчик события onExecute самого действия (объекта типа TAction или его потомка).

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

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

Введение события onupdate является очень хорошей находкой, о нем напишем подробно. И автор этих строк, и, возможно, вы потратили немало времени, чтобы в разрабатываемых программах элементы управления находились в актуальном состоянии. Если, скажем, вашей программой открыт первый файл, то нужно активировать ряд кнопок и пунктов меню (Save, Save as, Print и т. п.); как только закрыт последний — отключить их. Если в буфере обмена есть что-то подходящее, необходимо активизировать пункт меню и кнопку Paste, если нет — отключить. В результате код, отслеживающий это, у неопытных программистов "размазывается" по всему приложению. А ведь можно поступить проще. Событие TAction.onUpdate возникает в моменты простоя приложения, т. е. тогда, когда оно не занято обработкой сообщений (цикл содержится в методе idle объекта Application). Это гарантирует, что оно возникнет ДО ТОГО, как пользователь щелкнет мышью и увидит выпадающие пункты меню; поэтому можно успеть обновить их состояние. Пример использования события onupdate:

procedure TForml.PasteActionUpdate(Sender: TObject); begin

TAction(Sender).Checked := Clipboard.HasFormat(CFJTEXT);

 end;

Примечание Перед вызовом события onupdate также происходит 4-этапная последовательность действий, точно такая же, как при OnExecute.

Третье событие имеет такой тип:

THintEvent = procedure (var HintStr: string; var CanShow: Boolean) of object;

Оно вызывается тогда, когда от элемента управления требуется показать подсказку, связанную с данным действием. В обработчике события можно указать, будет ли что-нибудь показываться (параметр CanShow) и, если да, то что именно (параметр Hintstr).

Это были события, относящиеся к компоненту TAction. Сам компонент TActionList также имеет три события: OnExecute, OnUpdate И OnChange. О первых двух мы уже сказали; третье происходит в момент изменения списка (добавления или удаления действий).

Свойства, распространяемые на клиентов действияЕсли у нескольких кнопок или пунктов меню общий обработчик, разумно потребовать, чтобы у них были и другие общие свойства. Так оно и реализовано в Delphi. Действие также можно снабдить картинкой. Компонент TActionList связывается со спискомкартинок TimageList, а действие TAction — с конкретной картинкой через свойство imageindex. Таким образом, все элементы управления, связанные с действием, — кнопки и пункты меню — будут иметь одну и ту же картинку. …

Если вы не думаете о переносе своего приложения в среду Linux, то имеются все основания воспользоваться потомком TActionList — компонентом TActionManager (далее в тексте — менеджер действий). Более современный и "продвинутый" он обеспечит вас многими дополнительными возможностями. Будучи применен сам по себе, компонент TActionManager ничем не отличается от предшественника. Отличия проявляются, если действия из этого компонента разместить на специальных панелях — TActionMainMenuBar (будем называть его панелью главного меню) и TActionToolBar (далее — панель действий).

На первой странице редактора TActionManager (вызывается двойным щелчком или командой Customize из контекстного меню) как раз и содержится список всех панелей, связанных с данным менеджером действий. Вы можете добавить новый или убрать компонент TActionToolBar нажатием кнопок New и Delete соответственно. С компонентом TActionMainMenuBar так по понятным причинам поступить нельзя — меню полагается иметь одно.

Когда вы перетаскиваете действие на панель, на нем появляется специальный компонент, похожий на пункт меню или кнопку. Его роль — служить клиентом данного действия. Поэтому, естественно, он сразу и автоматически получает нужные Caption, imageindex, Hint и прочие общие для всех клиентов свойства, о которых говорилось выше. Класс этого клиента — TActionclientitem; будем называть их псевдокнопками или псевдоэлементами.

При перетаскивании нет особых сложностей, но надо иметь в виду следующие аспекты:

  •  при перетаскивании всей категории на панель главного меню она появляется в виде пункта меню верхнего уровня и содержит при этом все свои дочерние действия;

  •  при перетаскивании всей категории на панель действий создаются псевдокнопки для всех дочерних действий в категории. Логично поступить по принципу "одна категория — одна панель действий", это будет полезно для настройки интерфейса пользователем;

  •  если вы ошиблись при перетаскивании, не нажимайте кнопку Delete — при этом удалится не только псевдокнопка, но и само действие. Перетяните ненужный псевдоэлемент за пределы панелей действий, тогда он будет удален;

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

Стандартный интерфейс систем. Пример разработки интерфейса – MSVisualSystems,BorlandVisualSystems,OracleVisualSystemsи др. Решения, достоинства, недостатки, характеристики – мобильность, глубинность, цвет, размерность, анимация, масштабируемость, надежность, скорость доступа и др.. Элементы стандартных интерфейсов систем и их компонентная реализация. .

Минимизация вмешательства. Уровень автоматизации и защиты от некомпетентности. Сеансы и цепочки действий. Использование шаблонов и предистории. Многообразие и мобильность представления. Использование систем, – инструментов, деловой графики.

« Как избежать одновременного запуска двух копий одного приложения.

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

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

Пример такого ресурса — общий блок в файле, отображаемом в память. Поскольку этот ресурс имеет имя, можно сделать его уникальным именно для вашего приложения:

var UniqueMapping : THandle;

FirstWindow : THandle

; begin

UniqueMapping := CreateFileMapping($ffffffff,

nil, PAGE_READONLY, 0, 32,'MyMap');

if UniqueMapping = 0 then

begin ShowMessage(SysErrorMessage(GetLastError)); Halt; end

else if GetLastError = ERROR_ALREADY_EXISTS then

begin FirstWindow := FindWindowEx(0, 0, TfmMain.ClassName, nil);

if FirstWindowoO then SetForegroundWindow(FirstWindow}; Halt; end;

// Нет других копий — продолжение Application.Initialize;

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

Блок совместно используемой памяти выделяется в системном страничном файле (об этом говорит первый параметр, равный -1, см. описание функции

CreateFileMapping). Его имя — муМар. Если при создании блока будет получен код ошибки ERROR_ALREADY__EXISTS, это свидетельствует о наличии работающей копии приложения. В этом случае приложение переключает фокус на главную форму другого экземпляра и завершается; в противном случае процесс инициализации продолжается. ..»

Размещение на экране. Одно- и многостраничный интерфейс. Модальные окна и фокус. Панели, фреймы, деревья, графы, сети – информационные модели визуального отображения событийной парадигмы. Концентрация и обобщенность размещения интерфейса. Многостраничность и многопроцессность интерфейса. Смена изображений – действия в программе. Активация элементов интерфейса и использование фокуса. Модальность формы – плюсы и минусы.

Технологии, обеспечивающие визуальное проектирование интерфейса. Раскраска. Библиотека графического интерфейса операционных систем. Графические библиотеки визуальных построителей программ. Графически ориентированные системы. Форматы графических файлов – носителей графической информации. Экспорт – импорт графических форматов. Графические возможности микропроцессора – типы данных, операции, видеосистема

Сменяемость окон и порядок их размещения. Оконная парадигма и ее предистория. Передний план и фон. Группировка окон. Частичное и обобщенное отображение. Активация оперативного.

Организация подсказок. MSWord– пример организации подсказок. ПИК, как обучатель и стимулятор роста интеллекта. Подсказки – контекстность, конкретность, многослойность, визуальность, переносимость, настраиваимость, динамическая (оперативная) тестируемость.

Требования эргономики и инженерной психологии к интерфейсу. Не более 7 объектов в поле зрения, нейтрал раскраса, раздражители внимания, понятная (дружественная) мнемоника и визуализация, максимум автоматического.

Интерфейсные объекты визуальных дизайнеров и их использование при построении интерфейса. Ветвь IInterfaceв дереве компонент. НаследникиIInterface. Инструменты использованияIInterfaceи наследников.

Создание редактора свойств. Редакторы компонент. Категории свойств. Пример разработки инструмента с использованием инструмента существующего..

Расширение оболочки Windows– мастер СОМ объектов, обработчики перемещений, контекстного меню, пиктограмм. Пример разработки инструмента с использованием инструмента существующего.

Основная литература: 5 осн. [ (4)Delphi7 –gl 5,6, 7,8]

Контрольные вопросы:

  1. Какие элементы используются в стандартном интерфейсеWindows?

  2. Где расположены эти элементы?

  3. Где в программе м.б. размещены элементы интерфейса?

  4. Какие действия разработчика связаны с созданием интерфейса?

  5. Каков формат файлов графики стандартно используется в интерфейсеWindows?

  6. Что представляют собой объекты IInterfacе?

  7. Как группируются объекты реакции на события?

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

элементов интерфейса?

Соседние файлы в папке litra