Programowanie w języku C++ z użyciem Windows API

Programowanie w języku C++ z użyciem Windows API Autor: Mateusz Ferenc Data opracowania: 30 maja 2012 r. Windows API jest jedną z bibliotek programistycznych przeznaczonych do pisania programów na platformę Windows. API (Application Programming Interface ang. interfejs programowania aplikacji), ogólnie definiując, jest kompilacją podprogramów i struktur danych, które są powiązane z pewnym wytworem. Tym wytworem może być m.in. system, a ostatnio tworzy się API także dla serwisów internetowych, np. dla serwisu społecznościowego Google+. Wspomniany zestaw został stworzony przez firmę Microsoft. Windows API jest częścią systemu Windows począwszy od pierwszej wersji tego systemu. Mimo dużego wieku biblioteka jest do dzisiaj używana i rozwijana. Istnieje klika wersji Windows API i jest ona zależna od architektury systemu Windows, np. na 32-bitowych systemach Windows dołączany jest zestaw Win32 API, natomiast na 64-bitowych Win64 API. Windows API zawiera w sobie interfejsy, które tworzą jedną całość. Można je podzielić na osiem kategorii. Base services (ang. podstawowe usługi) zawierają funkcje zarządzania systemami plików, wątkami, procesami i błędami. Advanced services (ang. zaawansowane usługi) mają w sobie podprogramy, dzięki którym programista zyskuje możliwości edycji rejestru systemowego, tworzenia, uruchamiania i zatrzymywania usług oraz zarządzania kontami użytkowników w systemie. Graphics Device Interface (GD; ang. interfejs graficznego urządzenia) posiada funkcje rysowania na monitorach, drukarkach i innych urządzeniach wyjścia. User interface (ang. interfejs użytkownika) posiada funkcjonalność tworzenia tego, z czym użytkownik będzie miał kontakt przy pracy z aplikacją opartą o Windows API. Tymi elementami są okna oraz różnego podstawowe kontrolki, które można na tym oknie umieścić, np. przyciski czy pola edycji. Common Dialog Box Library (ang. biblioteka wspólnych okien dialogowych) w bibliotece tej zaimplementowano funkcjonalność podstawowych okien dialogowych takich jak okna otwierania i zapisywania plików, wyboru koloru i czcionki, drukowania itd. Common Control Library (ang. biblioteka wspólnych kontrolek) zawiera rozszerzone kontrolki, do których zaliczają się panel z zakładkami oraz paski stanu, postępu i narzędzi. Windows Shell (ang. powłoka systemu Windows) pozwala na dostęp do zasobów powłoki systemu Windows takich jak np. pasek zadań. Network Services (ang. usługi sieciowe) posiada komponenty do tworzenia aplikacji z wykorzystaniem komunikacji sieciowej. Najbardziej znanym jest Winsock (skr. Windows Socket API ang. gniazdo Windows API). Aby rozpocząć pisanie programu z użyciem Windows API, należy dołączyć do kodu plik nagłówkowy <Windows.h>. Plik ten zawiera w sobie odwołania do innych plików nagłówkowych, np. do pliku <WinDef.h>, który przechowuje struktury danych ułatwiające programowanie. Dzięki temu nic więcej nie trzeba dołączać do projektu aplikacji, by móc zacząć korzystać z biblioteki (choć oczywiście istnieje możliwość dołączenia pozostałych plików nagłówkowych bez użycia głównego, jakim jest <Windows.h>). Główną funkcją aplikacji opartych o Windows API jest funkcja WinMain. Ponieważ od niej zaczyna się działanie programu, wywołuje ją system. Jej nagłówek wygląda następująco: 1

