Megatutorial 3.1 - Aplikacje okienkowe.pdf - WinAPI - mrozek2002

APLIKACJE OKIENKOWE

Wyobraź sobie, że gdy w każdy czwartek

zwyczajnie zawiązujesz sobie buty, one eksplodują.

Coś takiego cały czas dzieje się z komputerami

i jakoś nikt na to nie narzeka.

Jeff Raskin, wywiad dla „Doctor Dobb’s Journal”

Pierwsze komputery osobiste powstały już całkiem dawno temu, bo przy końcu lat

siedemdziesiątych ubiegłego stulecia. Prawie od samego początku mogły też wykonywać

całkiem współczesne operacje - z edycją dokumentów czy wykorzystaniem sieci włącznie.

A jednak dopiero ostatnia dekada przyczyniła się do niezmiernego upowszechnienia

pecetów, a umiejętność ich obsługi stała się powszechna i konieczna. Przyczyn można

upatrywać się w szybkim rozwoju Internetu, jednak trudno sobie wyobrazić jego

ekspansję oraz rozpowszechnienie samych komputerów, gdyby ich użytkowanie nie było

proste i intuicyjne. Bez łatwych metod komunikacji z programami początkujący

użytkownik byłby bowiem zawsze w trudnej sytuacji.

Po licznych „bojach” stoczonych z konsolą możemy z pewnością stwierdzić, że interfejs

tekstowy niekiedy bywa wygodny. Faktycznie oferuje go każdy system operacyjny, a za

jego pomocą często można szybciej i efektywniej wykonywać rutynowe zadania -

szczególnie, kiedy mamy już pewne doświadczenie w obsłudze danego systemu.

Nie da się jednak ukryć, że całkowity nowicjusz, posadzony przez ekranem z migającym

tajemniczo kursorem, może poczuć się, delikatnie mówiąc, lekko zdezorientowany.

Naturalnie mógłby on zajrzeć do stosownych dokumentacji czy też innych źródeł

niezbędnych wiadomości, lecz procent użytkowników, którzy rzeczywiście tak czynią,

oscyluje chyba gdzieś w granicach błędu statystycznego (jeśli ktokolwiek przeprowadzał

kiedykolwiek takie badania) :D Czy to jest jednak tylko ich problem?…

Otóż nie, a właściwie - już nie. Oto bowiem w latach osiemdziesiątych wymyślono nowe

sposoby dialogu aplikacji z użytkownikiem, z których najlepszy (dla użytkownika) okazał

się interfejs graficzny . Prawdopodobnie zadecydowały tu proste analogie w stosunku

do znanych urządzeń, które regulowało się najczęściej przy pomocy różnych przycisków,

pokręteł, suwaków czy włączników. Koncepcje te dały się łatwo przenieść w świat

wirtualny i znacznie rozszerzyć, dając w efekcie obecny wygląd interfejsu użytkownika w

większości popularnych programów.

Graficzny interfejs użytkownika (ang. graphical user interface - w skrócie GUI) to

sposób wymiany informacji między programem a użytkownikiem, oparty na wyświetlaniu

interaktywnej grafiki i reakcji na działania, jakie są podejmowane w stosunku do niej.

Istnieje wiele powodów, dla których ten rodzaj interfejsu jest generalnie łatwiejszy w

obsłudzie niż rozwiązania oparte na tekście. Nietrudno znaleźć te powody, gdy

porównamy jakąś aplikację konsolową i program wykorzystujący interfejs graficzny.

Warto jednak wymienić te przyczyny - najlepiej w kolejności rosnącego znaczenia:

¾ program konsolowy jest często dla użytkownika „czarną skrzynką” (żeby nie

powiedzieć - czarną magią ;D). O jego przeznaczeniu czy oferowanych przezeń

funkcjach rzadko może się bowiem dowiedzieć z informacji prezentowanych mu na

326

ekranie. Są one zwykle tylko wynikami pracy programu lub też prośbami o

