Передмова
Найбільш поширеним мовою програмування останнього десятиліття безумовно є С. Цьому сприяли такі його особливості, як лаконічність, потужність, гнучкість, мобільність. Разом з тим, стрімке ускладнення програм, для реалізації яких застосовуються традиційні процедурно-оріентірованнние мови програмування і, зокрема С, змушують говорити про певну кризу в їх використанні, пов'язаному насамперед з недостатньою надійністю і виразною здатністю.
Подібних недоліків багато в чому позбавлені мови об'єктно-оріентірованнго програмування (ООП), в сонове которихлежіт ідея моделювання об'єктів за допомогою ієрархічно пов'язаних класів.
Окремо взятий клас розглядається як Сукупність безлічі даних та операцій над ними, причому доступ до елементів даних класу можливий тільки за допомогою операцій цього класу. Встановлення чіткої взаємозалежності між даними та операціями веде до великої цілісності даних і значно підвищує надійність програм в порівнянні з традиційними мовами програмування. Крім того, ідея програмування за допомогою класів багато в чому використовує той самий підхід, який дозволяє людям формувати моделі об'єктів реального світу.
Вперше ідеї ООП були реалізовані в середині 60-х років у мові програмування Симула-67. Останній, однак, не знайшов у той час широкого розповсюдження як у силу своєї відносно меншою продуктивності в порівнянні з традиційними мовами типу FORTRAN, ALGOL, PL / 1 так і, можливо, неадекватності пропонованих засобів вирішуються в той час завдання. Ще одним важливим обмеженням для распространеие Симула-67 стали труднощі, з якими довелося зіткнутися більшості програмістів при його вивченні. Справа в тому, що поряд з цілим рядом безумовних достоїнств, ідеї ООП володіють і одним істотним недоліком - вони далеко не прості для розуміння і особливо для освоєння з метою практичного використання.
С + + - це об'єктно-оріентірованиий мова, тобто мова, що дозволяє програмістові оперувати об'єктами деяких типів, попередньо їм визначеним. Назва мови "С + +" відображає еволюційний характер зміни мови С (запис "++", в мові С, означає, що до якоїсь змінної додається одиниця). Він має ще більш потужні та гнучкі засоби для написання ефективних програм, ніж С, від якого він відбувся. Людина, программмірующій на традиційних мовах, може просто втратити голову від тих можливостей, які надає С + +.
Але не менш важливим є те, що такий поширений і універсальна мова, як С, збережений в якості основи. З простий, ефективний, переносимо. Чого тільки немає в мові С: строкових даних немає, матриць немає, засобів паралельного програмування теж немає. Немає навіть введення-виведення.
Типи, операції і оператори З дуже близькі до того, з чим ми маємо справу в Асемблері, - числа, адреси, арифметичні і логічні дії, цикли ... Крім того, багато особливостей З недвозначно натякаю компілятору, як скоротити код і час виконання програми. Ці характерні риси мови С дозволяють написати ефективно працює і не надто складний компілятор. І хоча в машинних кодах на різних комп'ютерах елементарні операції обозначаютс по-різному, навряд чи розробнику компілятора прийде в голову інтерпретувати найпростіші вирази яким-небудь оригінальним способом. Саме тому мова С "йде скрізь і на всьому", програми, написані на ньому, працюють ефективно, і їх можна переносити з одного комп'ютера на інший.
MS Windows і новий метод розробки програм.
Одним з найбільш важливих механізмів взаємодії програм є обмін даними. У MS Windows існує декілька способів взаємодії додатків:
- Поштова скринька;
- Динамічний обмін даними;
- Вбудовування об'єктів.
Спеціальний поштовий ящик (clipboard) Windows дозволяє користувачеві переносити інформацію з одного додатка в інше, не піклуючись про її форматах та поданні.
На відміну від професійних операціональних операційних систем, де механізм обміну даними між програмами доступний тільки програмісту, в Windows це робиться дуже просто і наочно для користувача.
Механізм обміну даних між додатками - життєво важлива властивість багатозадачного середовища. І в даний час виробники програмного забезпечення прийшли вже до висновку, що для перенесення даних з однієї програми до іншої поштової скриньки вже недостатньо. З'явився новий, більш універсальний механізм - OLE (Object Linking and Embedding)
- Вбудована об'єктна зв'язок, який дозволяє переносити з одного додатка в інше різнорідні дані. Наприклад, за допомогою цього механізму дані, підготовлені в системі Time Line for Windows (Symantec), можна переносити в текстовий процесор Just Write (Symantec), а потім, скажімо, в генератор додатків Object Vision (Borland). Правда, це вже нестандартне засіб Microsoft Windows, але тим не менш реалізація OLE стала можливою саме в Windows.
Крім механізму поштової скриньки, призначеного, в основному, для користувача, програмісту в Windows доступні спеціальні засоби обміну даними між додатками.
Програмним шляхом можна встановити прямий зв'язок між завданнями, наприклад, приймаючи дані з послідовного порту, автоматично поміщати їх, скажімо, в комірки електронної таблиці Excel, засобами якої можна відразу відображати складні залежності у вигляді графіків або здійснювати їх обробку в реальному режимі часу (цей механізм називається динамічного обміну даними - Dynamic Data Exchange, DDE).
Основні терміни
Клієнтський додаток DDE - додаток, якому необхідно встановити діалог з сервером і отримати дані від сервера в процесі діалогу.
DDE-діалог - взаємозв'язок між клієнтським і серверним додатками.
Сервер-додаток - DDE додаток, що передає дані клієнтові в процесі діалогу.
DDE-Транзакція-обмін повідомленнями або даними між клієнтом і сервером.
Item ім'я - рядок, що ідентифікує деяке безліч даних, що сервер в змозі передати клієнтові в процесі діалогу.
Service ім'я - рядок, що генерується сервером і використовувана клієнтом для встановлення діалогу.
Строковий покажчик - подвійне слово, що генерується операційною системою, ідентифікує рядок, що передається в процесі динамічного обміну даними.
Topic ім'я - рядок, що ідентифікує тип даних, необхідних клієнтському застосуванню при динамічному обміні даних.
Фільтр транзакції - прапор, який перешкоджає передачі небажаних типів транзакцій у функцію зворотного виклику.
У Microsoft Windows динамічний обмін даних є формою зв'язку, яка використовує спільні області пам'яті для обміну даними між додатками. Програма може використовувати DDE в деякий момент часу для передачі і отримання нових даних від сервера.
Механізм DDE схожий з механізмом поштової скриньки, який є частиною операційної системи WINDOWS. Існує лише незначна різниця в тому, що поштова скринька, в більшості випадків, використовується як буфер тимчасового зберігання інформації. DDE може бути инициализирован користувачем і в більшості випадків
продовжувати працювати без його втручання.
Бібліотека DDEML забезпечує користувача набором засобів, які спрощують використання механізму DDE в WINDOWS додатках. Замість того, щоб обробляти, одержувати і передавати DDE повідомлення прямо, додатки використовують функції DDEML бібліотеки. Бібліотека DDEML також забезпечує роботу з рядками і розділяються даними, що генеруються DDE додатками. Замість того, щоб використовувати покажчики на загальні області пам'яті, DDE програми створюють і обмінюються строковими покажчиками, які ідентифікують рядки і дані.
Вже існуючі програми, що використовують протокол DDE, заснований на повідомленнях повністю сумісні з тими, які використовують бібліотеку DDEML. Ось чому додаток, що використовує DDE-протокол можуть встановити діалог і виконувати транзакції з додатками, що використовують бібліотеку DDEML.
Взаємозв'язок між клієнтом і сервером.
DDE виникає завжди між клієнтським додатком і серверним. Клієнтський додаток ініціалізує обмін даними шляхом встановлення діалогу з сервером і передачі транзакції. Транзакція необхідна для даних і обслуговування. Сервер відповідає на транзакцію, і забезпечує клієнта даними. Сервер може мати відразу декілька клієнтів в один і той же час, у свою чергу, клієнт може отримувати дані відразу від декількох серверів. Деякий додаток одночасно може бути клієнтом і сервером. На додаток до вищесказаного, клієнт і сервер можуть обірвати діалог у будь-який зручний для них час.
DDE сервер використовує три зарезервованих типу імен, розташованих ієрархічно: service, topic item - унікально ідентифікують деякий безліч даних, що сервер може передати клієнтові в процесі діалогу.
Service ім'я - це рядок, який генерує сервер в ті проміжки часу, в які клієнт може встановити діалог з сервером.
Topic ім'я - це рядок, який ідентифікує логічний контекст даних. Для сервера, який маніпулює файлами, topic імена це просто назви файлів; для інших серверів - це специфічні імена конкретного застосування. Клієнт обов'язково повинен вказувати topic ім'я разом з service ім'ям, коли він хоче встановити діалог з сервером.
Item ім'я - це рядок, який ідентифікує деяке безліч даних, що сервер може передати клієнтові в процесі транзакції. Наприклад, item ім'я може ідентифікувати ЦІЛЕ (int, integer), РЯДОК (string, char *), кілька параграфів тексту, або BITMAP образ.
Всі вищевказані імена дозволяють клієнту встановити діалог з сервером і отримати від нього дані.
Системний режим
Системний режим роботи забезпечує клієнта всією необхідною інформацією про сервер.
Для того, щоб визначити, які сервери доступні в даний момент часу, а також якою інформацією вони можуть забезпечити клієнта, останній, перебуваючи в початковому режимі роботи, повинен встановити ім'я пристрою, рівне NULL. Такий шаблон діалогу максимально збільшує ефективність роботи, а також роботу з сервером в системному режимі. Сервер, у свою чергу, повинен підтримувати нижчеописані item імена, а також інші, часто використовуються клієнтом:
SZDDESYS ITEM TOPICS - список item імен, з якими може працювати сервер в даний момент часу. Цей список може змінюватися час від часу.
SZDDESYS ITEM SYSITEMS - список item імен, з якими може працювати сервер в системному режимі.
SZDDDESYS ITEM STATUS - запитати поточний статус сервера. Зазвичай, даний запит підтримується тільки у форматі CF_TEXT і містить рядок типу Готовий / Зайнятий.
SZDDE ITEM ITEMLIST - список item імен, підтримуваних сервером у несистемності режимі роботи. Цей список може змінюватися час від часу.
SZDDESYS ITEM FORMATS - список рядків, що представляє собою список всіх форматів поштової скриньки, підтримуваних сервером в даному діалозі. Наприклад, CF_TEXT формат представлений рядком TEXT.
Основне призначення та робота функції зворотного виклику
Додаток, який використовує DDEML, повинно містити функцію зворотного виклику, яка обробляє події, отримані додатком. DDEML повідомляє додаток про такі події шляхом посилки транзакцій у функцію зворотного виклику даного додатка.
У залежності від прапора фільтра транзакції, сформованого при виконанні функції DdeInitialize, функція зворотного виклику отримує відсортовані транзакції незалежно від того, чи є дане додаток клієнтом, сервером або тим і іншим одночасно.
Параметр uType ідентифікує тип надісланій транзакції у функцію зворотного виклику за допомогою DDEML. Значення решти параметрів залежать від типів транзакції. Типи транзакцій будуть обговорені нами в розділі "Обробка Транзакцій".
Діалог між додатками
Діалог між клієнтом і сервером завжди встановлюється на вимогу клієнта. Коли діалог встановлено, обидва партнери отримують ідентифікатор, який описує даний діалог.
Партнери використовують цей ідентифікатор в більшості функцій DDEML для посилки транзакцій і для їх обробки. Клієнту може знадобитися діалог як з одним сервером, так і з кількома.
Розглянемо докладно як додаток встановлює діалог і отримує інформацію про вже існуючих каналах зв'язку.
Простий Діалог
Клієнтський додаток встановлює простий діалог з сервером шляхом виклику функції DdeConnect і визначає ідентифікатори рядків, які містять всю необхідну інформацію про service імені поточного сервера і інтересущем клієнта в даний момент topic імені.
DDEML відповідає на виклик цієї функції посилкою відповідної транзакції XTYP_CONNECT у функцію зворотного виклику кожного доступного в даний момент часу сервера, зареєстроване ім'я якого збігається з ім'ям, переданим за допомогою функції DdeConnect за умови, що сервер не відключав фільтр service імені викликом функції DdeServiceName.
Сервер може також встановити фільтр на XTYP_CONNECT транзакцію завданням відповідного прапора CBF_FAIL_CONNECTIONS при виклику функції DdeInitialize.
У процесі обробки транзакції типу XTYP_CONNECT DDEML передає отримані від клієнта service і topic імена сервера. Сервер повинен перевірити ці імена і повернути TRUE, якщо він в змозі працювати з такими іменами, і FALSE в іншому випадку. Якщо жоден з існуючих серверів не відповідає на CONNECT-запит клієнта, функція DDeConnect повертає йому NULL з інформацією про те, що в даний момент часу НЕ можливо встановити діалог.
Однак, якщо сервер повернув TRUE, то діалог був успішно встановлений і клієнт отримує ідентифікатор діалогу - подвійне слово, за допомогою якого і ведеться обмін даними з сервером.
Потім сервер отримує транзакцію виду XTYP_CONNECT_CONFIRM (у разі, якщо він НЕ описував прапор фільтра CBF_FAIL_CONFIRMS при виклику відповідної функції).
Якщо сервер повертає TRUE у відповідь на транзакцію XTYP_CONNECT, DDEML посилає транзакцію виду XTYP_CONNECT_CONFIRM у функцію зворотного виклику даного сервера. Обробивши цю транзакцію, сервер може отримати ідендіфікатор діалогу.
Замість конкретного імені сервера клієнт може встановити шаблон діалогу шляхом установки ідентифікаторів service і topic імен в NULL при виконанні функції DdeConnect.
Якщо хоча б один з перерахованих вище ідентифікаторів дорівнює NULL, DDEML посилає транзакцію типу XTYP_WILDCONNECT у функцію зворотного виклику всіх активних в даний момент DDE-додатків (виключення становлять лише ті, хто при виклику відповідної функції вказав прапор фільтрації XTYP_WILDCONNECT).
Будь-яке сервер-додаток повинен відповісти на дану транзакцію, і повернути вказівник на масив структур типу HSZPAIR, що закінчується нулем.
Якщо сервер-додаток НЕ викликає функцію DDeNameService для реєстрації власного service імені в системі і фільтр обробки транзакцій включений, то сервер НЕ отримає транзакцію виду XTYP_WILDCONNECT.
Вищеописаний масив повинен містити одну структуру для кожного service і topic імен. DDEML вибирає одну пару з масиву для встановлення діалогу і повертає його ідентифікатор клієнта. Потім DDEML посилає серверу транзакцію виду XTYP_CONNECT_CONFIRM (виключення становлять лише ті сервери, які при ініціалізації встановили фільтр обробки транзакцій).
Будь-який сервер або клієнт може обірвати діалог у будь-який час шляхом виклику функції DdeDisconnect. Це означає, що партнер з обміну даними отримує транзакцію типу XTYP_DISCONNECT у функції зворотного виклику (якщо, звичайно, партнер не встановив фільтр обробки транзакцій виду CBF_SKIP_DISCONNECTIONS).
Зазвичай додаток реагує на транзакцію XTYP_DISCONNECT викликом функції DdeQueryInfo для отримання інформації про припинення діалогу. Після того, як функція зворотного виклику опрацювала транзакцію типу XTYP_DISCONNECT, ідентифікатор діалогу більше не існує.
Клієнтський додаток, яке отримує транзакцію типу XTYP_DISCONNECT у своїй функції зворотного виклику може спробувати відновити діалог за допомогою виклику функції DdeReconnect. Клієнтська програма може викликати цю функцію тільки перебуваючи всередині своєї власної функції зворотного виклику.
Складний діалог
Клієнтський додаток може використовувати функцію DdeConnectList для того, щоб визначити які сервер-додатки існують в системі в даний момент часу.
Клієнт обов'язково повинен описувати service і topic імена, коли він викликає цю функцію; це означає, що DDEML повинна послати транзакцію виду XTYP_CONNECT всі функції зворотного виклику всіх наявних в даний момент сервер-додатків, чиї зареєстровані імена збігаються з іменами, зазначеними клієнтом (виняток становлять лише ті сервери, які фільтрують одержувані транзакції).
На додаток до вищесказаного, можна зазначити, що клієнт, при виклику функції DdeConnectList, може вказати NULL як service або topic імені, або ж відразу для обох. Всі доступні в системі сервери, чиї зареєстровані імена збігаються з іменами, зазначеними клієнтом, відповідають на його запит. Діалог встановлюється з усіма такими серверами, навіть якщо в системі запущено одне і теж сервер-додаток кілька разів.
Клієнт може використовувати функції DdeQueryNextServer і DdeQueryConvInfo для того, щоб зрозуміти, який сервер знаходиться в списку, отриманий при виконанні функції DdeConnectList. DdeQueryNextServer повертає ідентифікатор діалогу для наступного сервера, який знаходиться у списку; DdeQueryConvInfo заповнює структуру CONVINFO інформацією про діалог.
Клієнт може зберегти отримані ідентифікатори діалогів і відмовитися від перегляду залишилися серверів у списку.
Додаток може обірвати індивідуальний діалог, що знаходиться в списку діалогів шляхом виклику функції DdeDisconnect; додаток може обірвати всі діалоги, які знаходяться в списку шляхом виклику функції DdeDisconnectList.
Обидві вищевказані функції вказують DDEML про необхідність посилки транзакції виду XTYP_DISCONNECT в усі функції партнерів по діалогу даного додатки (у разі використання функції DdeDisconnectList буде посилатися транзакція XTYP_DISCONNECT для кожного елемента в списку діалогів).
Обмін даними між додатками
Так як DDE використовує області пам'яті для передачі даних з однієї програми до іншої, DDEML забезпечує кінцевого програміста функціями, за допомогою яких DDE-додатки можуть створювати і обробляти DDE-об'єкти.
Весь спектр транзакцій, який викликає обмін даними, вимагає від програми, експортує їх, створення деякого буфера, що містить ці дані, а потім виклику функції DdeCreateDataHandle.
Ця функція створює DDE-об'єкт, копіює дані з буфера в цей об'єкт і повертає ідентифікатор даних для цього додатка.
Ідентифікатор даних-це подвійне слово, яке використовує DDEML для забезпечення доступу до даних в DDE-об'єкті.
Для того, щоб розділяти дані в DDE-об'єкті, додаток передає ідентифікатор даних DDEML, а потім DDEML передає його у функцію зворотного виклику програми, що одержує дані.
Клієнтський додаток отримує покажчик на DDE-об'єкт шляхом передачі ідентифікатора даних функції DdeAccessData. Покажчик, що повертається цією функцією, забезпечує доступ до даних у форматі 'ТІЛЬКИ НА ЧИТАННЯ'. Клієнт повинен переглянути отримані дані за допомогою цього покажчика і викликати функцію DdeUnaccessData для його знищення. Клієнт може скопіювати отримані дані в заздалегідь приготований буфер за допомогою виклику функції DdeGetData.
Зазвичай, коли програма, що створює ідентифікатор даних, передає його DDEML, цей ідентифікатор псується всередині вищевказаного додатки. У цьому немає нічого страшного, якщо сервер повинен розділяти дані тільки з одним клієнтом. Якщо ж сервер повинен розділяти дані відразу з декількома клієнтами одночасно, йому доведеться вказувати прапор HDATA_APPOWNED при виклику функції DdeCreateDataHandle.
Це робить можливим отримання прав власності на DDE-об'єкт сервер-додатки та запобігає псування ідентифікатора даних DDEML. Додаток може передавати DDEML ідентифікатор даних будь-яку кількість разів, однак викликати функцію DdeCreateDataHandle можна лише одного разу.
Якщо програма вказує прапор HDATA_APPOWNED в параметрі atCmd при виклику функції DdeCreateDataHandle, воно обов'язково повинно викликати функцію DdeFreeDataHandle для очищення пам'яті незалежно від того, передавався чи ідентифікатор даних DDEML чи ні. Перед тим як обірвати діалог, застосування повинне викликати функцію DdeFreeDataHandle для очищення всіх створених ідентифікаторів, але які так і не були передані DDEML.
Якщо додаток ще не передало ідентифікатор DDE-об'єкта DDEML, то воно може додати дані до вже існуючого об'єкту або повністю замінити їх у ньому. Всі ці сервісні функції обслуговуються функцією DdeAddData.
Зазвичай програма використовує цю функцію для нової ініціалізації старих не знищених DDE-об'єктів. Після того, як додаток передає ідентифікатор даних DDEML, DDE-об'єкт, що ідентифікує цей ідентифікатор НЕ може бути змінений, проте він може бути знищений.
OLE-технологія
Як видно з описаного вище протоколу DDE, додатки повинні обов'язково знати типи переданих даних, вміти їх обробляти, а в основному навіть можуть працювати тільки з символьними рядками. Це, звичайно, не дуже зручно, коли необхідно, наприклад, створити невеликий текст з різними картинками, піктограмами та іншими наочними або не дуже ілюстраціями. У цьому випадку на допомогу приходить програмісту OLE - вбудовування об'єктів.
Разом з даними ми отримуємо машинний код, який ці дані може обробляти.
Способи упорядкування, джерела та цільові документи
При використанні OLE-технології користувач завжди має справу з одним провідним додатком (головним) і одним відомим (підлеглим), а точніше, з одним відомим.
Додаток, за допомогою якого отримано об'єкт для вбудовування завжди відіграє роль підлеглого. Це особливо характерно для випадків передачі об'єктів при вбудовуванні і зв'язуванні через буфер проміжного обміну.
Часто використовувані терміни Додаток-джерело і Цільове додаток стосуються не підпорядкування додатків, а визначають генеалогію об'єктів.
Деякі Windows-програми можуть виступати тільки в ролі підлеглих, а деякі тільки в ролі ведучих. Наприклад, Paintbrush в OLE технології може грати тільки роль підлеглого програми, що служить для створення і модифікації окремих об'єктів. Інші програми, наприклад, Write або Cardfile можна вважати виправданим з точки зору, що набагато частіше доводиться вставляти ілюстрації в складні за структурою текст, ніж текст в ілюстрації. Нові додатки, такі як Word, можуть виконувати в рамках OLE обидві ці функції.
Вживання терміну об'єкт вважається престижним в кругах програмістів, хоча часто він вживається і не до місця. Кожен розробник почувається до боргом застосувати в своєму продукті ООП без особливої на те необхідності. У середовищі Windows в термін об'єкт вкладається дещо специфічний сенс. Користувача не запрошують осягати ази ООП, або зайнятися конструюванням об'єктів на С + +.
Коли про об'єкти говорять в рамках Windows, то мають на увазі можливість вбудовування в певний документ фрагмента, породженого іншою програмою. Ось це "чужорідне тіло" і називається об'єктом.
У такому підході немає нічого нового. Коли в текст, підготовлюваний Write, вставляється малюнок з Paintbrush допомогою Clipboard або таблиць Exсel, в документ, що готується в Word, то результатом дії буде як раз появи об'єкта.
Традиційні об'єкти завжди представляють собою копії. Робота з ними грунтується на тому, що всі Windows програми підтримують не тільки свій власний формат, але і певний узагальнений, стандартний, який грає роль загальновідомого міжнародної мови. Якщо, наприклад, в текстовий документ вставляється таблиця з табличного процесора, то буфер проміжного обміну перетворює її у формат до стандартного, і тим самим забезпечує вставку. Така копія в текстовому редакторі з вигляду не відрізняється від оригіналу, але вона недоступна для внесення змін. Неможливо, вставивши таким способом копію з Paintbrush в Write документ, змінити колір, товщину ліній або масштаб.
Нові об'єкти, доступні в рамках Windows 3.1 дуже схожі на традиційні, але вони не є копіями - це оригінали. Вони є в єдиному екземплярі і знаходяться непостредственно в цільових документах. Там вони існують одночасно в двох форматах - в стандартному і у форматі програми-джерела.
Завдяки стандартним форматом об'єкт може відтворюватись і зберігати в рамках цільового документа. Є можливість обробки об'єкта також, як і будь-якого файлу оригіналу. Ситуація виглядає так, ніби усередині об'єкта вбудований інший. Це забезпечує доступ до засобів обробки нового об'єкта (додатку-джерела) за допомогою простого подвійного клацання на об'єкті.
Вбудовані об'єкти
Інформація, вставлена в документ цільового програми, являє собою об'єкт. Такий об'єкт вбудовується в документ, опрацьований провідним додатком. Це значить, що він розглядається як складова частина даного документа, може роздруковуватися і зберігатися разом з ним. Такі об'єкти можуть містити інформацію будь-якого типу: текст, таблиці, графіки та ін
Вбудовані об'єкти існують тільки в єдиному екземплярі і тільки там, де вони вбудовані - у цільовому документі. Обробляються вони своїми "батьківськими" програмами, що викликаються вельми ефективним способом, на відміну від традиційного.
Зв'язування з батьківським додатком
Наступною дуже зручною особливістю вбудованих об'єктів є те, що вони залишаються пов'язаними з породив їх додатками. Завдяки цьому користувач позбавляється від необхідності пам'ятати імена і директорії файлів-джерел. Досить подвійного клацання на об'єкті - і батьківська програма запускається.
Важливим достоїнством подібного зв'язування вбудованих об'єктів є мобільність документів. Можна легко перенести такий документ з однієї машини на іншу (необхідно тільки щоб на них обох була встановлена оболонка і були необхідні додатки або динамічні бібліотеки від них). Для обробки вбудованих об'єктів досить буде клацнути по ній двічі і на іншій машині відбудеться теж саме, що й на вашому: викличеться відповідної програми. В цьому випадку необхідною умовою перенесення є наявність на іншій машині текстового редактора Write і графічного редактора Paintbrush.
При роботі в рамках DDE таке перенесення не можливий, точніше він буде включати в себе не тільки перенесення самого файлу-документа, а й пов'язаних з цим файлом файлів-джерел та цільових файлів - всієї структури.
Перспективи розвитку OLE
Технологія OLE робить тільки перші кроки. Поки тільки деякі Windows додатки є OLE сумісними. Серед утиліт групи Accessories версії 3.1 такими на сьогоднішній день є тільки Write, Paintbrush і Cardfile. Але навіть вони "у своєму колі" не допускають вставки в довільному напрямі (тобто з будь-який в будь-яку іншу). У настає час мова йде про підтримку найбільш виправданого з практичної точки зору "напрямку вбудовування" - з Paintbrush в Write і Сardfile документа.
Щоб визначити які з додатків підтримую OLE інтерфейс, необхідно з OLE-сумісного додатка виконати директиву "ВСТАВИТИ ОБ'ЄКТ" в меню "Edit". У отрившемся вікні буде продемонстрований список доступних вбудовуваних об'єктів.
На даний момент багато компілятори вже ввели підтримку OLE в свої бібліотеки: Borland C + + ver4.5. Приклад використання OLE технології наведено у додатку 1. Дана програма використовує створений малюнок Paintbrush у вигляді файлу або копіює його з Clipboard.
Висновок
У висновку хотілося б відзначити, що існуючі способи обміну інформації виникали разом з розвитком Windows. Як сама суть Windows, вони є продовженням закладеної в неї мета: cспособность працювати з файлами будь-яких форматів, на будь-якому обладнанні. На відміну від стандартного рішення, коли фірма-виробник оболонки (типу Windows) намагалася сама написати різні драйвери для підтримки пристроїв і різні бібліотеки для підтримки форматів численних файлів інших пакетів, фірма Microsoft поклала цей обов'язок на виробників обладнання та програмного забезпечення. Таким чином, послідовний розвиток Clipboard -> DDE -> OLE є продовженням втілення ідеї "сам винайшов - сам впроваджуй". Естесственно, найбільші надії зараз покладаються на OLE (її новий стандарт OLE.2), так як цей стандарт дозволяє включати в себе дуже потужні засоби, такі як Multimedia. В одному файлі може знаходиться не тільки текст, малюнок, а й навіть цілий фільм, повністю озвучений і готовий до показу.
Список літератури
1. Гладков С.А. Фролов Г.В. Програмування в Microsoft Windows: У 2-х частинах. М.: "ДІАЛОГ-МІФІ", 1992.
2. Фойц С. Windows 3.1 для користувача. Пер. з німецької Київ: BHV, 1992.
3. Microsoft Windows Software Development Kit. Version 3. Programmer's Reference, Programming Tools, Windows Extensions.
4. Charles Petzold. Programming Windows. Microsoft Press.
5 Borland C + +. Usres manual.