int WINAPI WinMain( HINSTANCE hinstance, HINSTANCE hprevinstance, LPSTR lpszcmdline, int ncmdshow); Zwracaną wartością przez tę funkcję jest liczba całkowita ze znakiem. Można zwrócić własną wartość, ale z reguły używa się do tego tzw. kodu wyjścia. Kod wyjścia to wartość liczbowa mówiąca o stanie zakończenia działania programu. Jeśli kod wyjścia jest równy zeru, oznacza to, że wyjście z aplikacji zostało zakończone sukcesem, w innym przypadku jest to błędne wyjście z programu. W takim przypadku należy zajrzeć do dokumentacji Windows API, aby dowiedzieć się, co oznacza dany kod. Szczegóły jego otrzymywania znajdują się pod koniec tego sprawozdania. WINAPI jest to alias słowa kluczowego stdcall (standard call ang. standardowe wywołanie), które jest tzw. konwencją wywołania. Konwencją nazywamy sposób wywołania funkcji, która dostarcza informacje m.in. na temat sposobu przekazywania parametrów przez funkcję. Wytwór ten zawiera także adres podprogramu, który wywołał daną funkcję, dzięki czemu wiadomo, gdzie ma się odbywać dalsze działanie programu po zakończeniu wykonania się tej funkcji. W przypadku stdcall konwencja ta domyślnie przekazuje argumenty funkcji poprzez wartość, a nie przez referencję. Pierwszym parametrem funkcji jest zmienna hinstance typu HINSTANCE. Typ HINSTANCE jest uchwytem do aplikacji. Uchwyt to po prostu jakiś numer, który jest przyporządkowywany przez system. Na tej podstawie wie on, z jakim elementem ma do czynienia i jakiego jest on typu. Pierwsza litera H jest skrótem od angielskiego słowa handle, które po polsku oznacza właśnie uchwyt. Istnieje wiele typów uchwytu, a każdy z nich to tak naprawdę wskaźnik na strukturę o tej samej nazwie zakończona dodatkowo dwiema dolnymi spacjami. Struktura ta zawiera tylko jedno pole unused, które jest typu int. Uchwyty są tworzone za pomocą specjalnego makra nazwanego DECLARE_HANDLE. Jego definicja prezentuje się następująco: #define DECLARE_HANDLE(name) struct name## {int unused;}; \ typedef struct name## *name Pole unused jest używane wyłącznie przez system do swoich celów i programista nie powinien jego używać. Dwa znaki # oznaczają, że nazwa (tutaj name) ma zostać potraktowana jako typ elementu. Ostatni wyraz name nie zawiera już tych znaków, gdyż jest to już nazwa zmiennej, a nie typ. Dyrektywa #define nie rozumie znaków kończących wiersz. Aby oznajmić jemu, że dalsza definicja makra znajduje się w następnej linii, należy użyć znaku backslash. Biorąc za przykład uchwyt do aplikacji (HINSTANCE), makro DECLARE_HANDLE wygląda tak: DECLARE_HANDLE(HINSTANCE); Zarówno makro DECLARE_HANDLE, jak i wszystkie zadeklarowane za jego pomocą uchwyty znajdują się w pliku nagłówkowym <WinNT.h>, którego odwołanie zawiera również plik <Windows.h>. Innymi znanymi uchwytami to m.in.: uchwyt do okna (typ HWND) za jego pomocą tworzy się okna, 2

uchwyt do pędzla (HBRUSH) służy zazwyczaj do zamalowania obszaru roboczego okna na określony kolor, za pomocą desenia lub bitmapy, uchwyt do kursora (HCURSOR) z reguły ustala on, jak ma wyglądać kursor nad obszarem roboczym okna, uchwyt do ikony (HICON) tym uchwytem ustawia się ikonę dla okna, która będzie wyświetlona na pasku tytułowym okna. Uchwyt do aplikacji stosuje się podczas tworzenia klasy i uchwytu okna. Te procesy zostaną omówione w dalszej części sprawozdania. Można go użyć także do pobrania z programu tzw. zasobów. Do projektu aplikacji programista najczęściej dodaje pliki nagłówkowe (o rozszerzeniu h), a także pliki z listingiem (w formacie cpp). Nie są to jedyne pliki, które można umieścić w projekcie. Można także dodać do niego standardowe dane takie jak pliki muzyczne, filmowe, tekstowe, graficzne itp. Te informacje nazywane są zasobami. Zaletą rozwiązania zasobów jest fakt, że przy utworzeniu pliku wykonywalnego aplikacji nie trzeba przechowywać tych zasobów w postaci odrębnych plików, gdyż program będzie korzystał po prostu ze swoich wbudowanych. Wadą natomiast jest zwiększony rozmiar pliku wynikowego uzyskanego za pomocą kompilacji. Następny parametr jest również uchwytem do aplikacji. hprevinstance określa uchwyt do poprzedniej realizacji aplikacji. Jeśli użytkownik uruchomi kilka razy aplikację, to ten parametr będzie określał uchwyt do poprzednio uruchomionej kopii programu (pod warunkiem, że działanie kopii nie zostało zakończone, w przeciwnym wypadku wartość tego parametru będzie równa zeru). Taką kopię nazywamy instancją, stąd nazwa typu HINSTANCE. Aby uzyskać uchwyt do aktualnej instancji, wystarczy się posłużyć pierwszym parametrem głównej funkcji. Ponieważ ten parametr był wykorzystywany jedynie w systemach wspierających 16-bitową architekturę, obecnie przybiera zawsze wartość zerową. Za pomocą tego parametru można było m.in. pobrać dane z poprzedniej kopii programu np. informacje o uchwycie jakiegoś okna. Do parametru lpszcmdline można dostarczyć własny łańcuch znaków, natomiast ostatni parametr, czyli ncmdshow, określa sposób wyświetlania okien w aplikacji. Nie oznacza on jednak, że wszystkie utworzone okna w danym programie będą wyświetlane w sposób, jaki nakazuje ta zmienna. Jest to parametr opcjonalny tak samo jak parametr lpszcmdline, więc użycie ostatniej zmiennej zależy wyłącznie od woli osoby piszącej program. Sposób wyświetlania okna ustala się przy użyciu flag zdefiniowanych przez autorów Windows API. Najczęściej tworzonym uchwytem przez programisty będzie uchwyt do okna. Za jego pomocą można określić sposób komunikacji programu z użytkownikiem oraz jak ma te okno reagować na zdarzenia takie jak naciśnięcie klawisza na klawiaturze czy przycisku na myszce. Proces tworzenia tego uchwytu składa się z czterech etapów. 1. Tworzenie klasy okna Klasa okna to tak naprawdę struktura. Przyjęło się ją nazywać klasą ze względu na jej nazwę (WNDCLASSEX). Każde okno jest tworzone w oparciu o jego klasę. Ustala ona początkowe własności dla okna, jeśli będzie ono oparte o daną klasę. Jedna klasa okna może być bazą dla więcej niż jednego okna. Na tym etapie programista może ustalić ikonę dla okna, jak ma wyglądać kursor na jego obszarze roboczym, a także przeznaczyć dodatkowe bajty dla klasy okna i okien bazujących o klasę (na własne potrzeby). Warunkiem przyznania tej przestrzeni jest użycie jedynie liczb całkowitych bez znaku (wartości typu unsigned int) jako dodatkowych informacji, czyli liczba bajtów musi być wielokrotnością liczby 4. Przy tworzeniu bazy trzeba także podać uchwyt do aplikacji, która będzie właścicielem danej klasy. 2. Rejestracja klasy okna System w swoich specjalnych strukturach przechowuje informację o tym, które klasy mogą 3

być używane jako bazowe dla innych okien. Takie klasy nazywane są zarejestrowanymi. Klasy okna, które nie zostaną zarejestrowane, nie mogą służyć jako bazy dla innych okien. Aby je poddać procesowi rejestracji, należy użyć funkcji RegisterClassEx, której nagłówek prezentuje się niżej: ATOM RegisterClassEx (const WNDCLASSEX *lpwcx); Jako parametr funkcji wystarczy podać wskaźnik do klasy okna, która zostanie zarejestrowana. Zwracana wartość jest typu unsigned short i określa liczbę, która jest identyfikatorem dla zarejestrowanej klasy. 3. Tworzenie uchwytu do okna Po zarejestrowaniu klasy okna należy przystąpić do tworzenia uchwytu do okna. Funkcja, która się tym zajmuje, nazywa się CreateWindowEx i zwraca uchwyt do okna w przypadku pomyślnego wykonania się. Tutaj ustala się m.in. bazę dla okna, jego dodatkowe własności (czy ma posiadać pasek tytułowy, czy ma być możliwa zmiana rozmiaru okna, czy ma posiadać przyciski minimalizacji i maksymalizacji itp.), ekranowe współrzędne lewego górnego narożnika okna, jego szerokość i wysokość oraz uchwyt do aplikacji, która będzie właścicielem utworzonego okna. Tworzenie uchwytu może jednak zakończyć się porażką wtedy zwracana wartość jest równa zero. Do niepowodzenia może dojść np. gdy programista chce użyć klasy okna, która nie została zarejestrowana. 4. Zdefiniowanie pętli wiadomości i procedury okna Do każdego okna można wprowadzić interakcję, która będzie przebiegała między użytkownikiem programu a oknem. W tym celu definiuje się tzw. pętlę wiadomości. Pętla ta to zwykła pętla nieskończona, która odbiera wiadomości. Wiadomością nazywa się odpowiedź na jakieś wywołane zdarzenie, np. wiadomość WM_SIZE (WM skr. Window Message ang. wiadomość okna) jest odbierana w przypadku, gdy użytkownik zmieni rozmiar okna. Jak to wygląda w szczegółach? Z każdą aplikacją jest związana tzw. kolejka wiadomości, w której przechowywane są wszystkie zaistniałe zdarzenia w postaci wiadomości. System najpierw umieszcza je wszystkie w swojej kolejce, zwanej systemowej. Jeśli zauważy, że dana wiadomość przynależy do konkretnego programu, wtedy przenosi ją do wspomnianej kolejki aplikacji. Pętla wiadomości za pomocą swoich funkcji zapisuje informacje o wiadomości w specjalnie do tego przeznaczonej strukturze, usuwa ją z kolejki aplikacji i wysyła w postaci tej struktury do tzw. procedury okna dane o zaistniałym zdarzeniu. Owa procedura to nic innego jak funkcja, która przetwarza wiadomość, tzn. wykonuje jej kod napisany przez niezależną osobę i/lub domyślnie utworzony przez autorów biblioteki Windows API. Przetwarzanie odbywa się przez programistę, jeśli ją przechwycił. Standardowo wszystkie wiadomości są przetwarzane przez tzw. domyślną procedurę okna. Przykładowo w domyślnej procedurze wiadomość WM_SIZE jest przetwarzana w taki sposób, że następuje zmiana szerokości i/lub wysokości okna. Przechwycenie to czynność przetwarzania wiadomości przez programistę. Może on dopuścić do przetwarzania wiadomości również przez system, ale w zasadzie się tego nie robi. Za założenie można wziąć, że osoba pisząca program nie jest wyjątkiem od tej reguły. W tym przypadku wykona się tylko kod programisty, a nie systemowa procedura okna. To oznacza ni mniej ni więcej, iż w odpowiedzi na wiadomość WM_SIZE nie nastąpi żadna zmiana rozmiaru okna, chyba że programista umieści odpowiedni kod w obszarze danej wiadomości (tutaj WM_SIZE). Z każdą wiadomością powiązane są dwie dodatkowe dane: pierwsza jest 32-bitową liczbą całkowitą ze znakiem, druga bez znaku. Nie oznacza to jednak, że wszystkie wiadomości używają tych danych. Jeśli któraś z wiadomości nie używa wspomnianych informacji, wtedy jedna z nich lub obie zawsze zawierają wartość zerową, choć czasem wartości zerowe też mogą coś znaczyć aby się dowiedzieć, które wiadomości używa których danych, należy zajrzeć do dokumentacji wytworu Microsoftu. W przypadku wiadomości WM_SIZE dana liczbowa ze znakiem zawiera 4

