Технологія розробки програм

Програми C++Builder можна, звичайно, розробляти в будь-якій послідовності. Компонентів у C++Builder безліч, функції багатьох їх зрозумілі. Тож чи варто мудрувати: переноси компоненти на форму, пиши обробники їх подій і отримуй нагороду за чудово зроблену програму.
У даному інтернет-підручнику CuBook.pro, наведені приклади так і будувалися. Це були тестові програми, єдиним завданням яких було показати можливості різних компонентів.

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

Тому, щоб уникнути надалі зайвої роботи та нарікань на вашу адресу з боку колег, яким випало нещастя модернізувати вашу програму, краще відразу привчити себе дотримуватися певної технології розробки. Благо, у C++Builder є для цього всі можливості. Йдеться насамперед про проктування на основі списків дій, керованих спеціальними компонентами.

Свого часу об’єктна орієнтація справила революцію у програмуванні і зараз вже важко уявити іншу побудову програми. Але захоплення об’єктами якось відсунула тимчасово другого план функції, тобто. ті події, які були основою попереднього етапу у програмуванні. Наразі інтерес до дій знову повертається. Адже дії це те, заради чого програма створюється. І об’єкти цікавлять лише доти, оскільки вони можуть полегшити дії користувача.

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

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

Щоб уникнути подібних складнощів, C++Builder передбачені компоненти, що здійснюють централізоване управління діями, їх диспетчеризацію. Складений список дій ви заносите в спеціальний компонент «диспетчер». Для кожної дії при цьому ви можете встановити безліч властивостей: написи на відповідних елементах управління, піктограми, тексти ярликів підказок, «гарячі» клавіші та багато іншого. Ви також можете написати обробник, який забезпечує виконання задуманої дії. Розробники C++Builder створили багато класів таких стандартних дій, у яких необхідні функції реалізуються автоматично. Отже, не ознайомившись у деталях із цими можливостями, ви ризикуєте «винайти велосипед». Ви витратите час і сили на їхню реалізацію, а потім виявиться, що те саме можна було зробити кількома рухами миші, причому набагато краще, ніж ви це придумали самі.

Якщо ви сформували такий перелік дій, то подальше проектування керуючих елементів значно спрощується. У більшості елементів є властивість Action. Досить послатися у цій властивості однією з процесів, як і всі властивості цієї дії і обробник, реалізує його, перенесуться у цей управляючий елемент. І вам не доведеться для кожного елемента задавати все це заново. Уявляєте, скільки часу ви заощадите? А якщо ви надалі щось зміните у реалізації дії або в її властивостях (наприклад, зміните «гарячі» клавіші або піктограму), то вам навіть не треба буде згадувати, які елементи в різних формах вашої програми ініціюють цю дію. Всі ці елементи автоматично сприймуть зміни.

У C++Builder передбачена подібна централізація управління програмою на кількох рівнях. Для диспетчеризації дій, починаючи з C++Builder 4, є компонент ActionList. Він спростив створення меню та інструментальних панелей, дозволив робити програми більш зрозумілі та структуровані. Вже C++Builder 5 число стандартних дій, яких можна звертатися з ActionList, було понад двадцять. На C++Builder 6 їх кількість різко зросла і перевищила 60.

Уявляєте скільки стандартних операцій реалізували за вас творці C++Builder?

Крім того, у C++Builder 6 з’явилася група набагато потужніших компонентів, призначених для управління подіями: ActionManager, ActionMainMenuBar, ActionToolBar, CustomizeDlg. Вони не тільки забезпечують нові можливості візуального проектування, але й вирішують, наприклад, таке завдання, як налаштування меню та інструментальних панелей користувачем. Правда, треба зазначити, що ActionList можна використовувати в крос-платформних додатках CLX, а ActionManager тільки в додатках Windows.

Поки що ми розглядали лише диспетчеризацію дій. Але централізація управління програмою має ще кілька рівнів. По-перше, треба згадати список зображень ImageList, який може централізовано постачати зображення та піктограми різні елементи програми. По-друге, C++Builder є такий об’єкт, як Application (додаток). Цей об’єкт керує найбільш спільними властивостями вашого проекту. А для перехоплення багатьох подій компонента Application є компонент ApplicationEvents, який дозволяє здійснити диспетчеризацію повідомлень про події. Нарешті, у кожному додатку є об’єкт Screen (екран), що дозволяє керувати відображенням різних форм моніторі.

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

