ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 10.11.2023
Просмотров: 181
Скачиваний: 5
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
79 следнее не всегда бывает удобным с точки зрения интерфейса пользователя.
Для устранения этих и подобных недостатков нам придется вернуться в ре- жим изменения макета формы (кнопка Конструктор либо пиктограмма Вид на панели инструментов).
Рисунок48 – Форма Бумаги в режиме Автофильтра
На рис. 49 показана та же форма в режиме Конструктор.
Рисунок 49 – Форма Бумаги в режиме конструктора
Технология процесса проектирования форм в среде Access сводится к добавлению управляющих элементов и изменению их свойств. В связи с этим при переходе в режим Конструктор на экране по умолчанию появля- ются два дополнительных окна:
окно Панель элементов, которое предназначено для выбора очередного добавляемого к проектируемой форме управляющего элемента. В конст- руктор форм Access встроены такие элементы управления, как надпись, поле, кнопка, флажок, переключатель, список, набор вкладок и др. Поми- мо этого к форме можно подключать специальные (дополнительные) эле-
80 менты управления OLE, что значительно расширяет возможности разви- тия интерфейса управления данными.
окно свойств текущего элемента управления, предназначенное для изме- нения его атрибутов и настроек, например, цвета, шрифта, размера и т. п.
В режиме Конструктор явно видна структура формы. Она состоит из трех частей: Заголовок формы, Область данных и Примечание формы.
Такая структура в первую очередь ориентирована на возможности представ- ления таблично организованных данных. При этом как сама форма, так и ее разделы также рассматриваются как элементы управления, обладающие не- которыми настраиваемыми наборами свойств.
В качестве иллюстрации возможностей конструктора по изменению интерфейса ввода/вывода проведем следующие манипуляции над формой
Бумаги:
1. Удалим фоновый рисунок: очистим свойство Рисунок, когда текущим выбранном элементом является вся форма.
2. Изменим цвет фона: выберем элемент Область Данных и изменим у нее атрибут Цвет фона (рис. 50).
Рисунок 50 – Окно свойств элемента управления
3. Изменим внешний вид полей: выделим группу полей (поля выбираются с помощью мыши при нажатой клавише Shift) и в окне свойств изме- ним значение атрибута Оформление на Утопленное.
4. Отредактируем подписи полей и несколько изменим их расположение друг относительно друга: для этого достаточно воспользоваться воз- можностями визуального редактирования элементов.
5. Добавим разделительную линию после поля НаимБум (Наименование бумаги): для этого следует воспользоваться элементом Линия.
6. Добавим кнопку завершения работы с формой: в большинстве ситуа- ций эту и подобные операции проще и удобнее делать в режиме масте- ра (нажата соответствующая кнопка на панели Элементы управле-
81
ния). В этом случае от пользователя требуется лишь ввести минималь- ное количество параметров для добавляемого программного компонен- та. Добавленную кнопку поместим в область Примечания формы.
В результате отредактированная форма Бумаги примет вид, показан- ный на рис 51.
Рисунок 51 – Форма Бумаги после редактирования
Пример организации ввода/вывода данных в таблицу Бумаги с помощью одноименной формы носит в некотором смысле вырожденный характер: в нем структура полей в форме однозначно соответствует их структуре в таблице.
Однако, как правило, при создании реальных приложений приходится решать задачу управления данными, находящимися в системе взаимосвязанных таб- лиц, из единой формы. В качестве примера рассмотрим задачу построения формы, в которой для каждой данной бумаги одновременно выводится ин- формация по заявкам на ее покупку и продажу. Верхняя (заголовочная) часть формы соответствует текущей строке таблицы Бумаги и меняется при перехо- де от записи к записи, который может производиться с помощью стрелок, рас- положенных в нижней части окна. Одновременно должны меняться строки таблиц Заявки на продажу и Заявки на покупку, в которые выводится только информация, относящаяся к текущей бумаге.
Рассмотрим более подробно те средства Access, с помощью которых может быть получен такой результат. Это так называемая сложная/или со-
ставная форма (Заявки по бумагам). Процесс ее создания состоит из двух принципиальных этапов:
создание основной (главной) формы. Для этого осуществляются действия, аналогичные тем, которые выполнялись при создании формы Бумаги;
создание подчиненных форм. Для этого в созданную главную фор- му добавляется элемент управления Подчиненная форма.
При создании подчиненной формы в Access существует две принципи- альные возможности:
82
создать новую форму на базе некоторой таблицы или запроса;
воспользоваться уже существующей формой, сделав ее подчинен- ной.
В данном случае созданы две новые подчиненные формы. Причем соз- даны они на базе специальных запросов. Такое решение позволяет выделить по отдельности из общей таблицы Заявки записи с заявками на продажу и на покупку. В частности, запрос ЗаявПрод, возвращающий выборку из заявок на продажу ценных бумаг, имеет структуру, показанную на рис. 52.
Рисунок 52 – Структура запроса ЗаявПрод (заявки на продажу)
В качестве преимуществ такого подхода к организации источника дан- ных для подчиненной формы следует отметить следующие моменты:
во вспомогательном запросе достаточно просто обработать усло- вие, идентифицирующее тип заявки (если объем заявки меньше ну- ля, то это заявка на продажу). Более того, для конечного пользова- теля в качестве объема заявки вместо отрицательных величин вы- водятся выглядящие более естественно положительные значения:
1*[Объем3аявки];
данные выводятся отсортированными по возрастанию предлагае- мых цен, что несомненно упрощает процесс работы с ними в эк- ранной форме.
Запрос, возвращающий записи с заявками на покупку, создается анало- гично с учетом модификации условия отбора.
Наиболее существенным моментом в процессе внедрения подчиненной формы в главную является правильное задание условия связи между ними.
Во многих случаях с этим корректно справляются программные надстройки мастеров. При этом они используют информацию из схемы данных и описа- ний структуры таблиц. В то же время не следует забывать и о возможностях изменения условий связи между ведущей и подчиненной формами в ручном
83 режиме. Для этого необходимо изменить атрибуты в элементе управления
1 ... 4 5 6 7 8 9 10 11 12
Подчиненная форма, находясь в режиме Конструктор
7.2.6 Конструирование отчетов
Под отчетом традиционно понимается специальным образом структу- рированное представление хранимых данных, выводимое (как правило) на бумажный носитель. Перечислим принципиальные отличия отчетов от эк- ранных форм, обусловившие выделение их в отдельный программный объект
СУБД Access:
во-первых, отчеты являются исключительно средством вывода ин- формации;
во-вторых, организация данных в отчетах предполагает возмож- ность их сложного, многоуровневого структурирования;
в-третьих, структура информации, выводимой в отчете, должна быть согласована со структурой носителя. Например, разбиение отчета на страницы предполагает организацию вывода регулярных элементов в начале и конце каждого листа (колонтитулов), дубли- рование шапок таблиц и т.д. Также на внешний вид отчета значи- тельное влияние оказывают параметры конкретного печатающего устройства, которое будет использовано для его вывода.
В то же время, к числу важных достоинств Access относится то, что идеология работы как с экранными формами, так и с отчетами максимально универсализирована. В частности, интерфейс режима конструирования маке- та отчета аналогичен режиму конструктора для экранных форм.
Рассмотрим способы решения задач разработки отчетов, которые могут возникать в рамках описываемой нами программной системы управления торгами ценными бумагами. Простейшие отчеты, которые, скорее всего, бу- дут необходимы пользователям системы, – это распечатанные списки бумаг и агентов. Для их создания можно воспользоваться надстройками Автоотчет
в столбец или Автоотчет ленточный. На рис. 53 показан макет отчета по агентам, созданный в режиме Автоотчет ленточный.
Из рис. 53 видно, что в процессе конструирования в макет отчета могут быть добавлены те же самые управляющие элементы, что и при конструиро- вании макета экранной формы. В то же время следует отметить, что структу- ра отчета как объекта базы данных имеет свою специфику. Во-первых, она определяется уровнями группировки данных, выводимых в отчет, а во- вторых, содержит секции,
соответствующие регулярным элементам, поме- щаемым в начале и конце каждого листа – верхнему и нижнему колонтиту- лам. Для задания уровней группировки данных используется функция меню
Вид > Сортировка и группировка или же одноименная пиктограмма на па- нели инструментов Конструктор отчетов.
84
Рисунок 53 – Отчет по агентам в режиме конструктора
При работе с отчетами активно используются (это видно из рис. 53) встроенные переменные [Page] и [Pages], возвращающие номер текущей страницы отчета и общее, количество страниц в нем, а также функция Now(), определяющая текущую дату и время по системному календарю.
Остановимся теперь на более сложном примере. Поставим задачу по- строить отчет, выводящий сведения о спросе и предложении по ценным бу- магам с учетом их типа, то есть записи должны быть структурированы по следующим уровням:
все бумаги;
тип бумаги;
агент;
предложения агента по данной бумаге.
Также по каждому из уровней желательно предусмотреть вывод про- межуточных итогов (или же соответствующих средних значений).
Информация для данного отчета (назовем его РаспределЗаявок) должна браться из различных таблиц, поэтому в качестве источника данных для него целесообразно использовать специально построенный запрос. Для наглядно- сти приведем SQL-выражение, соответствующее данному запросу:
SELECT
Заявки.КодБум,
Бумаги.НаимБум,
Бумаги.Номинал,
Агенты.НаимАг,
IIf ([0бъем3аявки]<0,-1*[0бъем3аявки],0) AS ОбъемПродажи,
IIf ([ОбъемЗаявки]<0,[ЦенаЗаявки],0) AS ЦенаПродажи,
85
IIf ([0бъем3аявки]>0,[0бъем3аявки],0) AS ОбъемПокупки,
IIf ([ОбъемЗаявки]>0, [ЦенаЗаявки],0) AS ЦенаПокупки,
FROM Бумаги
INNER JOIN (Агенты INNER JOIN Заявки ON Агенты.КодАг = Заявки.КодАг)
ON
КодБум = Заявки.КодБум
ORDER BY IIf ([ТипБум]="1", "Акции", "Облигации"),
Бумаги.НаимБум;
На основе построенного запроса можно перейти к разработке отчета.
На начальном этапе представляется рациональным воспользоваться услугами мастера отчетов. Он в режиме диалога с пользователем позволяет создать по- ходящую "заготовку", избавляя нас от многих рутинных операций, например таких, как добавление полей и подписей к ним.
Далее полученный макет вручную "доводится" до желаемого вида в режиме Конструктор
Важным этапом при создании многоуровневого отчета является зада- ние уровней группировки выводимых данных. Это делается в окне, показан- ном на рис. 54, которое вызывается из меню Вид > Сортировка и группи-
ровка.
Рисунок 54 – Задание уровней группировки и сортировки
Для каждого из заданных уровней группировки данных могут быть оп- ределены раздел типа Заголовок, выводимый в начале каждой группы, и раздел типа Примечание, формируемый, когда группа заканчивается.
Задачи получения средних и итоговых значений по группам данных решаются с помощью встроенных функций Sum() и Avg(). Например, для получения среднего значения цены продажи бумаги в соответствующем эле- менте управления свойство Данные содержится строка:
=Avg([ОбъемПродажи]), а для определения итогового спроса используется формула:
=Sum([ОбъемПродажи]*[ЦенаПродажи]).