wprowadzenie potrzebnych danych.

Tymczasem w programach o interfejsie graficznym konieczne są przynajmniej

szczątkowe opisy poszczególnych opcji i funkcji, a to samo w sobie daje pewne

wskazówki co do prawidłowej obsługi programu.

Nic więc dziwnego, że wielu użytkowników programów uczy się ich obsługi metodą prób i

błędów, czyli kolejnego wypróbowywania oferowanych przez nie opcji i obserwacji

efektów tych działań.

¾ elementy interfejsów graficznych są bardziej „namacalne” niż tekstowe polecenia,

wpisywane z klawiatury. Łatwiej domyślić się, jak działa przycisk, suwak czy pole

tekstowe - czego nie można powiedzieć o komendach konsolowych.

Można więc stwierdzić, że występuje tu podobny efekt jak w przypadku

programowania obiektowego. Coś, co możemy zobaczyć/wyobrazić sobie, jest po

prostu łatwiejsze do przyswojenia niż abstrakcyjne koncepcje.

Screen 44. Nawet skomplikowany interfejs graficzny może być prostszy w obsłudze niż aplikacja

konsolowa. Kalkulator mógłby oczywiście z powodzeniem działać w trybie tekstowym i oferować

dużą funkcjonalność, np. w postaci obliczania złożonych wyrażeń. Można ją jednak

zaimplementować także w aplikacji z graficznym interfejsem, zaś przyciski i inne elementy okna są

z pewnością bardziej intuicyjne niż choćby lista dostępnych funkcji i operacji matematycznych.

¾ graficzne interfejsy użytkownika dają większą swobodę i kontrolę nad przebiegiem

programu. O ile w aplikacjach konsolowych funkcjonowanie programu opiera się

zazwyczaj na schemacie: pobierz dane Æ pracuj Æ pokaż wynik , o tyle interfejsy

graficzne w większości przypadków zostawiają użytkownikowi olbrzymie pole

manewru, jeżeli chodzi o podejmowane czynności i ich kolejność. Jest to

całkowicie inny model funkcjonowania programu .

GUI jest zatem nie tylko zmianą w powierzchowności aplikacji, ale też fundamentalną

różnicą, jeżeli chodzi o jej działanie - zarówno od strony użytkownika, jak i programisty.

Tworzenie programów z interaktywnym interfejsem przebiega więc inaczej niż kodowanie

aplikacji konsolowych, działających sekwencyjnie.

Ta druga czynność jest nam już doskonale znana, teraz więc przyszła pora na poznanie

metod tworzenia aplikacji działających w środowiskach graficznych i wykorzystujących

elementy GUI.

327

Posiadanie graficznego interfejsu nie oznacza aczkolwiek, że dany program jest w pełni

interaktywny. Wiele z aplikacji niewątpliwie graficznych, np. kreatory instalacji, są w

rzeczywistości programami sekwencyjnymi. Jednocześnie możliwe jest osiągnięcie

interaktywności w środowisku tekstowym, czego najlepszym przykładem jest chyba

popularny w czasach DOSa menedżer plików Norton Commander.

Obecnie jednak aplikacje wyposaża się w graficzny interfejs właśnie po to, aby ich

obsługa była interaktywna i możliwa na dowolne sposoby. Na tym opierają się dzisiejsze

systemy operacyjne.

Zajmiemy się programowaniem aplikacji okienkowych przeznaczonych dla środowiska

Windows. Pamiętamy oczywiście, że naszym nadrzędnym celem jest poznanie technik

programowania gier; znajomość podstaw tworzenia programów GUI jest jednak

niezbędna, by móc korzystać z biblioteki graficznej DirectX, która przecież działa w

graficznym środowisku Windows. Umiejętność posługiwania się narzędziami, jakie ten

system oferuje, powinna też zaprocentować w bliższej lub dalszej przyszłości i z

pewnością okaże się pomocna.

A zatem - zaczynajmy programowanie w Windows!

Wprowadzenie do programowania Windows

Pisanie programów działających w podsystemie GUI w Windows różni się zasadniczo od

tworzenia aplikacji konsolowych. Wynika to nie tylko z nowych narzędzi

programistycznych, jakie należy do tego wykorzystać, ale także, czy może przede

wszystkim, z innego modelu funkcjonowania programów okienkowych. Wymaga to nieco

innego podejścia do kodowania, myślę jednak, że jest ono nawet łatwiejsze i bardziej

sensowne niż dla konsoli.

Na początek naszej przygody z programowaniem Windows poznamy więc ów nowy model

działania aplikacji. Później zobaczymy również, jakie instrumenty wspomagające

kodowanie oferuje ten system operacyjny.

Programowanie sterowane zdarzeniami

Elastyczność, jaką wykazują programy z interfejsem graficznym, w zakresie kontroli ich

działania przez użytkownika jest niezwykle duża. Można w zasadzie stwierdzić, że dopiero

takie aplikacje stają się przydatnymi narzędziami, posłusznymi swoim użytkownikom. Nie

narzucają żadnych ścisłych wymogów co do sposobu obsługi, pozostawiając duże pole

swobody i ergonomii.

Osiągnięcie takich efektów przy pomocy znanych nam technik programowania byłoby

bardzo trudne, a na pewno naciągane - jeżeli nie niemożliwe. Graficzny interfejs aplikacji

okienkowych wymaga bowiem zupełnie nowego sposobu kodowania: programowania

sterowanego zdarzeniami .

Modele działania programów

Aby dokładnie zrozumieć tę ideę i móc niedługo stosować ją w praktyce, potrzebne są

rzecz jasna stosowne wyjaśnienia. Przede wszystkim chciałoby się wiedzieć, na czym

polegają różnice w tym sposobie programowania, gdy przyrównamy go do znanego

dotychczas sekwencyjnego uruchamiania kodu. Nie od rzeczy byłoby także wskazanie

zalet nowego modelu działania aplikacji. To właśnie uczynimy teraz.

Najpierw należałoby więc sprecyzować, co rozumiemy pod pojęciem modelu działania

programu, gdyż stosowaliśmy ten termin już kilkakrotnie i najwyraźniej wydaje się on tu

kluczowy. Mianowicie możemy powiedzieć krótko:

328

Model funkcjonowania aplikacji (ang. application behavior model ) to, najogólniej

mówiąc, pozycja, jaką zajmuje program w stosunku do użytkownika oraz do systemu

operacyjnego. Określa on sposób, w jaki kod programu steruje jego działaniem, głównie

wprowadzaniem danych wejściowych i wyprowadzaniem wyjściowych.

Wyjaśnienie to może wydawać się dosyć mgliste, ponieważ pojęcie modelu

funkcjonowania aplikacji jest jedną z najbardziej fundamentalnych spraw w

projektowaniu, kodowaniu, jak również w użytkowaniu wszystkich bez wyjątku

programów. Jednocześnie trudno je rozpatrywać całkiem ogólnie, tak jak tutaj, i dlatego

zwykle się tego nie robi; niemniej jednak jest to bardzo ważny aspekt programowania.

Najczęściej wszakże mówi się jedynie o odmianach modelu działania aplikacji, a zatem

także i my je poznamy. Nie są one zresztą całkiem dla nas obce, a nawet nowopoznane

koncepcje wydadzą się, jak sądzę, dosyć logiczne i rozsądne.

Przyjrzyjmy się więc poszczególnym modelom.

Model sekwencyjny

Najstarszym i najwcześniej przez nas spotkanym w nauce programowania modelem jest

model sekwencyjny . Był to w początkach rozwoju komputerów najbardziej oczywisty

sposób, w jaki mogły działać ówczesne programy.

Ogólnym założeniem tego modelu jest ustawienie programu w pozycji dialogu z