Перелічені приклади належали до стандартних дій. Насправді таких дій набагато більше, ніж вище. Усі стандартні дії реалізовані C++Builder класами, успадковуючи базовому класу дій TAction. Обробники подібних дій у ряді випадків вам писати взагалі не треба, тому що вони реалізовані у відповідних класах.

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

Таким чином, як уже говорилося, перш ніж починати програмування програми, вам потрібно скласти для себе список дій, які повинні бути доступні майбутньому користувачеві через розділи меню, панелі інструментів, кнопки та інші елементи управління. Під час програмування цей список реалізується спеціальними компонентами, які забезпечують диспетчеризацію дій. У C++Builder 4 і 5 був лише один такий диспетчер дій компонент ActionList. Редактор цього компонента дозволяв сформувати список дій, написати обробники, які виконують задумані дії, вказати основні властивості майбутніх інтерфейсних компонентів піктограми, написи, швидкі кнопки, тексти підказок тощо. У C++Builder 6 з’явився ще один диспетчер дій компонент ActionManager, який набагато потужніший за ActionList.

Після того, як список дій створено, треба сформувати смуги дій. Це компоненти, у яких розташовуються інтерфейсні компоненти дій. Такими смугами дій є смуга головного меню та інструментальні панелі. При використанні ActionList, ці смуги дій треба додавати на форму у вигляді окремих компонентів, створювати на них ініціатори дій (розділи меню, швидкі кнопки), а потім зв’язувати ініціатори з відповідними діями зі списку ActionList. При такому зв’язуванні властивості, що закладені в дії, автоматично передаються інтерфейсним компонентам. У АсtionManager створення смуг дій спрощується. Вони створюються та формуються безпосередньо з редактора ActionManager простим перетягуванням мишею.

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

Таким чином, послідовність формування списку дій та проектування меню та інструментальних панелей зводиться до наступних кроків:

  1. Продумується та складається список дій, які мають бути доступні майбутньому користувачеві через розділи меню, інструментальні панелі, кнопки та інші елементи керування.
  2. Для тих нестандартних дій, які мають бути доступними зі швидких кнопок інструментальної панелі, готується список піктограм на кнопках у компоненті ImageList.
  3. На головну форму програми переноситься компонент диспетчеризації дій: ActionList або ActionManager. Компонент зв’язується із ImageList. Формується список стандартних та нестандартних дій.
  4. Кожній дії задається набір характеристик: Name (ім’я), Caption (напис, в якому виділяється символ швидкого доступу), Shortcut (гарячі клавіші), Imagelndex (номер зображення в ImageList), Hint (тексти підказок), HelpContext або HelpKeyword (посилання) на тему довідки) та ін Для нестандартних дій всі ці характеристики ви записуєте самі. Для стандартних дій вони заносяться автоматично. Вам треба тільки перекласти написи і підказки на російську мову і, можливо, виправити посилання на стандартні зображення, що не влаштовують вас, і комбінації гарячих клавіш. А якщо у вас передбачена у додатку контекстна довідка, то треба задати посилання на відповідні теми. Втім, на початку проектування довідки, звісно, ще немає. Отже, властивості HelpContext і HelpKeyword ви можете задати пізніше.
  5. Записуються обробники подій виконання всім нестандартних дій. Стандартні дії обробляються автоматично і для багатьох досить задати деякі властивості обробки. Втім, як видно пізніше, іноді треба писати обробники і для стандартних дій. Подальші кроки залежать від того, чи ви використовуєте компонент ActionList,
    або ActionManager. Для ActionList далі треба зробити таке:
  6. На форму переноситься компонент MainMenu (головне меню), зв’язується з ImageList, у компоненті формується меню і в його розділах даються посилання на дії, описані в ActionList.
  7. На формі створюється інструментальна панель (зазвичай компонент ToolBar). Панель зв’язується з ImageList, а її кнопках даються посилання дії, описані в ActionList.

Якщо ви використовуєте компонент ActionManager, ці кроки виглядають інакше:

  1. На форму переноситься компонент ActionMainMenuBar (смуга головного меню). Вона пов’язується з диспетчером ActionManager. Потім з редактора ActionManager перетягуються мишею на смугу меню категорії розділів, які мають входити до меню як головні розділи, або окремі дії.
  2. У редакторі ActionManager створюється нова інструментальна панель або кілька панелей. Там перетягуються мишею необхідні дії. Ось загалом послідовність операцій при проектуванні списку дій, меню та інструментальних пакселів.

    Залишити відповідь

    Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *