Програмування в LE-технологія Microsoft Windows

Передмова

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

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

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

Вперше ідеї ООП були реалізовані в середині 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.