69283

Обробники подій. Концепція документ/представлення

Лекция

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

Як відомо, операційна система Windows використовує модель, керовану подіями (event-driven). Це означає, що замість послідовного набору команд додаток містить цикл повідомлень (message loop), який обробляє повідомлення (або події), передавані додатку операційною системою Windows.

Украинкский

2014-10-02

82 KB

0 чел.

Лекція № 3

Тема: Обробники подій. Концепція документ/представлення

План

  1.  Використання обробників подій
  2.  Концепція документ/предсталення

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

Як відомо, операційна система Windows використовує модель, керовану подіями (event-driven). Це означає, що замість послідовного набору команд додаток містить цикл повідомлень (message loop), який обробляє повідомлення (або події), передавані додатку операційною системою Windows. Як тільки повідомлення отримане, цикл повідомлень бере на себе всю відповідальність за його обробку (зазвичай для цього застосовується обробник повідомлення (message handler) або функція, спеціально написана для обробки конкретного повідомлення). Цикл повідомлень виконується впродовж всього періоду роботи додатку. Виконання циклу завершується під час вступу повідомлення WM_QUIT. Але де ж цей цикл в демонстраційному застосуванні? Якщо "копати" бібліотеку MFC достатньо глибоко, то він виявиться у функції
CWnd: :RunModalLoop, розташованою у файлі thrdcore. cpp. Цей цикл - великий фрагмент складної коди. Не варто турбуватися, якщо він поки не до кінця зрозумілий. На даному етапі розглянемо лише наступне основні моменти.

• За операторами ініціалізації слідує нескінченний цикл for (;;), призначений для обробки повідомлень.

• Усередині цього циклу for розташований цикл while, який спочатку визначає, чи не можна виконати цю роботу в режимі очікування (idle). Як відомо, додатки MFC перехоплюють повідомлення постійно (у фоновому режимі) навіть тоді, коли здавалося б додаток не робить нічого. Таким чином, цикл while перевіряє спочатку стан прапора bldle і з'ясовує, чи достатньо часу, щоб виконати цю частину роботи у фоновому режимі. Для підтвердження того, що додаток не завершив роботу, здійснюється виклик функції PeekMessage, яка повертає значення 0, якщо в черзі немає ніяких повідомлень. Отже, якщо прапор bldle встановлений в стан 1 і в черзі є повідомлення, то виконується код, що посилає окну повідомлення про те, що воно здатне виконати обробку у фоновому режимі.

• Наступний цикл (do) фактично обробляє повідомлення. Це і є цикл повідомлень (message loop), який іноді називають конвеєром повідомлень (message pump), саме він і здійснює в додатку фактичну обробку повідомлень. Звернете увагу, після звернення до функції ContinueModal (що дозволяє упевнитися в тому, що модальний стан повинен бути збережене) код перевіряє наявність в черзі повідомлення WM_QUIT (в цьому випадку функція AfxPurapMessage повертає значення 0). Якщо це так, то здійснюється вихід з функції і завершення роботи додатку. Інакше цикл продовжує отримувати і пересилати повідомлення.

Не дивлячись на те, що це достатньо поверхневий опис процесу обробки повідомлень в додатку MFC, воно зачіпає таку фундаментальну концепцію MFC, як передача повідомлень, що забезпечує прийом повідомлень, посланих додатку з операційної системи Windows, і їх розподіл між обробниками повідомлень. Але як перехопити певне повідомлення? Реалізовуючи обробник події для кнопки ОК, розташованої в діалоговому вікні, розробник фактично організовує перехоплення відповідного повідомлення, хоч це і не цілком очевидно. Для цього в карті повідомлень (message map) створюється запис про те, що повідомлення кнопки BN_CLICKED необхідно передавати на обробку призначеної для користувача функції OnBnClickedOk. Щоб проглянути карту повідомлень, відкрийте файл HelloDialogDlg.cpp і відшукайте рядок, що починається словами BEGIN MESSAGE_MAP. Там розташований наступний код:

BEGIN_MESSAGE_MAP(CAboutDlg, CDialog)

ON_BN_CLICKED(IDOK, OnBnClickedOk)

END MESSAGE MAP()