użytkownikiem. Taki dialog nie jest oczywiście normalną konwersacją, jako że komputery

nigdy nie były, nie są i nie będą ani trochę inteligentne. Dlatego też przyjmuje ona formę

wywiadu , któremu poddawany jest użytkownik.

Aplikacja zatem „zadaje pytania” i oczekuje na nie odpowiedzi w postaci potrzebnych

sobie danych. Prezentuje też wyniki swojej pracy do wglądu użytkownika.

Schemat 36. Sekwencyjny model działania programu. Aplikacja zajmuje tu miejsce nadrzędne w

stosunku do użytkownika (stąd jej wielkość na diagramie :D), a system operacyjny jest

pośrednikiem w wymianie informacji (zaobrazowanej strzałkami).

Najważniejsze, że cały przebieg pracy programu jest kontrolowany przez programistę. To

on ustala, kiedy należy odczytać dane z klawiatury, wyświetlić coś na ekranie czy

wykonać inne akcje. Wszystko ma tu swój określony porządek i kolejność, na którą

użytkownik nie ma wpływu . Właśnie ze względu na ową kolejność model ten

nazywamy sekwencyjnym.

Najlepszym przykładem aplikacji, które działają w ten sposób, będą wszystkie napisane

dotychczas w tym kursie programy konsolowe; w ogólności tyczy się to w zasadzie

każdego programu konsolowego. Sama natura tego środowiska wymusza pobieranie oraz

pokazywanie informacji w pewnej kolejności, niepozwalającej użytkownikowi na większą

swobodę.

329

Do tej grupy możemy też zaliczyć bliższe nam aplikacje, funkcjonujące jako kreatory

(ang. wizards ), z kreatorami instalacji na czele. Posiadają one wprawdzie interfejs

graficzny, ale sposób i porządek ich działania jest ściśle ustalony. Obrazują to nawet

kolejne kroki - ekrany, które po kolei pokonuje użytkownik, podając dane i obserwując

efekty swoich działań.

Screen 45. Kreatory instalacji (ang. setup wizards ) są przykładami programów działających

sekwencyjnie. Zawierają wprawdzie elementy interfejsu graficznego właściwe innym aplikacjom,

ale ich działanie jest precyzyjnie ustalone i podzielone na kroki, które należy pokonywać w

określonej kolejności.

Poza wspomnianymi kreatorami (które zazwyczaj są tylko częścią większych aplikacji),

programy działające sekwencyjnie nie występują zbyt licznie i nie mają poważniejszych

zastosowań. Ich niewrażliwość na intencje użytkownika i zatwardziałe trzymanie się

ustalonych schematów funkcjonowania sprawiają, że nie można przy ich pomocy

swobodnie wykonywać swoich zajęć.

Model zdarzeniowy

Zupełnie inne podejście jest prezentowane w modelu zdarzeniowym , zwanym też

programowaniem sterowanym zdarzeniami (ang. event-driven programming ).

Model ten opiera się na całkiem odmiennych zasadach niż model sekwencyjny, oferując

dzięki nim nieporównywalnie większą elastyczność działania.

Podstawową wytyczną jest tu zmiana roli programu. Nie jest on już ciągiem kolejno

podejmowanych kroków, które składają się na wykonywaną przezeń czynność, ale raczej

czymś w rodzaju witryny sklepowej, z której użytkownik może wybierać pożądane w

danej chwili funkcje.

Dlatego też działanie programu polega na odpowiedniej reakcji na występujące

zdarzenia (ang. events ). Tymi zdarzeniami mogą być na przykład wciśnięcia klawiszy,

ruch myszy, zmiana rozmiaru okna, uzyskanie połączenia sieciowego i jeszcze wiele

innych. Program może być informowany o tych zdarzeniach i reagować na nie we

właściwy sobie sposób.

Megatutorial 3.1 - Aplikacje okienkowe.pdf

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: