69286

Керування документами та представленнями

Лекция

Информатика, кибернетика и программирование

Оскільки архітектура документ/представлення є наріжним каменем будь-якого документ - орієнтованого застосування (як вже було сказано, діалогові застосування потрійні трохи інакше, чим додатки архітектури документ/представлення), класи MFC повинні володіти здатністю створювати...

Украинкский

2014-10-02

47.5 KB

0 чел.

Лекція № 6

Тема: Керування документами та представленнями

План

  1.  Документи та представлення
  2.  Фреймові вікна
  3.  Ресурси шаблону документу

Керування документами і представленнями

Оскільки архітектура документ/представлення є наріжним каменем будь-якого документ - орієнтованого застосування (як вже було сказано, діалогові застосування потрійні трохи інакше, чим додатки архітектури документ/представлення), класи MFC повинні володіти здатністю створювати і видаляти об'єкти класів, що реалізовують архітектуру документ/представлення. У зв'язку з тим, що додаток здатний забезпечувати декілька типів взаємин документ/представлення, класи MFC повинні володіти можливістю з'ясовувати, які саме класи документа, представлення і відображення використовуються, які відносини між цими класами, а також, як створювати об'єкти цих класів під час виконання програми. Не дивлячись на те, що один документ може підтримувати декілька різних типів представлень, цілком можлива ситуація, коли асоціація інших представлень з даним документом може виявитися безглуздою.

Створивши проект додатку SDI, можна відмітити, що у функцию-член Initlnstance об'єкту додатку майстер АррWizard додає код створення шаблону документа. Цей код може виглядати подібно до приведеного нижче (ім'я додатку — SDIApp):

BOOL CSDIAppApp::Initlnstance () {

CSingleDocTemplate* pDocTemplate;

pDocTemplate = new CSingleDocTemplate{

IDR_MAINFRAME

RUNTIME_CLASS(CSDIAppDoc)

RUNTIME_CLASS(CMainFrame) // головне фреймове вікно SDI

RUNTIME_CLASS(CSDIAppView)

);

AddDocTemplate(pDocTemplate);

Отже, розглянемо, що саме робить даний код. Після розміщення в стеку покажчика на клас CSingleDocTemplate здійснюється виклик конструктора класу, якому передається чотири параметри. Перший параметр — це ідентифікатор ресурсу. Докладніша інформація про ідентифікатори ресурсів приводиться далі в цьому розділі. Другим, третім і четвертим параметрами конструктора класу CSingleDocTemplate є покажчики на інформацію про класи часу виконання (runtime class information). Макрокоманда RUNTIME_CLASS створює покажчик на інформацію про класи часу виконання для певного класу. В даному випадку такий підхід використовується для доступу до інформації про класи документа, головного вікна і представлення додатку. Це зроблено для того, щоб клас CSingleDocTemplate міг динамічно створити ці об'єкти і сформувати таким чином повний комплект, необхідний для забезпечення архітектури документ/представлення.

Об'єкт CSingleDocTemplate існує впродовж всього періоду виконання додатку. Класи MFC використовують його як контейнер, а при завершенні роботи додатку (і видаленні об'єкту CWinApp) всі шаблони документа, додані в цей об'єкт, також будуть видалені. У складі функції CWinApp: : Initlnstance знаходиться фрагмент коди, яка розміщує в пам'яті екземпляр класу CSingleDocTemplate даного застосування (CWinApp), а наявність коди, що видаляє об'єкти шаблону документа, можна уникнути, якщо використовувати для їх створення шаблон AddDocTemplate. Це пов'язано з тим, що функція-деструкція CWinApp автоматично видалить все, що було розміщене в пам'яті шаблоном документа.

 

Фреймові вікна

Про взаємодію документів і фреймів вже згадувалося, тепер розглянемо цю тему детально. Не дивлячись на те, що безпосередньо з класами фреймів доводиться працювати не так часто, як з класами документів і представлень, читач, ймовірно, вже усвідомив, наскільки важливе правильне розуміння ролі фреймів в додатку з архітектурою документ/представлення.

Фактично, представлення реалізовані в додатку у вигляді вікон, але не контекстних або фреймових, а у вигляді дочірніх вікон, що не мають ні рамок, ні власних меню. Таким чином, ці вікна повинні знаходитися усередині спеціальних фреймових вікон. Класи MFC розташовують вікно представлення в клієнтській області (client area) фреймового вікна, вказаного в конструкторі шаблону документа. У додатку SDI фреймове вікно завжди є головним вікном (main window) додатку. Представлення, що містять, фреймові вікна додатків багатодокументного інтерфейсу є дочірніми вікнами (child window).

При розробці додатків Windows більшість програмістів не роблять ніяких додатковий дій, щоб відокремити клієнтську область додатку від фреймового вікна. Замість цього зазвичай створюють вікно в стилі WS_OVERLAPPED і працюють прямо в його клієнтській області. Для розділення завдань класів MFC, корпорація Microsoft реалізувала їх так, щоб існувало два різних типи фреймових вікон, які можна використовувати залежно від обставин, тобто в бібліотеці MFC фреймові вікна SDI відрізняються від фреймових вікон MDI як внутрішньо, так і зовні. Докладніша інформація про фреймові вікна приводиться далі, а поки досить зрозуміти, що саме фреймове вікно отримує всі повідомлення від меню і рамок вікон.

Повідомлення рамок вікна (window frame message) отримують лише ті вікна, які володіють рамками. Такі повідомлення містять інформацію про зміну розмірів вікна, його розгортання, згортанні і так далі Крім того, фреймове вікно отримує достатньо багато повідомлень з областей, що не відносяться до клієнтської, оскільки фреймове вікно несе відповідальність за реалізацію і неклієнтській області (nonclient area) вікна додатку.

Ресурси шаблону документа

Першим параметром конструктора класу CSingleDocTemplate є ідентифікатор ресурсу (resource ID). Подібні ідентифікатори застосовуються для вказівки ресурсів, використовуваних для вкомплектовування фрейма таблицею акселераторів (accelerator table), меню, піктограмою і панеллю інструментів, в чому легко переконатися, створивши в середовищі розробки простий додаток SDI і відкривши панель Resource View (Ресурси) середовища розробки. У цій панелі всі вищезгадані типи ресурсів будуть відображені з однаковим ідентифікатором IDR_MAINFRAME. Не дивлячись на те, що зовсім необов'язково використовувати встановлене за умовчанням значення IDR_MAINFRAME, застосування, що розробляється, повинно використовувати однаковий ідентифікатор для кожного з типів ресурсу, що асоціюється з фреймовим вікном додатку. Такий підхід був задуманий і реалізований в бібліотеці MFC спеціально: застосування єдиного ідентифікатора дозволяє передати конструктору класу CSingleDocTemplate один параметр, а не цілий набір параметрів (але одному на кожен тип ресурсу).

Рядкові ресурси і шаблон документа

Рядковий ресурс (string resource) — колекція рядків, що зберігається у файлі ресурсу. Це якнайкращий спосіб зберігання рядкових значень додатку. По можливості, завжди використовуйте саме його, замість жорсткого завдання рядків в коді самого додатку. Такий підхід істотно підвищує гнучкість додатку, а також спрощує його подальший супровід. Один з цих рядків критично важливий для архітектури документ/представлення і повинна мати той же ідентифікатор, що і переданий в конструктор класу CSingleDocTemplate. Фактично, вона складена з семи підрядків, розділених символом нового рядка (\n). Підрядки є набором параметрів, що встановлюють тип документа додатку. Наприклад, такий рядок, типовий для додатку SDI, є в додатку SDIApp.

STRINGTABLE

BEGIN

IDR_MAINFRAME

"SDIApp\n\nSDIApp\n\n\nSDIApp.Document\nSDIApp.Document"

END

Ресурси представлення

Більшість решти ресурсів додатку вказана в шаблоні документа за допомогою ідентифікатора ресурсу (resource ID). Ці ресурси асоціюються з тим типом документа, з яким працює дане застосування. У створених майстром AppWizard додатках SDI для всіх ресурсів встановленого за умовчанням шаблону документа використовується ідентифікатор ресурсу на ім'я IDR_МАINFRAME.

Майстер AppWizard комплектує головне фреймове вікно додатку відповідним меню, яке також має ідентифікатор IDR_MAINFRAME; Це означає, що в додатках однодокументного інтерфейсу вид меню залежатиме від типу активного документа, а в додатках багатодокументного інтерфейсу кожен окремий тип документа матиме свій власний вид меню. Якщо необхідно, щоб для всіх типів документа використовувалося однакове меню, досить вказати в шаблоні кожного типу посилання на один і той же ресурс меню.

Фрейм містить піктограму, яка нарівні з рештою всіх ресурсів володіє тим же самим ідентифікатором. Ця піктограма представляє даний додаток SDI. Наприклад, вищезгадану піктограму операційна система відображає на кнопці панелі завдань, коли додаток буде згорнутий. У додатку багатодокументного інтерфейсу дана піктограма застосовується для згорнутих дочірніх вікон MDI, а піктограма, використовувана для всього застосування, знаходиться в іншому ресурсі.

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

