3.6.2. Операції створення нових об'єктів

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

Команда Копіювати (Сміттю)

Одержання копії існуючого об'єкта є основним способом створення нових об'єктів. Об'єкти-копії можуть модифікуватися і звичайно исполь-

80

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

Команда Створити (New)

Команда Створити (New) полегшує створення нових об'єктів. Вона забезпечує автоматичне створення нового екземпляра об'єкта визначеного типу і може розглядатися як комбінація команд Копіювати (Сміттю) і Вставити (Paste).

Команда Помістити (Іnsert)

Команда Помістити (Іnsert) працює аналогічно команді Створити (New), за винятком того, що вона застосовується до контейнера для створення нового об'єкта (звичайно визначеного типу) усередині цього контейнера. Використовуючи різні формати команди Помістити, можна надати користувачу можливість включати в контейнер об'єкти різних типів. Якщо створюваний додаток підтримує технологію OLE, за допомогою команди Помістити може бути реалізоване створення широкого класу об'єктів. Крім того, об'єкти, підтримувані вашим додатком, можуть включатися у файли даних, створені іншими додатками OLE.

Використання елементів керування

З метою автоматичного створення нових об'єктів можуть використовуватися елементи керування. Наприклад, у графічних додатках часто використовуються кнопки, що відповідають різним інструментальним чи засобам способам створення нових об'єктів, таких як лінія визначень чи форми геометрична фігура. Кнопки можуть також використовуватися для впровадження об'єктів за технологією OLE.

Використання шаблонів

Шаблон є спеціальним об'єктом, що автоматизує створення нового об'єкта. Щоб користувачу було зрозуміле його призначення, піктограма шаблона повинна містити невеликий малюнок, що відбиває тип створюваних з його допомогою об'єктів, як показано на мал. 3.17.

Рис. 3.17. Приклад піктограми шаблона

Як визначену операцію для об'єкта Шаблон використовується команда Створити; вона ініціює процес створення об'єкта, що може виконуватися

81

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

3.6.3. ОЦЕРАЦИИ ЗВ'ЯЗУВАННЯ ОБ'ЄКТІВ

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

Зв'язок між об'єктами може бути представлена різними засобами інтерфейсу. Зокрема , зв'язок за даними реалізується за допомогою передачі відповідних величин між двома об'єктами, наприклад, між двома осередками в чи таблиці між стовпцем таблиці і діаграмою. Переходи (називані також гіперпосиланнями - hyperlіnks) надають навігаційний доступ до іншого об'єкту. Цей вид зв'язку можна назвати також зв'язком по г/правлінню.

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

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

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

82

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

Як додатковий засіб настроювання інтерфейсу користувачу може бути надана можливість вибору використовуваного маршруту (абсолютного чи відносного) для зв'язаного об'єкта. Такий вибір може виконуватися за допомогою відповідного елемента керування на панелі властивостей зв'язаного об'єкта.

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

Спосіб активізації зв'язаного об'єкта залежить від типу зв'язку. Наприклад, активізація переходу може виконуватися за допомогою однократного щиглика ЛКМ. Проте , такий механізм ефективний тільки для вибору зв'язаних чи даних зв'язаного об'єкта OLE. Якщо ж він використовується, щоб зробити щось ще, крім вибору об'єкта, варто використовувати різні форми візуального представлення для кожної з припустимих операцій. Наприклад, якщо перехід виконується за допомогою кнопки-акселератора, то при виборі кнопки змінюється форма покажчика (він відображається у виді руки, як показано на мал. 3.18), а коли користувач клацає на ній ЛКМ, то змінюється зображення кнопки і виробляється перехід по посиланню.

Рис. 3.18. Ідентифікація виконуваної операції за допомогою зміни форми покажчика

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

83

Розділ 4

-, ..

ВІКНА І ПІКТОГРАМИ

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

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

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

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

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

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