informacje o nowej szerokości i wysokości obszaru roboczego. Na każdą tę właściwość przypada po 16 bitów taka wartość bitów nazywana jest słowem. Młodsze słowo (czyli pierwsze 16 bitów) zawiera liczbę określającą nową szerokość obszaru roboczego okna, natomiast starsze słowo (czyli następne 16 bitów) nową wysokość. Programista nie musi martwić się o poprawność otrzymania wysokości (ostatni bit jest przeznaczony na znak liczby) system sam wszystko obliczy, tak aby w starszym słowie uzyskać poprawną liczbę. Aby wyodrębnić z osobna każdą wartość, należy użyć makr LOWORD i HIWORD. Służą one odpowiednio do wyciągania pierwszych i ostatnich 16 bitów z 32-bitowej liczby. Oto ich nagłówki: LOWORD(l) HIWORD(h) Jako parametry l i h podaje się liczbę, z której programista chce wyciągnąć potrzebną mu wartość. Jeśli chodzi o dodatkową daną bez znaku, to określa ona stan okna po zmianie jego rozmiaru, np. czy jest zmaksymalizowane. Dostępne wartości, jakie może przybierać ta dana, są zapisane w dokumentacji Windows API. Wiadomością, która mówi o zakończeniu działania programu, jest wiadomość WM_QUIT. Aby ją otrzymać, należy użyć funkcji PostQuitMessage. Nic ona nie zwraca, a jako parametr należy podać wartość, która będzie oznaczała kod wyjścia. W większości przypadków podaje się wartość zerową. Nagłówek funkcji jest zaprezentowany niżej: void PostQuitMessage (int nexitcode); Pętla wiadomości powinna być napisana w taki sposób, aby w reakcji na wiadomość WM_QUIT została przerwana. Z tą wiadomością przychodzi tylko jedna dodatkowa dana jest ona bez znaku. W niej jest przechowywana dokładnie ta sama wartość, jaka została przekazana funkcji PostQuitMessage. Natomiast dana ze znakiem nie jest w ogóle używana i zawsze wynosi zero. Jak już wcześniej było napisane, dane o otrzymanej wiadomości są przechowywane w specjalnej strukturze dokładniej nazywa się ona MSG. Przechowuje ona m.in. identyfikator otrzymanej wiadomości w postaci liczby, a także wspomniane dodatkowe dane. Jeśli programista chce zwrócić do głównej funkcji kod wyjścia, musi użyć pola wparam, które określa dodatkową daną bez znaku. Kończąc, dodatkowa dana ze znakiem została określona za pomocą pola lparam. Bibliografia Literatura Tytuł Visual Studio 2005. Programowanie z Windows API w języku C++ Autor Piotr Besta Rok wydania 2008 Wydawnictwo Helion Internet www.msdn.microsoft.com www.warsztat.gd http://en.wikipedia.org/wiki/windows_api 5