Для успішної роботи з бібліотекою MFC достатньо знати, що існують карти повідомлень, що зв'язують повідомлення і функції, а також різноманітні майстри, які дозволяють створювати ці функції. Докладніша інформація про внутрішню організацію і функціонування таких макросів бібліотеки MFC, як BEGINMESSAGEMAP, приведена в книзі Худоби Вінго (Scot Wingo) MFC Internals.

Тепер розглянемо створення обробника повідомлення для події, що не відноситься до графічного інтерфейсу користувача (GUIGraphical User Interface). Створити обробник повідомлення BN_CLICKED для кнопки ОК не так вже і складно: достатньо двічі клацнути в редакторові діалогового вікна на кнопці ОК. Але що робити з іншими повідомленнями, для доступу до яких редактор діалогового вікна не допоможе? Наприклад, якщо необхідно обробляти події переміщення або зміни розміру діалогового вікна? Нижче приведена послідовність дій, що дозволяє легко і просто створити обробник, який відобразить відповідне повідомлення, якщо користувач двічі клацне мишею в клієнтській області.

1. Відкрийте представлення Class View (Класи).

2. Знайдіть клас, що відповідає за те діалогове вікно, обробник повідомлень якого необхідно створити. В даному випадку це клас CHelloDialogDlg.

3. Клацніть правою кнопкою миші на імені класу і в контекстному меню, що з'явилося, виберіть пункт Properties (Властивості).

4. У діалоговому вікні Properties (Властивості) клацніть на піктограмі Messages (Повідомлення) (розташованою у верхній частині діалогового вікна). Вікно буде розділено на два стовпці. Перший з них містить список всіх повідомлень, для яких можна створити обробники, а другий — перелік імен всіх вже створених обробників.

5. Клацніть в полі праворуч від ідентифікатора повідомлення WM_LBUTTONDBLCLK. Поле ідентифікатора повідомлення виявиться виділеним, а в полі справа з'явиться кнопка із стрілкою. Вибираючи повідомлення в правому стовпці, звернете увагу на інформаційне поле в нижній частині діалогового вікна, що містить опис повідомлення поточного ідентифікатора. В даному випадку (мал. 1.21) про повідомлення з ідентифікатором WM_LBUTTONDBLCLK мовиться (внизу вікна), що воно "Означає подвійне клацання лівої кнопки миші". Хоча інформація про повідомлення не завжди настільки очевидна, як в даному випадку, вона виявиться вельми корисною при пошуку ідентифікатора, точне ім'я якого невідоме.

Клацання на кнопці із стрілкою розверне список дій, які можна виконати за допомогою обробника цієї події. Оскільки на справжній момент ніяких обробників для події не існує, єдиним пунктом списку буде <Add> OnLButtonDblClk (<Додати> OnLButtonDblClk).

7. Виберіть в списку цей пункт, і середовище розробки Visual Studio самостійно створить як функцию-член на ім'я CHelloDialogDlg: : OnLButtonDblClk, так і елемент карти повідомлень, переадресующий повідомлення WM_LBUTTONDBLCLK саме цій функції. От і все.

 

Мал. 1.21. Діалогове вікно Properties дозволяє легко додавати нові обробники повідомлень

8. Для перевірки працездатності обробника зміните функцию-член OnLButtonDblClkTaK, щоб вона виглядала таким чином:

void CHelloDialogDlg::OnLButtonDblClk(UINT nFlags, CPoint point) {

AfxMessageBox("Ouch! Don't touch me there!");

CDialog::OnLButtonDblClk(nFlags, point);

}

9. Відкомпілювавши і запустивши це застосування, можна переконатися, що у відповідь на подвійне клацання в клієнтській області головного діалогового вікна з'являється відповідне повідомлення.

Безумовно, обробник повідомлення можна відредагувати у будь-який момент. Досить відкрити файл, що містить його, і внести зміни до функції. Але як видалити обробник? Один із способів полягає у видаленні прототипу функції (function prototype) з файлу заголовка, видаленні визначення функції (function definition) з файлу реалізації . СРР і видаленні запису з карти повідомлень. Проте такий підхід складний і важкий. Найпростіше видалити обробник повідомлення за допомогою діалогового вікна Properties (Властивості). Перейшовши до поля повідомлення WM_LBUTTONDBLCLK і відкривши список можливих дій, можна відмітити, що тепер він містить два пункти — один для редагування функції, а другий для її видалення. Вибір пункту відповідного видаленню, приведе до повного автоматичного видалення обробника події зі всіх вищеперелічених місць.

