Windows

ЗАПРОВАДЖЕННЯ.

ІСТОРІЯ СТВОРЕННЯ MICROSOFT WINDOWS.

ОГЛЯД ОСНОВНИХ ПРИНЦИПІВ ОРГАНІЗАЦІЇ ІНТЕРФЕЙСУ У WINDOWS.

Аппаратно-независимый графічний інтерфейс (GDI.

Стандартний оконно-ориентированный интерфейс.

Окно.

Пиктограммы.

Меню.

Смуги прокрутки.

Курсоры.

Каретка.

Блоки диалога.

Механізм повідомлень.

ІНТЕРФЕЙС ГРАФІЧНИХ ПРИСТРОЇВ (GDI.

Устрою GDI.

Логічні обьекты графіки GDI.

Контекст устройства.

Основні атрибути контексту устройства.

Перерисовка області й зображення пикселей.

Малювання линий.

Малювання зафарбованих фигур

Висновок тексту.

ЕЛЕМЕНТИ ВІКОННОГО ИНТЕРФЕЙСА…

Вікна Windows… 20.

Головне вікно приложения…

Реєстрація класу окна…

Функція вікна приложения…

Створення окна…

Відображення і відновлення окна…

Типи окна…

Побудова меню…

Визначення меню…

Обьекты діалогу…

Кнопки і переключатели…

Статичні обьекты диалога…

Редактор…

Вікно список…

Комбінований список…

ОБМІН ДАНИМИ МІЖ ДОДАТКАМИ…

Кошти обміну даними між приложениями…

Динамічний обмін між приложениями…

Основні терміни…

Декілька слів про DDEML…

Взаємозв'язок між клієнтом і сервером…

Транзакції, функція зворотного виклику DDE…

Допоміжні імена та інші назви…

Системний режим…

Ініціалізація…

Основне призначення та робота функції зворотного виклику.

Обробка рядків…

Діалог між додатками…

Простий Діалог…

Складний діалог…

Обмін даними між додатками…

Класи транзакцій…

Визначення помилок…

Список літератури…

ЗАПРОВАДЖЕННЯ.

Задля ефективної роботи системи та її большого.

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

У розроблено величезна кількість різноманітних систем підтримки створення користувальницького інтерфейсу. Найбільш прогресивному, на погляд, є обьектноориетированная система Turbo Vision фірми Borland і операційна середовище Windows фірми Microsoft. Розглядом можливостей системи Turbo Vision навчалася у свою роботу Фомичева Т. Л., а представленої роботі виробляється вивчення та огляд коштів, входять до складу операційній середовища Windows.

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

У Microsoft Windows програмісту доступна всю силу цього інтерфейсу — позбувається від виробничої необхідності організовувати меню, роботи з клавіатурою і мишею (досить скористатися стандартними засобами). Інтерфейс з користувачем Windows є повний та цільним. У ньому вирішені як проблеми організації меню, але й спілкування з користувачем організовано стандартними засобами.

ІСТОРІЯ СТВОРЕННЯ MICROSOFT WINDOWS.

Корпорація Microsoft оголосила початок розробки графічної операційній оболонки Windows 10 листопада 1983 року, хоча ще кінці 1982 року програмісти Microsoft почали створювати універсальний набір графічних процедур, під назвою Графічним Інтерфейсом з Комп’ютером (CGI).

Спочатку передбачалося, що CGI як набір процедур постачатиметься з компиляторами Microsoft, дозволяючи розробникам програм виводити графіку на найрізноманітніші типи принтерів. Програмісти міг би використовувати у своїх програмах функції CGI, які потім переводилися в команди потрібного типу принтера.

Незабаром після початку робіт над CGI корпорація Microsoft розгорнула робота зі створення графічної операційній середовища для комп’ютерів з MS-DOS. Створення такої оболонки було інспіровано несподіваним інтересом користувачів IBM сумісних комп’ютерів до оголошенню корпорацією VISICorp про початок робіт над многооконной операционнной оболонкою VisiOn. Отже, стара добра конкуренція не підкачала — у лютому 1983 року став ясно, що Microsoft створить своє власне оболонку Windows.

Хоча багато хто особливості й поліпшуючи властивості Windows кардинально змінилися у майбутньому, деякі положення були зрозумілі від початку. Windows мусить бути многозадачной, тобто. повинна дозволяти запускати кілька програм одночасно. Windows повинна працювати з усіма типами дисплеїв і принтерів. І оскільки користувачеві дуже важко відмовитися від звичних програмних засобів, Windows повинна дозволяти запускати докладання MS-DOS. Остання мета настільки виявилася важкою у реалізації, що затримала весь проект на багато месяцы.

Завдання не було з простих. Типовою машиною був комп’ютер зі порівняно повільним процесором 8088 і оперативної пам’яттю 64Kb. Коли ж врахувати, що MS-DOS накладає принципове обмеження по оперативної памити в 640Kb і на відміну від комп’ютерів Macintosh, не забезпечує программноаппаратную підтримку графіки, розробка многозадачной графічної операційній оболонки загрожувала вирости в нездійсненне завдання. Проте Microsoft розгорнула роботи над Windows на повну котушку. А до осені 1983 року розробкою Windows працювали уже виповнилося 15 висококваліфікованих програмістів, залучених нині проектом із різних філій Microsoft. Багато фірм відрядили своїх спеціалістів одночасної участі в проекте.

Коли роботи над CGI перейшли у фазу тестування, це був самостійний продукт. CGI був переменован в GDI (the Graphics Device Interface — «Інтерфейс з графічними Пристроями ») і становив частину Windows, включивши до себе процедури роботи тільки з принтером, але й дисплеєм. І тому в CGI було додано функції, щоб забезпечити підтримку типографско-издательских особливостей регулярно працюють з текстами і складні процедури маніпулювання графічними объектами.

При презентації першого варіанта буде Windows обіцяли, що комерційна продаж розпочнеться о травні 1984. Навесні 1984 року дата початку продажів була відсунута на листопад. У листопаді ця дата було покладено на червень 1985 року. Проте коробки з Windows з’явилися торік у магазинах лише 18 листопада 1985 года.

Кілька чинників сприяли настільки значительным.

затримкам. Проте головну роль зіграло небажання Microsoft.

виходити ринку з сирим продуктом. Вже у лютому 1984 року глава.

корпорації Microsoft Білл Гейтс (Bill Gates) провів семинар,.

у якому представив Software Development Kit (SDK), пакет.

для написання додатків під Windows, продемонструвавши на нем.

можливості, запропоновані програмісту під Windows.

SDK справив хороше враження і до червня 1984 року був продано майже сто копій. Почавши працювати під Windows, програмісти надсилали в Microsoft свої зауваження, примушуючи розробників ще та ще удосконалювати Windows, облегчая.

написання додатків. Був замінений мову, у якому создавался.

Windows (спочатку це був Microsoft Pascal, потім Lattice З и,.

нарешті, Microsoft З Compiler). Орієнтація на Microsoft C.

Compiler також було одним із причин затримки робіт над.

проектом, оскільки сам компілятор ні готовим продуктом.

і постійно совершенствовался.

Проте, як і раніше, у листопаді 1985 року Windows все-таки посів прилавки магазинів, протягом два роки (з 1985 по 1987 рік) Windows не надав великого впливу ринок програмного забезпечення не став альтернативою MS-DOS, як сподівався Microsoft. Велика кількість користувачів (51%) купували Windows не заради створених йому додатків (яких неможливо було обмаль проти звичайними програмами під MS-DOS) чи графічного інтерфейсу, а здобуття права матимуть можливість швидко переключатися з однієї DOS докладання на другое.

З 1987 року почала змінюватися. Почали з’являтися потужні й відомі докладання, переписані до роботи під Windows. Нині можна назвати такі продукти як Page Maker під Windows, дуже потужну електронну таблиця Excel, Windows Graph, Word for Windows і з другие.

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

У 1990 року «PC Magazine «помістив статтю про нове версії Windows 3.0, у якій зазначалося, що Microsoft Windows перетворився на блискучу многозадачную операційну систему, якої ще намагається стати OS/2. Як і програмні продукти Microsoft, перші версії Windows не виправдовували надій як і раніше, що виходили зі значними затримками, але у останньому варіанті залишають конкурентів давно минули.

ОГЛЯД ОСНОВНИХ ПРИНЦИПІВ ОРГАНІЗАЦІЇ.

ІНТЕРФЕЙСУ У WINDOWS.

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

— аппаратно-независимая графика;

— стандартний оконно-ориентированный интерфейс;

— взаємодія додатків і системи Windows і з передачі сообщений;

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

Аппаратно-независимый графічний інтерфейс (GDI).

Будь-яка програма для Windows може виконувати висновок будь-яку пристрій з допомогою однієї й тієї ж набору що викликаються підпрограм. Причому для Windows докладання всі пристрої виглядають однаково програмісту непотрібно забодится про управління конкретним пристроєм на низькому уровне.

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

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

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

Стандартний оконно-ориентированный інтерфейс.

Система Windows має вмонтовану підтримку низки об'єктів користувальницького інтерфейсу: вікон, піктограм, меню, блоків діалогу й т.п.

Вікно.

Вікно є найважливішу часть.

користувальницького інтерфейсу. Воно грає ключову роль.

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

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

Кожне вікно належить класу вікон. Клас вікон — це шаблон, яким реалізуються реальні вікна. Із кожним класом вікон та, отже, з кожним вікном пов’язаний спеціальний тип підпрограми, званий процедурою вікна. Завдання процедури вікна полягає у обробці вступників вікна сообщений.

Кожне додаток міститься у своєму власному вікні і має по крайнього заходу хоча одне вікно — головне вікно докладання. З докладання Windows безпосередньо реалізувати висновок на екран, оскільки екран є поділюваним ресурсом, а засобом його поділу є вікна. Отже, як відобразити щось на екрані, треба створити вікно, і лише у вікні можна здійснити вывод.

Піктограми.

Піктограма є невеличкий рисунок,.

який є для користувача нагадуванням про щось и.

позначають команду, програму чи деякі дані.

Меню.

Меню є список команд та зняття функцій програми. Є п’ять типів меню:

— системные,.

— горизонтальные,.

— выпадающие,.

— вложенные,.

— всплывающие.

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

Горизонтальне меню фіксоване прив’язується до горі окна.

Які меню з’являються під час виборів відповідних пунктів горизонтального меню.

Вкладені меню з’являються під час виборів відповідних пунктів випадаючих меню. Прикладна програма може вкладывать.

одне меню до іншого до рівня вложенности.

Спливають меню можуть розташовуватися у довільній позиції з вікні і буде у будь-якій позиції на екрані дисплея.

Смуги прокручування.

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

Існує обмеження на обсяг даних в скроллинге. Обсяг даних неспроможна перевищувати 64 Кбайт.

Курсоры.

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

Каретка.

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

Користувальницький інтерфейс Windows підтримує тільки один каретку на экране.

Блоки діалогу.

Блок діалогу — це стандартний спосіб прийому програмою введення від користувача. Типовий приклад блоку діалогу — це блок діалогу відкриття файла.

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

Система має шість визначених класів вікон, з урахуванням яких створюються елементи управління блоками диалога:

— кнопки;

— комбіновані блоки;

— елементи управління редактированием;

— блоки списков;

— смуги прокрутки;

— статичні элементы.

Більше повне опис об'єктів інтерфейсу представлено нижче.

Механізм повідомлень.

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

Додаток є 16-битовое значення без знака, котрому задля зручності присвоюється символьна константа. Усі повідомлення мають єдиний формат і є єдиним способом зв’язку докладання з операційній оболонкою і коїться з іншими додатками. Деякі повідомлення можуть у своє чергу породжувати інші сообщения.

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

Якщо повідомлення надійшло наприклад, від пристроїв введення, як-от миша чи клавіатура, то тут для визначення адресата повідомлення використовується поняття «фокус введення ». Оскільки користувач у кожний час може працювати лише з однією додатком. Отже, кажуть, що додаток, у якому потрапляють повідомлення від клавіатури в останній момент введення, має фокус введення, тому всі повідомлення від пристроїв введення інформації надходять із системної черги, у чергу докладання, має фокус входження у даний момент.

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

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

створенні вікна докладання. Цикл повідомлень дістає сообщения.

з черзі й передає їх функцій управління соответствующим.

вікном докладання, причому не безпосередньо, а ще через Window. Про функции.

вікна додатків йтиметься позже.

Усі стандартні повідомлення, певні у системі Windows можна розділити сталася на кілька групп:

— апаратні (вхідні дані від миші і клавиатуры);

— про організацію вікна (повідомлення, вимога дії, запрос);

— про організацію інтерфейсу користувача (меню,.

покажчик миші, лінійка прокручування, блоки діалогу, MDI);

— про завершення (закриття прикладної програми чи системы);

— приватні (елементи управління блоком діалогу: редактор кнопка, блок списку, комбо-блок);

— повідомлення про системному ресурсі (зміна кольору, шрифти, буферизация друку, режими роботи устройств);

— спільне використання даних (буфер вирізаної зображення динамічний обмін даними DDE);

— внутрішні системні (недокументированные сообщения).

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

і спільному використанню даних.

ІНТЕРФЕЙС ГРАФІЧНИХ ПРИСТРОЇВ (GDI).

У розділі розглядаються питання пов’язані зі створенням графічного виведення, обговорюються різні типи графічного виведення, підтримуваних інтерфейсом графічних пристроїв (GDI).

GDI є бібліотеку графічного виведення Windows. GDI забезпечує графічний висновок на екран дисплея і устрою щоб одержати твердих копій, наприклад, принтери і плоттеры. GDI відпо-відає створення відображення кожну лінію, літери чи графічного знака, виведеного програмою для Windows. Сама Windows використовує GDI при добірці елементів, складових користувальницький інтерфейс, — вікон, піктограм, меню, блоків діалогу й т.д.

Устрою GDI.

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

До того ж, драйвер устрою представляє GDI набір прапорів, які повідомляють, якими графічними можливості має дане пристрій. Існує п’ять наборів таких прапорів: для кривих ліній, для прямих, многоугольников, бітових образів тексти, які повідомляють GDI, коли можна направити влаштуванню безпосередньо запит, а коли така запит треба попередньо перетворити на послідовність запитів низького рівня. Це то можливостей конкретного устройства.

Крім фізичних пристроїв GDI підтримує логічні устрою, чи псевдоустройства. Псевдоустройства служать для зберігання зображень. На відміну то фізичних пристроїв, що виводять зображення на певної апаратної базі, псевдоустройства дозволяють «перехопити «образ зображення на оперативної пам’яті чи диску. GDI підтримує два типу псевдоустройств: бітові образи і метафайлы.

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

Метафайлы створюються засобами записи-воспроизведения.

GDI. З погляду расходуемой пам’яті метафайлы.

краще, ніж бітові образи, проте робота сними.

відбувається повільніше. Зазвичай, у метафайлах зберігаються крупные.

зображення.

Логічні обьекты графіки GDI.

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

— пера (для малювання линий);

— пензля (для закрашивания областей);

— шрифти (висновку текстов);

— логічні кольору (описують кольору вывода).

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

Контекст устрою.

Контекст устрою є некоторое.

безліч атрибутів графічного виведення, до якого входить одно.

перо для малювання ліній, одна пензель для закрашивания областей.

і тільки шрифт висновку текстів, які можна змінити в.

будь-якої миті. Разом взяті, атрибути графічного виведення дают.

повний контроль з того, що таке і выполняется.

графічний висновок программы.

Кожен контекст устрою включає у собі 20 атрибутів графічного виведення, які нижче (в дужках наведено значення по умолчанию):

— Колір фону (белый);

— Режим фону (OPAQUE);

— Логічний номер пензля (біла кисть);

— Початок координат пензля (0,0);

— Логічний номер області промальовування (вся поверхность);

— Логічний номер колірної палітри (палітра по умолчанию);

— Поточна позиція пера (0,0);

— Режим графічного виведення (R2_COPYPEN);

— Логічний номер шрифту (системний шрифт);

— Межсимвольный інтервал (0);

— Режим отбражения (MM_TEXT);

— Логічний номер пера (чорне перо);

— Режим закрашивания многоугольников (альтернативный);

— Режим розтяги (чорний по белому);

— Вирівнювання кордонів тексту (із лівого і верхньому краям);

— Колір тексту (чорний для тексту і пензлів з монохромним.

шаблоном закрашивания);

— Вирівнювання рядків тексту (0,0);

— Протяжність вікна даного екрана (1,1);

— Початок координат вікна даного екрана (0,0);

— Протяжність вікна екрана (1,1);

— Початок координат вікна екрана (0,0).

Контекст устрою пов’язує програму з конкретною поверхнею малювання. Таке з'єднання є логічним, а чи не фізичним. Щоб уникнути конфліктів, що з спільним використанням пристроїв, програма отримує в контексту устрою «перепустку «до влаштуванню. Робота системи перепусток залежить від типу устрою. На пристроях отримання твердих копій це шляхом буферизации введення, але в видеоустройствах — шляхом виділення так званої області промальовування, поза межами якої програма малювати неспроможна.

Основні атрибути контексту устрою.

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

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

Для закрашивания областей використовується атрибут пензель, визначальний як виглядатиме закрашиваемая область і характеризується трьома характеристиками: стилем, кольором і шаблоном. Розмір пензля становить 8Х8 пикселей.

При зображенні тексту ключовим атрибутом є шрифт. Шрифт — сукупність шаблонів висновку тексту. GDI розпізнає два виду шрифтів: логічні і физические.

Логічний шрифт описує текст стандартним не.

залежать від зовнішніх пристроїв способом. Логічний шрифт.

задається структурою LOGFONT. Логічний шрифт — це запит на.

на текст з деякими характеристиками.

typedef struct tagLOGFONT.

int lfHeight; // висота символа.

int lfWidth; // середня ширина.

int lfEscapement; // кут нахилу текста.

int lfOrientation; // кут нахилу символа.

int lfWeight; // середня кількість пикселей/1000.

BYTE lfItalic; // не 0, якщо курсив.

BYTE lfUnderline; // не 0, якщо подчеркнуто.

BYTE lfStrikeOut; // не 0, якщо вычеркнуто.

BYTE lfCharSet; // набір символів ANSI, OEM.

BYTE lfOutPrecision; // точнось отображения.

BYTE lfClipPrecision; // точність вырезки.

BYTE lfQuality; // якість друку.

BYTE lfPitchAndFamily; // прапор для стилю шрифта.

BYTE lfFaceName[LF_FACESIZE]; // назва шрифта.

LOGFONT;

Фізичний шрифт — це набір шаблонів, залежить від устрою. Він вибирається за описом, утримується в логічному шрифту і то, можливо апаратно реализован.

Для завдання атрибута контексту устрою використовується функція SelectObject, описана наступним образом:

HANDLE FAR PASCAL SelectObject (HDC, HANDLE);

Тут перший параметр — логічний номер контексту устрою, а другий — логічний номер значення атрибута.

А, щоб отримати логічний номер необхідного значення атрибута контексту, використовується функція GetStockObject. Її прототип:

HANDLE FAR PASCAL GetStockObject (int);

Параметром є значення атрибута контекста.

устрою, зазвичай для зручності задаваемое як набора.

символов.

Програміст може використовувати або вже задані значення атрибутів, творити нові.

Перерисовка області й зображення пикселей.

Через те, що Windows не накладає обмежень на розміри і місцезнаходження вікон додатків, виникатимуть ситуації, що вікно одного докладання перекриє вікно іншого докладання, тому при переключенні між додатками необхідно перерисовыть пошкоджені області окна.

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

Підпрограма BeginPaint приймає два параметра:

логічний номер вікна і покажчик на структуру данных.

PAINTSTRUCT, Вона повертає логічний номер контексту устрою, необхідний малювання пикселя. Прототип підпрограми має вид:

HDC FAR PASCAL BeginPaint (HWND, LPPAINTSTRUCT);

Структура PAINTSTRUCT визначено так:

typedef struct tagPAINTSTRUCT.

HDC hdc;

BOOL fErase;

RECT rcPaint;

BOOL fRestore;

BOOL fIncUpdate;

BYTE rgbReserved[16];

PAINTSTRUCT;

hdc — логічний номер контексту устройства;

fErase — прапор, ставить необхідність стирання вікна; rcPaint — описує прямокутник, ограничивающий.

пошкоджену область;

fRestore, fIncUpdate і rgbReserved призначені для внутрішнього використання Windows.

Для відображення пикселя використовується подпрограмма.

SetPixel. Її прототип:

DWORD FAR PASCAL SetPixel (HDC, int, int, DWORD);

HDC — логічний контекст устрою; такі два параметра — координати пикселя; останній параметр — цвет.

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

void FAR PASCAL EndPaint (HWND, LPPAINTSTRUCT);

Малювання ліній.

Кожна лінія має початкову і кінцевої точки, і GDI малює лінію так, початкова точка входить у лінію, а кінцева виключається з линии.

GDI має 4 підпрограми для малювання ліній: MoveTo, LineTo, PolyLine і Arc.

Підпрограма MoveTo поміщає пару координат XY в атрибут контексту устрою, що називається поточної позицією. Підпрограма має прототип:

DWORD FAR PASCAL MoveTo (HDC, int x1, int y1);

Підпрограма LineTo бере початкову точку з атрибута поточної позиції і малює лінію до кінцевої точки, переданої як параметр. Після цього вона встановлює нового значення атрибута поточної позиції. Підпрограма має прототип:

BOOL FAR PASCAL LineTo (HDC, int x1, int y1);

Підпрограма Polyline дозволяє намалювати ломанную лінію, але на її роботи необхідно попередньо створити масив координат точок. Підпрограма має прототип:

BOOL FAR PASCAL Polyline (HDC, LPPOINT points, int num);

points — покажчик на масив координат, якому координати осі абсцис і осі ординат чергуються; num — число пар координат в массиве.

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

BOOL FAR PASCAL Arc (HDC, int, int, int, int, int, int, int, int);

Малювання зафарбованих постатей.

Для малювання зафарбованих постатей існує семь.

різних функций.

Функція Polygon з'єднує розташовані послідовно точки з допомогою поточного встановленого у тих устрою пера. Функція визначено так:

BOOL FAR PASCAL Polygon (HDC, LPPOINT, int);

HDC — логічний номер контексту устройства;

LPPOINT — покажчик на масив координат, соединяемых граничних точек;

Третій параметр — число соединяемых точок.

Функція PolyPolygon дозволяє намалювати за виклик кілька многоугольников і так:

BOOL FAR PASCAL PolyPolygon (HDC, LPPOINT, LPINT, int);

HDC — логічний номер контексту устройства;

LPPOINT — покажчик на масив координат, соединяемых граничних точок всіх створюваних многоугольников;

LPINT — покажчик на масив типу int. Елементи масиву задають число точок у кожному многоугольнике*.

Останній параметр задає кількість точок в масиві LPINT, тобто кількість многоугольников.

Для малювання закрашенного еліпса використовується функція Ellipse. Вона визначається так:

BOOL FAR PASCAL Ellipse (HDC, int, int, int, int);

HDC — логічний номер контексту устройства;

Інші параметри визначають координаты.

який би прямокутника.

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

BOOL FAR PASCAL Chord (HDC,.

int, int,.

int, int,.

int, int,.

int, int);

HDC — логічний номер контексту устройства;

Наступні чотири параметри визначають координаты.

який би прямоугольника.

Далі вказуються координати початкової ідеї та кінцевої точки сегмента линии.

Функція Pie аналогічна функції Chord, лише малює не хорду, а сектор еліпса. Вона визначено наступним образом:

BOOL FAR PASCAL Pie (HDC,.

int, int,.

int, int,.

int, int,.

int, int);

HDC — логічний номер контексту устройства;

Наступні чотири параметри визначають координаты.

який би прямоугольника.

Далі вказуються координати початкової ідеї та кінцевої точки сектора.

Для малювання прямокутника використовується функция.

Rectangle.Ее прототип:

BOOL FAR PASCAL Rectangle (HDC, int, int, int, int);

HDC — логічний номер контексту устройства;

Інші параметри визначають координаты.

прямокутника.

Якщо потрібно намалювати прямокутник з закругленими краями, те є функція RoundRect. Вона визначено та:

BOOL FAR PASCAL RoundRect (HDC,.

int, int,.

int, int,.

int, int);

HDC — логічний номер контексту устройства;

Наступні чотири параметри визначають координаты.

прямоугольника.

Останні два параметра задають ширину і висоту який би прямокутника для еліпса, використовуваного при скруглении кута.

Висновок тексту.

Для виведення тексту є п’ять основних функций.

Функція TextOut варта виведення рядка. Вона визначено наступним образом:

BOOL FAR PASCAL TextOut (HDC, int, int, LPSTR, int);

HDC — логічний номер контексту устройства;

Наступні два параметри визначають координати точки прив’язки виведеної стоки текста.

LPSTR — покажчик на виведену символьну строку.

Останній параметр — число символів в рядку тексту.

Більше потужний варіант функції TextOut є функція ExtTextOut. Вона дозволяє управляти інтервалом між рядками і вырезкой.

BOOL FAR PASCAL ExtTextOut (HDC,.

int, int,.

WORD wOptions,.

LPRECT lpRect,.

LPSTR lpString,.

WORD nCount,.

LPINT lpDx);

HDC — логічний номер контексту устройства;

Наступні два параметри визначають координати точки прив’язки виведеної стоки текста.

wOptions — прапор, приймає значення 0, ETO_CLIPPED, ETO_OPAQUE і ETO_CLIPPED|ETO_OPAQUE, дозволяє встановлювати прямокутні області вирізки і за виведення тексту затирати фон.

lpRect — покажчик на структуру прямоугольника;

lpString — покажчик на виведену символьну строку.

nCount — число символів в рядку тексту. lpDx ;

покажчик на масив значень інтервалів между.

символами.

Функція TabbedTextOut при виведення тексту поширює знаки табуляції до позицій табуляції. Це забезпечує зручний спосіб вирівнювання шпальт даних. Прототип функции:

LONG FAR PASCAL TabbedTextOut (HDC,.

int, int,.

LPSTR, int, LPINT, int);

HDC — логічний номер контексту устройства;

Наступні два параметри визначають координати точки прив’язки виведеної стоки текста.

LPSTR — покажчик на виведену символьну строку.

Наступний параметр — число символів в рядку тексту.

LPINT — покажчик на масив позицій табуляции;

Останній параметр — число елементів масиві позицій табуляции.

Функція DrawText забезпечує деяку можливість форматування і у автоматичному режимі нові рядок при велику кількість рядків тексту. Її прототип:

int FAR PASCAL DrawText (HDC, LPSTR, int, LPRECT, WORD);

HDC — логічний номер контексту устройства;

LPSTR — покажчик на виведену символьну строку.

Наступний параметр — число символів в рядку тексту. LPRECT — покажчик на структуру прямоугольника,.

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

Для відображення заблокованих пунктів меню и.

заблокованих елементів управління блоками діалогу Менеджер

Вікон використовує функцію GrayString.

ЕЛЕМЕНТИ ВІКОННОГО ІНТЕРФЕЙСУ.

Вікна Windows.

Головне вікно приложения.

Кожне додаток розташований у своєму власному вікні і має по крайнього заходу хоча одне вікно — головне вікно докладання. З докладання Windows безпосередньо реалізувати висновок на екран, оскільки екран є поділюваним ресурсом, а засобом його поділу є вікна. Отже, як відобразити щось на екрані, треба створити вікно, і лише у вікні можна здійснити вывод.

Функція головного вікна докладання виконує на програмі таку ж роль, що функція main () програми на Сі для MS-DOS. Під час створення вікна функція бібліотеки SDK виконує спеціальні дії початковій підготовки в DOS, не явно здійснюваних функцією main (). Тому додаток зовсім позбавлений функції main (), роль якої виконує функція WinMain (), отримує управління початковий момент завантаження докладання. Функція WinMain () виконує такі основні действия:

— реєстрація класу вікна докладання і другие.

инициализации;

— створення основного вікна докладання і, можливо, інших, підлеглих окон;

— запуск циклу обробки повідомлень, помещаемых у чергу приложения;

— завершення роботи докладання при добуванні з черги повідомлення WM_QUIT.

Прототип функції WinMain виглядає так:

int PASCAL WinMain.

(.

HANDLE instance, // дескриптор попередньої копии.

HANDLE prevInstance, // попередня копия.

LPSTR cmdLine, // покажчик на командну строку.

int cmdShow // прапор «вікно открыто/закрыто «.

);

instance — однозначно визначає кожну копию.

докладання, якщо додаток запущено кілька раз.

prevInstance — визначає копію даного докладання, що була останньої активної копією. Якщо це параметр дорівнює 0, то інших копій докладання, виконуваних в момент не существует.

cmdLine — далекий покажчик на командний рядок, що закінчувалася нулем. Він дає змогу додатків отримувати дані через командну строку.

cmdShow — визначає, як додаток спочатку відображати на екрані: піктограми (cmdShow = SW_SHOWMINNOACTIVE) або у вигляді відкритого вікна (cmdShow = SW_SHOWNORMAL). Константи SW_SHOWMINNOACTIVE і SW_SHOWNORMAL визначено у включаемом файлі windows.h.

Реєстрація класу окна.

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

Характеристики вікна задаються при реєстрації класу вікна (у структурі класу вікна) при створенні вікна. Найбільш загальні характеристики вікон задаються при реєстрації класу вікна. Вікна, створювані з допомогою функції CreateWindiw, повинен мати зареєстрований раніше клас окон.

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

А, щоб зареєструвати клас вікон, слід правильно заповнити структуру типу WNDCLASS і цю структуру як параметра функції RegisterClass. Структура класу вікна має вид:

typedef struct tagWNDCLASS.

WORD style; // тип окна.

LONG (FAR PASCAL *lpfnWndProc)(); // функція вікна int cbClsExtra; // розмір доп. памяти.

int cbWndExtra; // розмір доп. памяти.

HANDLE hInstance; // індекс копії приложения.

HICON hIcon; // індекс пиктограммы.

HCURSOR hCursor; // індекс курсора.

HBRUSH hbrBackground; // колір фону окна.

LPSTR lpszMenuName; // ім'я меню.

LPSTR lpszClassName; // ім'я класу окна.

WNDCLASS;

lpszClassName — покажчик на рядок, що містить ім'я класу. Оскільки певний при застосуванні клас доступний всім додатків, ім'я класу на повинен повторяться у різних приложениях.

hInstance — маніпулятор копії, що створює клас вікна; повинна утримувати індекс копії приложения.

lpfnWndProc — покажчик на функцію підтримки вікна. Короткий опис цієї функції дивися наступного разделе.

style — містить набір прапорів, визначальних властивості вікна. За умовчанням присвоюється NULL.

hBrBackground — визначає колір фону окна.

hCursor — визначає курсор, вживаний у даному вікні по умолчанию.

hIcon — визначає піктограму (icon), яка відображатись під час перекладу вікна в неактивне состояние.

lpszMenuName — покажчик з ім'ям меню вікна, певне в файлі ресурсов.

cbClsExtra — визначає число байт, що слід додатково запросити у Windows під цей дивний організм. Цей обсяг пам’яті буде зарезервований наприкінці структури всім вікон даного класса.

clWndExtra — визначає число байт, що слід додатково запросити у Windows розміщувати всіх структур, створюваних що з даним классом.

Після визначення полів структури WNDCLASS необхідно зареєструвати клас з допомогою функції RegisterClass.

BOOL FAR PASCAL RegisterClass (LPWNDCLASS winClass);

Якщо реєстрація класу пройшла успішно, то яке значення TRUE, інакше — FALSE.

При реєстрації класу вікна Windows копіює структуру, описує клас вікна, в системну область, щоб іншим копіям докладання не треба був її реєструвати.

Функція вікна приложения.

Функція вікна докладання робить те, що обробляє все повідомлення для вікон даного класу. Це функція всегда.

викликається неявно Windows на час вступу повідомлень у вікно, за.

яким вона закріплено. Функція вікна має вид:

long far PASCAL WndProc (HWND hwnd,.

WORD msg,.

WORD wParam,.

LONG lParam);

hwnd — логічний номер вікна, ідентифікуючий вікно, що з приложением;

msg — ідентифікатор приложения;

wParam і lParam визначають додаткову інформації і залежить від типу сообщения.

Для полегшення роботи програміста существует.

спеціальна функція обробки повідомлень DefWindowProc з теми.

ж параметрами, яка виробляє стандартну обробку всех.

повідомлень. З іншого боку він відіграє ключову роль формировании.

інформаційних потоків повідомлень Windows, і його вказівку в.

функції вікна обов’язково.

Створення окна.

Створення вікна виробляється з допомогою функции.

CreateWindow. Вона створює вікно, має зазначений тип і те що до зазначеного класу. Прототип функції має вид:

HWND FAR PASCAL CreateWindow.

(.

LPSTR, // ім'я класу окна.

LPSTR, // заголовок окна.

DWORD, // тип окна.

int, // X-координата.

int, // Y-координата.

int, // Ширина окна.

int, // Висота окна.

HWND, // Дескриптор копии-родителя.

HMENU, // Дескриптор меню.

HANDLE, // Дескриптор копии.

LPSTR // Додаткова информация.

);

Тип вікна є комбінацією бітових флагов,.

визначальних стиль вікна. Можливі значення типу вікна розглянуті ниже.

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

Дескриптор меню дозволяє визначити меню, що буде зображуватися в окне.

Дескриптор копії дозволяє ідентифікувати власника вікна, тобто вказує Windows, що саме примірник програми створив вікно. Через війну Windows має можливість правильно встановити регістр сегмента даних для.

ініціалізації окна.

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

Що стосується успішного створення вікна функція CreateWindow повертає індекс вікна.

Відображення і відновлення окна.

Вікно не відображається на екрані відразу після створення; для відображення вікна використовується функція ShowWindow. Її прототип:

BOOL FAR PASCAL ShowWindow (HWND wnd, int cmdShow);

wnd — дескриптор відображуваного окна;

cmdShow — визначає, як вікно спочатку вказуватиметься на экране:

SW_SHOWNORMAL — звичайне окно;

SW_SHOWMINIMIZED — минимизированное як піктограми; SW_SHOWMAXIMIZED — максимизорованное все экран;

Для відновлення вікна використовується функція UpdateWindow. Її прототип виглядає так:

void FAR PASCAL UpdateWindow (HWND wnd);

Типи окна.

Тип вікна задається 32-битовым цілим числом, яке є комбінацію бітових прапорів, які визначають різні властивості окна.

WS_OVERLAPPED — перекрывающееся вікно. Перекрывающиеся вікна — це основний найбільш універсальний тип вікон Windows. Головне вікно докладання зазвичай має тої вид.

WS_POPUP — допоміжні вікна. Їх використовують найчастіше для відображення вікон діалогу. Ось лише деякі властивості допоміжних окон:

— коли таке вікно має батьківське вікно, то завжди відбиваються поверх всіх вікон на екрані, коли користувач робить активним інше окно;

— допоміжні вікна немає заголовка і найчастіше повинен мати фіксований размер.

WS_CHILD — дочірнє вікно. Вікна подібного типу створюються, якщо в докладання є головне (отже, і перекрывающее вікно) і пов’язані деякі характеристики про те вікном з яких були викликані. Усі керівні органи також є дочірніми вікнами. Ось лише деякі їх властивості:

— дочірні вікна будь-коли відбиваються поза свого батьківського вікна ні з розкритому вигляді, ні з вигляді пиктограммы;

— координати дочірніх вікон звітують від верхнього лівого кута робочої області окна-родителя і за переміщенні останнього, дочірні вікна переміщаються разом із ним;

— дочірнє вікно будь-коли може бути активним окном.

WS_MINIMIZE — створюване вікно буде зафіксовано у вигляді пиктограммы.

WS_VISIBLE — Вікно стає видимим відразу після створення. Використовується для діалогових окон.

WS_DISABLED — створюється неактивне окно.

WS_CLIPSIBLINGS — виняток областей, занимаемых.

іншими дочірніми вікнами з змінюваного області дочірнього окна.

Використовується лише дочірніх окон.

WS_CLIPCHILDREN — виняток областей, занимаемых.

іншими дочірніми вікнами за зміни робочої области.

батьківського вікна. Використовується лише батьківських окон.

WS_MAXIMIZE — створюване вікно буде зафіксовано у максимально можливий виде.

WS_CAPTION — вікно має рамку і заголовок, отже користувач може переміщати його за допомоги мыши.

WS_BORDER — вікно має широку рамку без заголовка. Використовується під час створення діалогових окон.

WS_DLGFRAME — вікно має тонку рамку без заголовка.

WS_VSCROLL — вікно має вертикальну смугу просмотра.

WS_HSCROLL — вікно має горизонтальну смугу просмотра.

WS_SYSMENU — вікно має системне меню.

WS_THICKFRAME — створюване вікно має рамку істотно помітної толщины.

WS_MINIMIZEBOX — вікно має кнопку минимизации.

WS_MAXIMIZEBOX — вікно має кнопку максимізації.

Побудова меню.

До сформування меню потрібно проделать:

1. Поставити структуру меню в файлі ресурсов,.

послідовно визначивши пункти меню як текстових строк.

2. Кожному пункту меню експортувати відповідність.

унікальний идентификатор.

3. Вказати ім'я меню у структурі класу вікна.

Визначення меню.

Визначення меню в файлі ресурсів повинен мати вид:

MenuName MENU [опції загрузки][опции памяти].

BEGIN.

MENUITEM «Item1 «IDM_Item1 [, опции].

MENUITEM «Item2 «IDM_Item3 [, опции].

…

POPUP «Item3 «[, опции].

BEGIN.

MENUITEM «Item3−1 «IDM_Item3−1 [, опції] MENUITEM «Item3−2 «IDM_Item3−2 [, опції] …

END.

END.

MenuName — ім'я ресурсу меню для звернення з подпрограммы.

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

Опції пам’яті визначають, як Windows повинна поводження з сегментом пам’яті, куди завантажується ресурс.

Пункти меню визначаються між словами BEGIN і END. Вони може бути два види: MENUITEM і POPUP. Пункт типу MENUITEM є кінцевою пунктом меню. При виборі цього пункту функції вікна повідомлення передається повідомлення WM_COMMAND з ідентифікатором пункту меню як параметра. Пункт типу POPUP є заголовком подменю.

Опції пункту меню можуть комбінуватися. Як опцій пункту меню можуть бути такими значения:

GRAYED — пункт меню не активний. Текст пункту меню відображається у сірому цвете.

INACTIVE — пункт меню не активний. Текст пункту меню відображається як і за іншими пунктах.

MENUBREAK — цей і наступні його пункти меню відбиваються з нового стовпці (якщо зазначений головного меню, то нової строке).

MENUBARBREAK — цей і наступні його пункти меню відбиваються з нового стовпці (якщо зазначений головного меню, то нової рядку); попередній і розпочнеться новий стовпець поділяються вертикальної чертой.

CHECKED — пункт меню помечен галочкою, вміщеній ліворуч від нього. Не діє для пунктів головного меню.

SEPARATOR — визначає роздільник, який виділяє до груп пов’язані списки меню.

HELP — пункт меню вирівнюється по з правого боку меню.

Обьекты діалогу.

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

Взаємодія між батьківським вікном (вікном діалогу) і обьектами діалогу здійснюється з допомогою повідомлень. Коли користувач виробляє якесь дію з обьектом діалогу, функції вікна батька передається повідомлення WM_COMMAND, як параметра wParam якого передається індекс об'єкта діалогу, а ролі параметра lParam — спеціальна додаткова информация.

А, щоб сконструювати об'єкт діалогу нужно:

1. Зареєструвати клас вікна диалога.

2. Створити дочірнє вікно функцією CreateWindow, вказавши зареєстрований клас окна.

3. До функцій вікна об'єкта діалогу визначити дескриптор дочірнього вікна з допомогою функції GetParent.

4. З того чи іншому дії користувача повідомляти батьківське вікно відповідними повідомленнями з допомогою функції SendMessage.

Для об'єктів діалогу як дочірніх вікон непотрібен реєструвати клас вікна — в Windows визначено стандартні класи вікон — об'єктів діалогу: «button », «edit », «scrollbar », «listbox «і пр.

З використанням стандартних класів Windows до створення об'єкта діалогу потрібно викликати лише функцію CreateWindow.

Розглянемо основні обьекты діалогу.

Кнопки і переключатели.

Кнопка «Button «зазвичай використовується реалізації яких — або негайних дій, без перемикання чи включения/выключения будь-яких опций.

Перемикач «І «(«CheckBox ») використовується как.

перемикач опцій вкл/выкл. Будучи з'єднаними в группу.

перемикачі реалізують логіку «І «.

Перемикач «АБО «(«RadioButton ») використовують як перемикач опцій вкл/выкл. Будучи з'єднаними у групу перемикачі реалізують логіку «АБО » .

Навколо цих основних типів є певні варіації. Нижче наводиться опис стандартних класів кнопок.

і переключателей.

BS_PUSHBUTTON — визначає кнопку з жирною рамкой.

BS_DEFPUSHBUTTON — визначає кнопку з жирною рамкою. Зазвичай використовується визначення дії з умолчанию.

BS_CHECKBOX — визначає квадратик, має два.

стану: відзначене (перекреслять хрестиком) і отмеченное.

(квадратик порожній). У час позначки рамка квадрата выделяется.

жирною линией.

BS_AUTOCHECKBOX — теж, попередній, лише стан кнопки при позначці відстежується автоматически.

BS_RADIOBUTTON — визначає круглу кнопку, яка то, можливо натиснута (всередині окружності жирна точка) і відпущена. Праворуч від кнопки може бути будь-якою поясняющий текст.

BS_AUTORADIOBUTTON — теж, як і попереднє, лише за позначці кнопки користувачем раніше зроблена позначка автоматично снимается.

BS_3STATE — теж, як і BS_CHECKBOX, лише додано стан, що «дія чи властивість не справді (позначається штрихуванням кнопки).

BS_AUTO3STATE — теж, як і попереднє, лише зміна станів підтримується автоматически.

BS_GROUPBOX — визначає рамку, що охоплює інші обьекты диалога.

BS_OWNERDRAW — об'єкт діалогу, определяемый.

користувачем, що цілком перебирає роботи з ним.

BS_LEFTTEXT — використовується для выравнивания.

роз’яснювального тексту по лівому боці кнопок.

Кнопки посилають функції вікна батька сообщение.

WM_COMMAND,.

як параметра lParam вказується дескрипотор органа.

управління і код нотифікації, службовець визначення того,.

яке дію справив користувач з кнопкою.

Статичні обьекты диалога.

Статичні обьекты діалогу йдуть на відображення тексту і отрисовки оформлювальних примітивів. Обьекты цього можна створити зазначенням функції CreateWindow імені класу «static ». Визначено такі класи статичних обьектов:

SS_LEFT — текст, выравненный із лівого краю;

SS_CENTER — центрированный текст;

SS_RIGHT — текст, выравненный по правому краю;

SS_ICON — пиктограмма;

SS_BLACKRECT — прямокутник кольору рамки фона;

SS_GRAYRECT — прямокутник кольору фону вікна;

SS_WHITERECT — прямокутник кольору окна;

SS_BLACKFRAME — рамка кольору рамки окна;

SS_GRAYFRAME — рамка кольору фону окна;

SS_WHITEFRAME — рамка кольору окна;

SS_USERITEM — об'єкт, визначається користувачем.

Редактор

Редактор «edit «дозволяє створити дочірнє вікно і редагувати у ньому текст. За умовчанням редактор може редагувати тільки один рядок. Типи класів редактора наведено ниже.

ES_LEFT — текст, выравненный із лівого краю;

ES_CENTER — центрированный текст;

ES_RIGHT — текст, выравненный по правому краю;

ES_MULTILINE — визначає багатосторінковий редактор;

ES_UPPERCASE — символи перетворюються на верхній регистр;

ES_LOWERCASE — символи перетворюються на нижній регистр;

ES_PASSWORD — стиль для введення паролей;

ES_AUTOHSCROLL — автоскроллинг вправо на 10 позиций,.

якщо курсор перебуває у кінці строки;

ES_AUTOVSCROLL — при натисканні ENTER наприкінці сторінки текст автоматично зсувається вгору однією экран.

Як параметрів повідомлення WM_COMMAND передаються ідентифікатор дочірнього окна-редактора, індекс дочірнього вікна і код повідомлення. Код повідомлення може быть:

EN_SETFOCUS — редактору тексту передали фокус ввода;

EN_KILLFOCUS — редактор тексту втратив фокус ввода;

EN_CHANGE — вміст редактора изменено;

EN_ERRSPACE — переповнювання буфера редактора;

EN_HSCROLL — натиснута клавіша горизонтального просмотра;

EN_VSCROLL — натиснута клавіша горизонтального перегляду.

Вікно список.

Вікно список «listbox «є прямокутник, у якому перебуває листаемый список з текстових рядків. Користувач може виділити рядки списку з допомогою курсору. Окно-список використовується для перегляду і вибору елементів деревоподібного списку. Наведемо типи вікна списка.

LBS_NOTIFY — батьківське вікно отримує інформацію про будь-якому дії користувача в списке;

LBS_SORT — рядки сортуються за алфавітом; LBS_MULTIPLESEL — множинний вибір з переключением.

вибору кожної строки;

LBS_OWNERDRAWFIXED — відображення вмісту списку доручається функцію батьківського вікна, все елементи списку може мати різну высоту;

LBS_OWNERDRAWVARIABLE — відображення вмісту списку доручається функцію батьківського вікна, все елементи списку може мати різну высоту;

LBS_HASSTRINGS — визначає користувальницьке окно-список з довільними строками;

LBS_USETABSTOPS — символи табуляції вживають пробелы;

LBS_MULTICOLUMN — визначає многостолбцовый список; LBS_EXTENDEDSEL — в окне-списке можна делать.

множинний вибір з допомогою миші і клавіші Shift.

Як параметрів повідомлення WM_COMMAND передаються ідентифікатор дочірнього окна-редактора, індекс дочірнього вікна і код повідомлення. Код повідомлення може быть:

LBN_ERRSPACE — списку бракує памяти;

LBN_SELCHANGE — змінено вибір элемента;

LBN_DBLCLK — вибір подвійним натисканням кнопки миші.

Комбінований список.

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

редагування, до котрої я привішено окно-список. Стандартные.

типи обьекта:

CBS_SIMPLE — список відображається постійно, і поточне виділення відстежується серед елементів списка;

CBS_DROPDOWN — те, як і попереднє, але список не відображається, поки користувач на натисне на ліву кнопку мыши;

CBS_DROPDOWNLIST — те, але рядок редагування замінюється на статичну текстову рядок, його не можна редактировать;

CBS_OWNERDRAWFIXED — елементи списку отрисовываются користувачем, їх висота одинакова;

CBS_OWNERDRAWVARIABLE — елементи списку отрисовываются користувачем, їх висота одинакова;

CBS_AUTOHSCROLL — горизонтальна прокручування в рядку редактирования;

CBS_SORT — сортування автоматична елементів списку.

ОБМІН ДАНИМИ МІЖ ДОДАТКАМИ.

Кошти обміну даними між додатками.

Однією з коштів, які забезпечують программную.

сумісність, є механізм обміну даними между.

различнами додатками. Спеціальний поштову скриньку (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 у додатках у таких разделах:

— Основні термины.

— Декілька слів про DDEML.

— Взаємодія Клієнта і Сервера.

— Транзакції, функція зворотного виклику DDE.

(CallBack function).

— Service, item і topic имена.

— Системний режим.

— Инициализация.

— Основне призначення та робота функції зворотного вызова.

— Обробка строк.

— Service імена. Реєстрація, фильтр

— Діалог між приложениями.

— Простий диалог.

— Складний диалог.

— Обмін даними між приложениями.

— Класи транзакций.

— Визначення наявності помилок при динамічному обміні даними.

Основні терміни.

Клієнтське додаток DDE — додаток, якому необхідно встановити діалог із сервером й одержати дані від серверу у процесі диалога.

DDE-диалог — взаємозв'язок між клієнтським і серверним приложениями.

Сервер-приложение — DDE додаток, яке передає дані клієнту у процесі диалога.

DDE-Транзакцияобмін повідомленнями чи даними між клієнтом і сервером.

Item ім'я — рядок, идентифицирующая некоторое.

безліч даних, яке сервер може передать.

клієнту у процесі диалога.

Service ім'я — рядок, генерируемая сервером и.

використовувана клієнтом задля встановлення диалога.

Строковый покажчик — подвійне слово, генеровану операційній системою, идентифицирующее рядок, передающуюся у процесі динамічного обміну данными.

Topic ім'я — рядок, яка ідентифікує тип.

даних, необхідних клієнтському додатку при.

динамічному обміні данных.

Фільтр транзакції - прапор, який препятствует.

передачі небажаних типів транзакцій на функцию.

зворотного виклику.

Декілька слів про DDEML.

У Microsoft Windows динамічний обмін даних є формою зв’язку, що використовує загальні області пам’яті обмінюватись даними між додатками. Додаток може використовувати DDE в певний час передачі й отримання нових даних від сервера.

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

Бібліотека DDEML забезпечує користувача набором коштів, які спрощують використання механізму DDE в WINDOWS додатках. Натомість, щоб обробляти, отримувати передавати DDE повідомлення безпосередньо, докладання використовують функції DDEML бібліотеки. Бібліотека DDEML також забезпечує роботу з рядками і поділюваними даними, генерируемыми DDE додатками. Натомість, щоб використовувати покажчики на загальні області пам’яті, DDE докладання створюють і обмінюються строковыми покажчиками, які ідентифікують рядки — і данные.

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

Взаємозв'язок між клієнтом і сервером.

DDE виникає завжди між клієнтським додатком і серверним. Клієнтське додаток инициализирует обмін даними через встановлення діалог із сервером і передачі транзакції. Транзакція необхідна для даних, і обслуговування. Сервер відповідає на транзакцію і відданість забезпечує клієнта даними. Сервер може мати відразу кількох клієнтів за одну і також час, своєю чергою, клієнт може отримувати дані відразу від кількох основних серверів. Певний додаток одночасно може бути клієнтом і сервером. Додатково вищесказаного, клієнт і сервер можуть обірвати діалог у зручний їм час.

Транзакції, функція зворотного виклику DDE.

(CallBack function).

DDEML інформує додаток про активності DDE через передачу транзакції до функцій зворотного виклику даного докладання. DDE транзакція схожа зі звичайним повідомленням — це іменована константа, супроводжувана іншими параметрами, які містять додаткову інформацію про поточної транзакции.

DDEML передає транзакцію до функцій зворотного виклику докладання, що виконує деяке дію відповідно до типом і виду транзакції. Наприклад, коли клієнтське додаток намагається встановити дилог з сервером, клієнт викликає функцію DdeConnect. Це означає, що DDEML повинна послати транзакцію XTYP_CONNECT до функцій зворотного виклику серверу. Функція зворотного виклику може дозволити або дозволяти установку діалогу, повертаючи TRUE чи FALSE DDEML.

Допоміжні імена та інші названия.

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, додаток повинно викликати функцію DdeInitialize. Ця функція отримує ідентифікатор копії даного докладання, реєструє функцію зворотного виклику докладання у вигляді DDEML і вказує прапор фільтра транзакції для функції зворотного виклику.

Кожне додаток чи DLL має содержать.

ідентифікатор своєї копії, наприклад, в параметрі idInst.

Він необхідний будь-який функції DDEML. Це дуже просто можна пояснити: призначення DDEML — підтримка механізму DDE в додатках, кілька копій яких то, можливо запущено в момент часу. Проте додаток НЕ МОЖЕ використовувати більше копії DDEML.

Фільтр транзакції оптимізує эффективность.

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

DWORD idInst = 0;

HINSTAINCE hInst;

DdeInitialize (&idIns, // Копія приложения.

(PFNCALLBACK) DdeCallback, // Адреса CallBack функції CBF_FAIL_EXECUTES | // Фільтр XTYPE_EXECUTE CBF_SKIP_ALLNOTIFICATIONS, 0);// Фільтр NOTIFICATIONS.

Кожне додаток має викликати функцию.

DdeUninitialize, як його большє нє собирается.

використовувати DDEML. Ця функція припиняє поточний діалог та звільняє ресурси DDEML, надані системою задля встановлення діалогу.

Основне призначення та робота функції зворотного вызова.

Додаток, яке використовує DDEML, должно.

утримувати функцію зворотного виклику, яка обробляє події, отримані додатком. DDEML повідомляє додаток про такі подіях шляхом посилки транзакцій на функцію зворотного виклику даного приложения.

Залежно від прапора фільтра транзакции,.

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

HDDEDATA CALLBACK DdeCallback (uType, uFmt, hconv, hsz1, hsz2, hdata, dwData1, dwData2).

UINT uType; // Тип транзакции.

UINT uFmt; // Формат почтого ящика.

HCONV hconv; // Ідентифікатор диалога.

HSZ hsz1; // Ідентифікатор рядки #1.

HSZ hsz2; // Ідентифікатор рядки #2.

HDDEDATA hdata; // Ідентифікатор глобального об'єкта пам’яті DWORD dwData1; // Дані поточної транзакції #1.

DWORD dwData2; // Дані поточної транзакції #2.

switch (uType).

case XTYP_REGISTER:

case XTYP_UNREGISTER:

.. .

return (HDDEDATA) NULL;

case XTYP_ADVDATA:

.. .

return (HDDEDATA) DDE_FACK;

case XTYP_XACT_COMPLETE:

.. .

return (HDDEDATA) NULL;

case XTYP_DISCONNECT:

.. .

return (HDDEDATA) NULL;

default:

return (HDDEDATA) NULL;

Параметр uType ідентифікує тип посланной.

транзакції до функцій зворотного виклику з допомогою DDEML. Значення решти параметрів залежить від типів транзакції. Типи транзакцій обговорюватимуть нами розділ «Обробка Транзакцій » .

Обробка строк.

А, щоб працювати у режимі диалога,.

більшість DDEML функцій вимагає наявності доступу до рядкам. Наприклад, клієнт повинен перетворитися на явному вигляді вказувати service і topic імена, коли додаток викликає функцію DdeConnect задля встановлення діалог із сервером. Додаток вказує рядок через передачу її ідентифікатора до відповідного місце (як і у разі покажчика на DDEML функцію). Ідентифікатор рядки — це подвійне слово, обумовлений системой.

Додаток може мати простий ідентифікатор строки.

шляхом виклику відповідної функции.

DdeCreateStringHandle. Ця функція реєструє рядок у системі і повертає її ідентифікатор додатку. Наступний приклад отримує ідентифікатор рядки для рядків System topic і Service-name.

HSZ hszServName;

HSZ hszSysTopic;

.. .

hszServName = DdeCreateStringHandle (.

idInst, // Копія докладання.

" MyServer ", // Рядок для регистрации.

CP_WINANSI); // Кодова сторінка Windows ANSI.

hszSysTopic = DdeCreateStringHandle (.

idInst, // Копія приложения.

SZDDESYS_TOPIC, // Рядок для реєстрації CP_WINANSI); // Кодова сторінка Windows ANSI.

.. .

Параметр idInst містить идентификатор,.

повернутий функцією DdeInitialize.

Функція зворотного виклику отримує чи більш строковых ідентифікаторів при обробці більшості DDE-транзакций. Наприклад, сервер отримує два ідентифікатора рядків процесі транзакції типу XTYP_REQUEST: один ідентифікатор — це рядок, яка описувала topic ім'я, а інший — item.

Додаток може отримувати довжину строки,.

відповідну ідентифікатору рядки — і копіювати эту.

рядок в певний буфер, попередньо зарезервированный.

приложением.

Усі вищевказані дії можна проробити з допомогою виклику функції DdeQueryString, як продемонстровано наступного примере:

DWORD idInst;

DWORD cb;

HSZ hszServ;

PSTR pszServName;

.. .

cb = DdeQueryString (idInst, hszServ, (LPSTR) NULL, 0,.

CP_WINANSI) + 1;

pszServName = (PSTR) LocalAlloc (LPTR, (WORD) cb);

DdeQueryString (idInst, hszServ, pszServName, cb, CP_WINANSI);

.. .

Отже, функція DdeQueryString створює строку,.

використовуючи строковый ідентифікатор, та був функция.

DdeCreateStringHandle створює строковый ідентифікатор з рядки. Слід зазначити, що дві ідентифікатора НЕ СУЩЕСТВУЮТ за одну і також время.

DWORD idInst;

DWORD cb;

HSZ hszInst, hszNew;

PSZ pszInst;

.. .

DdeQueryString (idInst, hszInst, pszInst, cb, CP_WINANSI); hszNew = DdeCreateStringHandle (idInst, pszInst, CP_WINANSI); // hszNew ≠ hszInst !

.. .

Під час повернення деякого значення функцией.

зворотного виклику ідентифікатор рядки псується. В.

додатку можна зберегти ідентифікатор з допомогою функції DdeKeepStringHandle і використовувати цей ідентифікатор після виклику функції CallBack.

Коли додаток викликає функцию.

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

Якщо додаток намагається визначити рядок, яка вже є в таблиці, система просто збільшує її кількість використання, а при виклик функції DdeFreeStringHandle, відповідно зменшує на 1. Рядок видаляється з таблиці, коли її кількість використання одно 0. Service імена. Реєстрація, фильтр.

DDEML дозволяє реєструвати service імена для серверу та не посилати транзакцію виду XTYP-CONNECT для неподдрерживаемых service імен із функцію зворотного виклику. Зупинимося під час обговорення цього питання більш подробно.

При реєстрації service імен із DDEML, сервер інформує інші DDE-приложения у системі у тому, що поточний сервер доступний обміну данными.

Сервер реєструє service ім'я шляхом виклику функції DdeNameService і вказує ідентифікатор рядки, що з именем.

З отриманням вищевказаних даних DDEML посилає транзакцію виду XTYP-REGISTER до функцій зворотного виклику кожного DDEML-приложения у системі (крім лише про тих, які вказали прапор фільтрації GBF_SKIP_REGISTRATION до функцій DdeInitialize).

Транзакція XTYP_REGISTER передає два.

ідентифікатора рядків функцію зворотного виклику: перший из.

них свідчить про основне service ім'я, а другий — на.

рядок, що містить системну информацию.

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

Сервер може використовувати функцію DdeNameServise у тому, щоб скинути реєстрацію service імені. Це оэначает, що DDEML необхідно послати транзакцію виду XTYP_UNREGISTER в DDE-приложения з туристичною інформацією у тому, що вони большє нє зможуть використовувати дане service ім'я задля встановлення диалога.

Сервер повинен викликати функцію DdeNameServise для його service імені відразу після виклику функції DdeInitialize. Сервер повинен скидати своє service ім'я відразу після виклику функції DdeUninitialize. Крім реєстрації service імені функція DdeNameService поэволяет включати чи вимикати серверу її власний фільтр service имени.

Коли сервер виключає фільтр, DDEML посилає транзакцію виду XTYP_CONNECT до функцій зворотного виклику серверу незалежно від цього збігаються чи викликаного service ім'я з зареєстрованим чи ні при вызыве клієнтом функції DdeConnect. Коли сервер включає фільтр, транзакція виду XTYP_CONNECT посилається лише тому випадку, коли викликаного service ім'я збігаються з зарегистрированным.

За умовчанням, фільтр включений буде лише тоді, коли додаток викликає функцію DdeInitialize. Це необхідне запобігання генерації транзакції XTYP_CONNECT перш ніж створено необхідні ідентифікатори рядків. Сервер може вимкнути фільтр шляхом установки прапора DNS_FILTEROFF при виклик функції DdeNameService. Прапор DNS_FILTERON включає фільтр.

Діалог між приложениями.

Діалог між клієнтом і сервером всегда.

встановлюється на вимогу клієнта. Коли диалог.

встановлено, обидва партнера отримують ідентифікатор, который.

описує даний диалог.

Партнери використовують цей ідентифікатор в.

більшості функцій 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 при виклик відповідної функции).

У нижеприведенном прикладі виробляється попытка.

встановити діалог із сервером, який у змозі працювати з service ім'ям «My Server «в системному режимі. Вважаємо, що параметри hszSysTopic і hszServName вже попередньо створено нами ранее.

HCONV hConv;

HWND hwndParent;

HSZ hszServName;

HSZ hszSysTopic;

.. .

hConv = DdeConnect (.

idInst, // Копія приложения.

hszServName, // Ідентифікатор service-имени.

handle hszSysTopic, // Ідентифікатор system-topic-имени (PCONVCONTEXT) NULL); // Використовуємо контекст по умолчанию.

if (hConv == NULL).

MessageBox (hwndParent, «MyServer НЕ доступний! » ,.

(LPSTR) NULL, MB_OK);

return FALSE;

.. .

У цьому вся прикладі функція DdeConnect змушує DDEML посилати транзакцію виду XTYP_CONNECT до функцій зворотного виклику серверу MyServer.

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

#define CTOPICS 5.

HSZ hsz1; // Ідентифікатор строки,.

отриманий DDEML.

HSZ ahszTopics[CTOPICS]; // Масив поддреживаемых topic імен int і; // Лічильник циклу.

.

. // Для обробки транзакцій використовуємо стандартну ANSI З. // конструкцію switch —> case —> default.

.

case XTYP_CONNECT:

for (і = 0; і < CTOPICS; i++)>

if (hsz1 == ahszTopics[i]).

return TRUE; // Установка диалога.

return FALSE; // Topic ім'я НЕ підтримується, діалог запрещен.

.

. // Обробка інших типів транзакций.

.

Якщо сервер повертає 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 (винятки складають лише ті сервери, які за ініціалізації встановили фільтр обробки транзакций).

Продемонстируем використання транзакції вида.

XTYP_CONNECT.

#define CTOPICS 2.

UINT uType;

HSZPAIR ahszp[(CTOPICS + 1)];

HSZ ahszTopicList[CTOPICS];

HSZ hszServ, hszTopic;

WORD і, j;

if (uType == XTYP_WILDCONNECT).

// Сканируем список topic імен та створюємо массив.

// структур типу HSZPAIR.

j = 0;

for (і = 0; і < CTOPICS; i++)>

if (hszTopic == (HSZ) NULL ||.

hszTopic == ahszTopicList[i]).

ahszp[j]. hszSvc = hszServ;

ahszp[j++]. hszTopic = ahszTopicList[i];

// Останній елемент масиву завжди NULL.

ahszp[j]. hszSvc = NULL;

ahszp[j++]. hszTopic = NULL;

// Повертаємо дискриптор глобального об'єкта памяти,.

// у якому структури типу HSZPAIR.

return DdeCreateDataHandle (.

idInst, // Копія приложения.

(LPBYTE) &ahszp, // Покажчик на масив типу HSZPAIR.

sizeof (HSZ) * j, // Довжина массива.

0, // Початкова смещение.

(HSZ) NULL, // item-имя не существует.

0, // формат item-имени также.

// не существует.

0); // Покладаємо все работу.

// з масивом на систему.

Будь-який сервер чи клієнт може обірвати діалог у час шляхом виклику функції 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 інформацією щодо диалоге.

Клієнт може зберегти отримані ідентифікатори діалогів і відмовитися від перегляду решти серверів в списке.

Наведемо досвід використання функции.

DdeConnectList задля встановлення діалогу з всеми.

серверами, які підтримують ім'я «system topic », затем.

використовуватимемо функції DdeQueryConvInfo и.

DdeQueryNextServer щоб одержати їх идентификаторов.

service імен, одночасно не забуваючи зберегти последние.

в часі буфере.

HCONVLIST hconvList; // Список диалогов.

DWORD idInst; // Дискриптор приложения.

HSZ hszSystem; // System topic.

HCONV hconv = NULL; // Ідентифікатор диалога.

CONVINFO ci; // Інформації про диалоге.

UINT cConv = 0; // Кількість ідентифікаторів диалогов.

HSZ *pHsz, *aHsz; // Покажчик на ідентифікатор строки.

// Приєднуємося всім серверам, поддерживающим.

// System topic.

hconvList = DdeConnectList (idInst, NULL, hszSystem,.

NULL, NULL);

// Обчислюємо кількість серверів в списке.

while ((hconv = DdeQueryNextServer (hconvList, hconv)) ≠ NULL).

cConv++;

// Виділяємо буфер задля збереження ідентифікаторів строк.

hconv = NULL;

aHsz = (HSZ *) LocalAlloc (LMEM_FIXED, cConv * sizeof (HSZ));

// Копіюємо ідентифікатор рядки у буфер.

pHsz = aHsz;

while ((hconv = DdeQueryNextServer (hconvList, hconv)) ≠ NULL).

DdeQueryConvInfo (hconv, QID_SYNC, (PCONVINFO) &ci);

DdeKeepStringHandle (idInst, ci. hszSvcPartner);

*pHsz++ = ci. hszSvcPartner;

.

. // Використовуємо ідентифікатор: «спілкуємося «з сервером.

.

// Звільняємо пам’ять і припиняємо диалог.

LocalFree ((HANDLE) aHsz);

DdeDisconnectList (hconvList);

Додаток може обірвати індивідуальний діалог, що у списку діалогів шляхом виклику функції DdeDisconnect; додаток може обірвати все діалоги, перебувають у списку шляхом виклику функції DdeDisconnectList.

Обидві вищевказані функції вказують DDEML о.

необхідності посилки транзакції виду XTYP_DISCONNECT во.

всі функції партнерів у діалогу даного докладання (в.

разі використання функції DdeDisconnectList будет.

посилатися транзакція XTYP_DISCONNECT кожному за элемента.

у списку діалогів).

Обмін даними між приложениями.

Оскільки DDE використовує області пам’яті передачі даних із одного докладання до іншого, DDEML забезпечує кінцевого програміста функціями, з яких DDE-приложения можуть створювати й обробляти DDE-объекты.

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

Ця функція створює DDE-объект, копіює дані з буфера у цей об'єкт і повертає ідентифікатор даних для.

даного приложения.

Ідентифікатор данных-это подвійне слово, яке використовує DDEML задля забезпечення доступу до даних в DDE-объекте.

А, щоб розділяти дані в DDE-объекте, додаток передає ідентифікатор даних DDEML, та був DDEML передає їх у функцію зворотного виклику докладання, отримує данные.

У нижеприведенном прикладі показано, як створити DDE-объект і її ідентифікатор. У процесі обробки транзакції типу XTYP_ADVREQ, функція зворотного виклику конвертує час в ASCII рядок, копіює рядок в допоміжний буфер, та був створює DDE-объект, у якому вищевказану рядок. Функція зворотного виклику повертає ідентифікатор DDE-объекта DDEML, яка передає цей ідентифікатор клієнтському приложению.

typedef struct tagTIME.

INT hour; // 0 — 11 формат часу для часов.

INT hour12; // 12-ой формат.

INT hour24; // 24-ой формат.

INT minute;

INT second;

INT ampm; // 0 —> AM, 1 —> PM.

TIME;

HDDEDATA EXPENTRY DdeCallback.

(uType, uFmt, hconv, hsz1, hsz2, hdata, dwData1, dwData2).

UINT uType;

UINT uFmt;

HCONV hconv;

HSZ hsz1;

HSZ hsz2;

HDDEDATA hdata;

DWORD dwData1;

DWORD dwData2;

CHAR szBuf[32];

switch (uType).

case XTYP_ADVREQ:

case XTYP_REQUEST:

if ((hsz1 == hszTime && hsz2 == hszNow) &&.

(uFmt == CF_TEXT)).

// Копіюємо рядок в буфер.

itoa (tmTime.hour, szBuf, 10);

lstrcat (szBuf, «: »);

if (tmTime.minute < 10)>

lstrcat (szBuf, «0 »);

itoa (tmTime.minute, &szBuf[lstrlen (szBuf)], 10);

lstrcat (szBuf, «: »);

if (tmTime.second < 10)>

strcat (szBuf, «0 »);

itoa (tmTime.second, &szBuf[lstrlen (szBuf)], 10);

szBuf[lstrlen (szBuf)] = «.