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, містить акселератори (вони ж комбінації клавіш) стандартних елементів призначеного для користувача інтерфейсу і меню.

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


 

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

4962. Выполнение простых операций на C++ 177.5 KB
  Выполнение простых операций Из урока 4 вы узнали, как объявлять и использовать переменные в своих программах. По мере усложнения программ вы будете выполнять арифметические операции, такие как сложение, вычитание, умножение и деление, над значениями...
4963. Отчет создания простой программы в Visual Studio 2012 447.93 KB
  Отчет создания простой программы Запускаем программу Visual Studio 2012 Запуск программы Visual Studio 2012 FIRST. СРР Удалила все содержимое и заменила на заранее приготовленный мной текст из блокнота. Вид глобальной обла...
4964. Технология модульного программирования 23.5 KB
  Технология модульного программирования Сущность технологии модульного программирования Технология модульного программирования заключается в разбиении программы на отдельные модули. Модуль должен обладать следующими основными свойствами: выполн...
4965. Создание новых типов данных 30.5 KB
  Создание новых типов данных Для представления данных о сложных физических и математических объектах необходимо создавать новые типы данных на основе базовых и ранее созданных. Структуры Наиболее простым способом создания нового типа данных является...
4966. Класс как основа технологии объектно-ориентированного программирования (ООП) 25.77 KB
  Класс как основа технологии объектно-ориентированного программирования (ООП) Основные составляющие технологии ООП Инкапсуляция – объединение элементов данных и действий над ними в класс с ограничением доступа к элементам данных. Это означает...
4967. Наследование как основа создания иерархии классов 22.18 KB
  Наследование как основа создания иерархии классов Наследование Наследование – создание новых классов на основе ранее созданных классов. Класс, на основании которого формируется новый класс, называют базовым (родительским) классом. Новый класс...
4968. Полиморфизм и виды его операций 30.97 KB
  Полиморфизм Полиморфизм – использование одного и того же имени функции, операции или класса для разных типов данных. Полиморфизм позволяет многократно не переписывать фрагменты программы, реализующие один и тот же алгоритм для разных типов...
4969. Классы структур данных 39.21 KB
  Классы структур данных Классификация структур данных Структура данных – совокупность взаимосвязанных программных объектов. К стандартным структурам данным относятся: - массивы указателей - однонаправленные списки - двунаправленные списки - д...
4970. Сравнение однонаправленного и двунаправленного списка 65.03 KB
  Списки Список – линейная структура, каждый элемент которой содержит адрес соседних элементов. Различают однонаправленные и двунаправленные списки. В однонаправленном списке каждый элемент содержит адрес следующего элемента. В двунаправленном сп...