Видаляючи обробники за допомогою діалогового вікна Properties, будьте дуже обережні. У попередніх версіях Visual Studio для видалення обробників застосовувався майстер ClassWizard, який не тільки запрошував підтвердження на видалення прототипу і запису в карті повідомлень, але і залишав текст коди, щоб його можна було згодом відновити у разі помилкового видалення.

Діалогове вікно Properties підтвердження при видаленні не запрошує і видаляє обробник події повністю.

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

В основі додатків MFC лежить концепція об'єкту документа (document object) і відповідного йому вікна представлення (view window). Зазвичай документом є окремий файл, який додаток здатний відкрити. Такий файл містить набір даних, що обробляються додатком. Представлення (вигляд) забезпечує візуальне відображення даних документа, а також взаємодія з користувачем. Представлення здатне відображати дані застосування частково, оскільки їх може опинитися значно більше, чим можна розмістити на екрані; крім того, можливе застосування декількох різних представлень одного документа. Іншими словами, відносини між документами і представленнями будуються за принципом "один до многим"— тобто один документ може мати безліч уявлень, але кожне представлення може бути асоційоване тільки з одним документом.

Документами додатків є об'єкти відповідних класів, похідних від загального базового класу бібліотеки MFC CDocument. Всі класи вікон представлення походять від класу MFC CView. У цьому розділі розглядаються як самі класи CDocument і CView, так і їх застосування в додатках з однодокументным інтерфейсом (SDISingle Document Interface). Складніші дії з документами і представленнями розглядаються в наступному розділі.

Застосування концепції документ/представлення

Всі створені за допомогою майстра AppWizard (майстри додатків) додатки MFC, що підтримують як одно-документный інтерфейс (SDI), так і багатодокументний інтерфейс (MDI— Multiple Document Interface), використовують архітектуру документ/представлення (document/view). Майстер AppWizard створює додаток так, щоб для кожного завантажуваного файлу в додатку створювався екземпляр відповідного класу документа. Крім того, в додатку обов'язково використовується екземпляр класу представлення, що надає користувачеві можливість взаємодіяти як з самим застосуванням, так і з даними документа.

У додатку з одним документом можна асоціювати декілька екземплярів певного представлення. Крім того, з одним і тим же документом може бути зв'язане декілька екземплярів різних уявлень.

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

Що володіє дружнім інтерфейсом додаток забезпечує зазвичай декілька різних представлень одних і тих же даних, а це дозволяє краще зрозуміти їх сенс. Наприклад, на підставі табличних даних про температуру атмосфери на всій території США ймовірно буде досить важко зміркувати, наскільки холодно буде в штаті Південна Дакота. Але одного погляду на публіковану в газетах карту погоди, де синім кольором позначають холодний фронт, а оранжевим — теплий, цілком достатньо, щоб скласти представлення про те, яка погода може чекати мандрівника в цих краях. І це не дивлячись на те, що табличні дані містять ту ж інформацію. По-перше, представлення даних у вигляді таблиці дуже зручно для введення значень, а по-друге — це єдиний спосіб з'ясовувати погоду в штаті Південна Дакота для тих, хто не дуже добре знає, де саме вона знаходиться. Таблиця і кольорова карта — це два разных представлення, і додаток MDI може використовувати обидва (а можливо і ще декілька) для відображення одних і тих же даних.

Додатки з однодокументным інтерфейсом, створені за допомогою майстра AppWizard, здатні використовувати тільки один документ, один тип представлення і лише по одному екземпляру кожного з цих класів. Але це справедливо тільки для коди, створеної майстром AppWizard. Після того, як він закінчить роботу із створення додатку, розробник вольний на свій розсуд змінити конфігурацію проекту і, за бажання, скористатися декількома екземплярами будь-якого представлення або документа.

Додатки MDI використовують, принаймні, одну пару документ/представлення, але при необхідності можуть використовувати і декілька документів з різними представленнями в різних комбінаціях, що дозволяє користувачеві одночасно працювати з декількома файлами, а також відображати ці дані різними способами. Докладніша інформація про додатки MDI приведена в розділі 3, "Додатки MDI". На мал. 2.1 представлена схема взаємодії класів, використовуваних при реалізації простого додатку SDI із застосуванням класів MFC.