Додаток може містити растрові ресурси (bitmap resource), які майстер AppWizard використовує для створення стандартної панелі інструментів фреймового вікна. Не дивлячись на те, що панель інструментів складається з окремих кнопок, самі малюнки на кнопках фактично є фрагментами єдиного зображення. Докладніша інформація про клас CToolbar, використовуваний в бібліотеці MFC для створення панелі інструментів, приводиться в розділі 6, "Рядок стану і панель інструментів".

Оскільки фрейм реалізує вікно, що містить меню, він повинен також підтримувати таблицю акселераторів (accelerator table). Таблиця забезпечує взаємозв'язок між натиснутими клавішами акселератора (комбінаціями клавіш) і повідомленнями WM COMMAND, які додаток повинен посилати у тому випадку, коли операційна система виявляє натиснуті клавіші. Середовище виконання сама поклопочеться про пошук таблиці акселераторів, а також про передачу і диспетчеризацію повідомлень, які операційна система формує у відповідь на натиснення користувачем відповідної клавіші. Стандартна таблиця акселераторів, що створюється майстром AppWizard, містить акселератори (вони ж комбінації клавіш) стандартних елементів призначеного для користувача інтерфейсу і меню.

Будь-яким з цих ресурсів можна відредагувати так, щоб він відповідав потребам даного застосування. Але для досягнення необхідної мети внесення змін тільки в ресурси може опинитися недостатньо. Тому, перш ніж вносити зміни до ресурсів, упевніться, що добре розумієте роботу класів, що використовують їх, щоб додаток залишився працездатним.


 

А также другие работы, которые могут Вас заинтересовать

50499. Создание типизованных файлов с использование элементов управления Edit, Button, GroupBox, RadioButton, CheckBox, ListBox 72 KB
  Цель работы Приобретение навыков работы с типизованными файлами использование в работе элементов управления Edit Button GroupBox RdioButton CheckBox ListBox и других для создания форм. Методические указания по самостоятельной работе студентов Типизованный файл это последовательность данных одинакового типа которая предназначена для долгосрочного хранения на внешних носителях. В C создание типизованных файлов осуществляется путём записи в файл блоков информации одинаковой длины.
50500. Моделирование работы программ в виртуальной памяти и исследование эффективности их выполнения 86.5 KB
  Имитационная модель страничных прерываний Программа моделирует процесс обработки страничных прерываний и выполнение алгоритмов замещения страниц при их отсутствии в физической памяти. Модель реализована в классе VM который сохраняет последовательность обращений к памяти исследуемого алгоритма трассировка и моделирует по ней страничные прерывания и алгоритмы замещения собирая при этом статистику. Для моделирования обращения к памяти используется метод VM::ccessint ddr int write который получает адрес обращения обычно это индекс в...
50501. Дослідження текстового та графічного режимів роботи EPSON-сумісних матричних принтерів 67.5 KB
  Висновок: у даній лабораторній роботі було розглянуто різні шрифти, які використовуються при друку, а також різні режими друку. Було створено програму, яка генерує коди, які розуміє принтер. На симуляторі принтера підтвердилася робочість програми і було роздруковано текст, зображення, а також візитку, яка містила 2 попередні пункти одночасно.
50502. Исследование функций и построение графиков в полярной системе координат 471 KB
  Обычно функции исследуются в декартовой системе координат, а графики функций, заданных в полярной системе координат, строят по точкам, не приводя полного исследования, подобное тому которое проводится в декартовой системе координат. Но построение графика по точкам не является математически строгим, так как например оно не позволяет определить интервалы возрастания и убывания функции, ее выпуклость и вогнутость или найти асимптоты.
50505. Створення фреймових web-сторінок 299 KB
  Тема: Створення фреймових webсторінок Мата: Навчитися за допомогою Microsoft Office ShrePoint Designer 2007 створювати фреймові webсторінки розібратися із параметрами webвузла. У даному вузлі створила фреймову webсторінку. Скопіювала цю папку в створений webвузол. За допомогою параметрів webвузла та переходів у створеній фреймовій сторінці у лівому фреймі розмістила webкомпоненти таким чином щоб у правому фреймі відкривався кожен із підручників.
50506. ПРИБОРЫ АНАЛОГОВЫЕ А542М 1.81 MB
  Перечень вложенных схем Приложение Г Схема электрическая принципиальная смонтированной платы прибора Приложение Е Схемы электрические соединений прибора: рисунок Схема электрическая соединений одноканального прибора; рисунок Схема электрическая соединений двухканального прибора Приложение Л Расположение элементов на плате канала измерения В связи с постоянной работой по совершенствованию изделий повышающей их надежность и улучшающей условия эксплуатации в конструкцию могут быть внесены незначительные изменения не...