Ці класи послідовно розглядаються впродовж даного розділу. Наприклад, фреймові вікна (представлені на мал. 2.1 базовим класом CFrameWnd), детальніше розглядаються в розділі "Декілька слів про фреймові вікна". Проте, щоб легко зрозуміти деякі теми, викладені у ряді наступних розділів, з фреймовими вікнами має сенс ознайомитися зараз.

Фреймовим вікном (frame window) називають вікно, що містить представлення документа. Представлення (view) несе відповідальність за відображення на екрані вмісту документа, який користувач бачить фактично, а фреймом є батьківський (parent) елемент даного представлення. На справжній момент необхідно зрозуміти, що фрейм — це вікно, яке може володіти різними меню, панелями інструментів, рядком стану і заголовком вікна (а також, але необов'язково, системним меню і кнопками свернуть/развернуть). При зміні розміру вікна додатку SDI користувач фактично перетягує межу фрейма, а батьківському вікну передається відповідне повідомлення. Вікно представлення, оскільки воно є дочерним (child) вікном фрейма, також отримує ці повідомлення і змінює свої розміри відповідно до них.

У додатках SDI, створених майстром AppWizard, фреймові вікна реалізують за допомогою класу CMainFrame. Його початковий код міститься у файлах MainFrm. h і MainFrm. срр.

Мал. 2.1. Модель відносин між п'ятьма базовими класами додатку SDI

І нарешті, звернете увагу, що клас CMainFrame успадковує практично всі свої функціональні можливості від базового класу CFrameWnd, а у разі додатків SDI різниця між їх можливостями неістотна. Виняток становить можливість застосування і маніпулювання такими специфічними для дочірніх фреймових вікон елементами, як панелі інструментів і рядка стану. Взаємовідношення між рядками стану, панелями інструментів і фреймовими вікнами описані в розділі 6, "Рядок стану і панель інструментів".


 

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

47519. Методические указания. Безопасность жизнедеятельности 208 KB
  Рост энерговооруженности производства внедрение новых форм организации и стимулирования труда требует подготовки квалифицированных специалистов обладающих глубокими знаниями в области безопасности труда. Только квалифицированные специалисты способны реализовать основные направления государственной политики в области охраны труда направленные на улучшение условий труда снижение травматизма и профессиональных заболеваний повышение производительности труда. Такие специалисты должны иметь потребность к разработке и безусловному выполнению...
47521. ГРОШІ ТА КРЕДИТ 162 KB
  Сутність та функції грошей СУТНІСТЬ ТА ФУНКЦІЇ ГРОШЕЙ Походження та сутність грошей. Форми грошей та їх еволюція. Формування цінності неповноцінних грошей.
47523. Бухгалтерский учет, анализ и аудит. Методические рекомендации 333 KB
  Рекомендуемая тематика и планы дипломных работ по бухгалтерскому учету аудиту и экономическому анализу Цель и задачи дипломной работы Подготовка и защита дипломной работы является завершающим этапом учебного процесса по подготовке специалистов высокой квалификации в области бухгалтерского учета экономического анализа и аудита. Задачами дипломной работы являются: Систематизация расширение и закрепление полученных теоретических знаний и практических навыков по бухгалтерскому учету экономическому анализу и аудиту; Овладение методикой...
47524. Дипломные работы. Методика проведения и оформления 791.5 KB
  Учебное пособие знакомит студентов с требованиями, которые предъявляются к дипломной работе на всех этапах ее создания. Учебное пособие поможет правильно выбрать и сформулировать тему исследования, подобрать литературу, написать текст, оформить его, успешно защитить свою работу. В пособии содержится большое количество примеров, иллюстрирующих наиболее важные аспекты создания научного произведения.
47525. Методические указания. Информационные системы и технологии 156 KB
  Акмуллы Институт профессионального образования и информационных технологий МЕТОДИЧЕСКИЕ УКАЗАНИЯ ПО ВЫПОЛНЕНИЮ И ОФОРМЛЕНИЮ КВАЛИФИКАЦИОННОЙ ДИПЛОМНОЙ РАБОТЫ Специальность 230201 Информационные системы и технологии Уфа 2012 Методические указания по выполнению и оформлению квалификационной дипломной работы предназначенной для студентов дневной обучения по специальности 230201 Информационные системы и технологии. Организация написания дипломной работы 1. Структура дипломной работы и правила...