Rozdział 6.
PrzeglÄ…d programowania w MFC


W tym rozdziale:

Zapoznanie się z ogólną koncepcją biblioteki MFC
Cele spełniane przez bibliotekę MFC
Najczęściej wykorzystywane klasy MFC
Hierarchia obiektów MFC
Kiedy nie należy używać MFC


Ten rozdział różni się od innych w książce tym, że nie zawiera żadnego programu demonstracyjnego i bardzo niewiele przykładów kodu. Nie oznacza to, że powinieneś go pominąć i przejść do bardziej "treściwych" rozdziałów. Tematy w nim zawarte stanowią klucz do zrozumienia klas MFC (Microsoft Foundation Classes) i efektywnego ich wykorzystania przy tworzeniu 32-bitowych programów dla Windows.
Powstanie MFC może być uważane za jedno z największych wydarzeń związanych z programowaniem dla Windows. Zanim powstało MFC, programiści aplikacji byli skazani wyłącznie na korzystanie z Windows API. Jeśli zajmowałeś się tworzeniem programów korzystających jedynie z API, z pewnością rozumiesz, jak ogromnego zadania się podjęto. Wyobraź sobie tworzenie instrukcji case rozciągającej się na wiele stron kodu lub ręczne tworzenie okna. W tamtych czasach programowanie Windows w C/C++ było uważane bardziej za czarną magię w jeszcze większym stopniu niż obecnie. Od tamtych czasów powstały dwie konkurencyjne biblioteki klas: MFC oraz OWL (Object Window Library) Borlanda. Choć oba produkty mają swoje mocne i słabe strony, jednak to MFC stało się dominującą biblioteką dla tworzenia aplikacji dla Windows.
W tym rozdziale poznasz strukturę MFC oraz kryjącą się za nią filozofię, mającą wpływ na całą architekturę tej biblioteki. Omówimy także pokrótce hierarchię obiektów, na koniec zaś powiemy parę słów o tym, kiedy należy wykorzystać MFC, a kiedy lepiej jest pozostać przy gołym interfejsie Windows API.
Co to jest MFC?
MFC to skrót nazwy kolekcji klas C++ stworzonych przez Microsoft i nazwanych Microsoft Foundation Classes. MFC dostarcza obiektowo zorientowanego szkieletu, który może zostać wykorzystany przez twórców programów do tworzenia aplikacji Windows. MFC jest zorganizowane jako hierarchia klas C++. Kilka klas wysokiego poziomu zapewnia ogólną funkcjonalność, podczas gdy klasy niższych poziomów implementują bardziej specyficzne zachowanie. Każda z klas niskiego poziomu jest wyprowadzona z klasy wysokiego poziomu, tak więc dziedziczy jej działanie.
Na przykład, klasa cwnd jest klasą wysokiego poziomu implementującą większość funkcji wspólnych dla wszystkich okien. Ta klasa posiada między innymi funkcje dla drukowania tekstu, rysowania grafiki oraz śledzenia ruchów wskaźnika myszy. Klasa csplitterWnd jest wyprowadzona z klasy cwnd i dziedziczy wszystkie funkcje tej klasy. Klasa csplitterWnd implementuje specjalny rodzaj okna, nazywanego oknem dzielonym (ang. splitter window). Okno dzielone to okno podzielone co najmniej na dwie sekcje. Granica pomiędzy sekcjami może być przesuwana przez użytkownika. Tego typu okna są używane między innymi w Eksploratorze Windows przy wyświetlaniu informacji na temat zawartości dysku. Klasa csplitterWnd jest niskopoziomową klasą wyprowadzoną z klasy wysokiego poziomu, cwnd.
MFC dostarcza także innych korzyści. Obsługuje wiele powszechnych zadań związanych z Windows, takich jak obsługa i przekazywanie komunikatów w tle. Zamiast pisać tę samą pętlę obsługi komunikatów w każdej tworzonej przez siebie aplikacji Windows, możesz skorzystać z MFC, które zrobi to za Ciebie, udostępniając Ci łatwe do zrozumienia i wykorzystania funkcje składowe. Jedną z takich funkcji jest OnPaint(), umożliwiająca wstawienie kodu wykonywanego w reakcji na otrzymanie komunikatu odmalowania okna.
Oprócz hierarchii klas MFC dostarcza także modelu tworzenia aplikacji. Ten model nosi nazwę modelu dokument-widok i stanowi metodę takiego projektowania aplikacji, że dane aplikacji są oddzielone od elementów interfejsu użytkownika. Dzięki temu obie części aplikacji mogą działać niezależnie, umożliwiając programiście dokonywanie zmian w jednej części bez konieczności drastycznej przebudowy drugiej.
Potęga MFC
Trudno w kilku słowach opisać siłę i elastyczność modelu typu dokument-widok. Ten model może być używany w dużej części tworzonych aplikacji.
Na przykład, weź pod uwagę procesor tekstów lub aplikację arkusza kalkulacyjnego. Dane zawarte w aplikacji są właśnie dokumentem w modelu dokument-widok. Sposób prezentacji tych danych należy wyłącznie do widoku. Klasa dokumentu posiada funkcje składowe umożliwiające klasie widoku dostęp do danych aplikacji. Dopóki te funkcje nie ulegną zmianie, nie ma potrzeby zmiany interfejsu użytkownika. W rzeczywistości, dokument nie musi być nawet dokumentem procesora tekstów czy arkusza kalkulacyjnego. Mogą nim być równie dobrze rekordy bazy danych lub obrazki w programie graficznym. Dopóki funkcje składowe nie ulegną zmianie, nie ma znaczenia rodzaj używanych informacji. Szczegóły architektury typu dokument-widok zostaną przedstawione w rozdziale 19.
Filozofia MFC
Struktura programowania aplikacji, taka jak MFC, stanowi kolekcję bibliotek udostępniających programiście zestaw usług pomocnych przy tworzeniu aplikacji. Zwykle taka struktura jest zaprojektowana w taki sposób, aby jak najbardziej usprawnić proces tworzenia, a także uprościć trudne lub żmudne zadania programistyczne. W szczególności, MFC zostało zaprojektowane do uproszczenia korzystania z dużych części Windows API. MFC przejęło większość z funkcji API, takich jak zarządzanie oknami, wyjście graficzne czy przekazywanie komunikatów, ujmując je w bardziej przyjazne dla programisty klasy C++, dużo łatwiejsze w użyciu. W wielu przypadkach MFC wykonuje pewne złożone operacje w tle, dzięki czemu programista ma do czynienia z dużo prostszym interfejsem i nie musi się borykać z niektórymi niewdzięcznymi aspektami programowania z użyciem Windows API.
Jednym z celu zespołu tworzącego MFC było dostarczenie użytecznego szkieletu przy zachowaniu jak najmniejszego narzutu. MFC nie miałoby większego zastosowania, jeśli w związku z jego wykorzystaniem aplikacje działałyby dużo mniej wydajnie. Projektanci MFC spróbowali zredukować narzut wnoszony przez bibliotekę w takim stopniu, jak to tylko było możliwe. Ich wysiłki doprowadziły do powstania świetnej architektury, w bardzo niewielkim stopniu zmniejszającej wydajność aplikacji przy jednoczesnym zdjęciu z barków biednego programisty ogromnego ciężaru związanego z bezpośrednim programowaniem interfejsu Windows API.
Stabilność projektu szkieletu można poznać po możliwościach rozszerzania biblioteki. Każdy szkielet programowy wart swej ceny powinien mieć możliwość łatwej rozbudowy. Wiele ze szkieletów C++ opiera się w tym celu na mechanizmach obiektowych samego języka, jednak samo wykorzystanie możliwości języka to nie wszystko. Aby szkielet mógł być naprawdę rozbudowywany, jego wewnętrzne struktury także muszą być dobrze skonstruowane i spójne.
MFC zostało stworzone z wielu klas C++. Niektóre, takie jak Cwnd czy CwinThread, stanowią podstawę dla dużej części całego szkieletu. Te podstawowe klasy zawierają podstawowe funkcje, takie jak otwarcie okna, wymagane przez większość aplikacji Windows. Inne, bardziej wyspecjalizowane klasy, takie jak CSplitterWnd, są wyprowadzone właśnie z klas podstawowych. Klasy pochodne dziedziczą wszystkie właściwości klas nadrzędnych, uzupełniając je o własne, specyficzne dla siebie możliwości. Jako programista Windows możesz skorzystać z możliwości rozbudowy hierarchii klas MFC, tworząc własne klasy, wykonujące specjalistyczne zadania. Hierarchii klas MFC przyjrzymy się za chwilę, w sekcji zatytułowanej "Hierarchia klas MFC".
Zalety płynące z wykorzystania MFC
Obiektowo zorientowana struktura MFC grupuje powiązane ze sobą obszary Windows API w poszczególne klasy i obiekty. Na przykład, klasa cwnd kryje w sobie większość funkcji API związanych z obsługą okien. Jako programista aplikacji nie musisz już pamiętać mnóstwa wywołań API. Wszystko co musisz zrobić to stworzyć nowy egzemplarz obiektu klasy cwnd i wywołać kilka jego funkcji składowych. Listingi 6.1 oraz 6.2 ilustrują różnicę przy tworzeniu okna za pomocą MFC oraz bez MFC.
Listing 6.1. Tworzenie okna bez użycia MFC
int WINAPI WinMain (HINSTANCE hlnstance,
HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow)
static char szAppName[] = "NonMFC" ; HWND hwnd ; MSG msg ; WNDCLASSEK wndclass ;
// Wypełnienie struktury wndclass wymaganymi informacjami.
// Te ustawienia tworzÄ… proste okno bez menu,
// pasków przewijania oraz paska stanu.
wndclass.cbSize = sizeof(wndclass) ;
wndclass.style = CS_HREDRAW | CS_VREDRAW ;
wndclass.IpfnWndProc = WndProc ;
wndclass.cbClsExtra = O ;
wndclass.cbWndExtra = O ;
wndclass.hlnstance = hlnstance ;
wndclass.hlcon = Loadlcon(NULL, IDI_APPLICATION) ;
wndclass.hCursor = LoadCursor(NULL, IDC_ARROW) ;
wndclass.hbrBackground = (HBRUSH)GetStockObject(WHITE_BRUSH)
wndclass.1pszMenuName = NULL ;
wndclass.1pszClassName = szAppName ;
wndclass.hlconSm = Loadlcon(NULL, IDI APPLICATION) ;
RegisterClassEx (Swndclass) ,// nazwa klasy okna

hwnd = CreateWindow (szAppName,// nagłówek okna
"Non-MFC App",// styl okna
WS_OVERLAPPEDWINDOW,// pocz. póz. na osi x
CW_USEDEFAULT,// pocz. póz. na osi y
CW_USEDEFAULT,// pocz. szerokość okna
CW_USEDEFAULT,// pocz. wysokość okna
CW_USEDEFAULT,// uchwyt okna nadrzędnego
NULL,// uchwyt menu okna
NULL,// uchwyt egzemplarza
hlnstance,// programu

NULL) ;// parametry inicjacji okna

// W tym momencie klasa okna została zarejestrowana w systemie // operacyjnym. Stworzono także egzemplarz klasy okna, który // jednak jeszcze nie jest widoczny na ekranie.
// Pokażmy okno i zaktualizujmy je ShowWindow (hwnd, iCmdShow) ; UpdateWindow (hwnd) ;
Programowanie z użyciem "gołego" API wymaga pracy z kilkoma różnymi strukturami danych oraz z czterema różnymi wywołaniami funkcji. W większych projektach brak obiektowego zorientowania API stwarza trudności przy zarządzaniu kodem. Porównaj listing 6.1 z listingiem 6.2.
i
Listing 6.2. Tworzenie okna z -wykorzystaniem MFC
CMyApp myApp;
BOOL CMyApp::Initlnstance() {
m_pMainWnd = new CMainWindow;
m_pMainWnd->ShowWindow(m_nCmdShow) ;
m_pMainWnd->UpdateWindow() ;
return TRUE; }
CMainWindow::CMainWindow() {
CreatetNULL, "MFC App");
W listingu 6.2 klasa CMainWindow jest wyprowadzona z klasy podstawowej cwnd. CMainWindow dziedziczy wszystkie funkcje klasy cwnd, włącznie z implementacją procesu tworzenia okna. Możesz mieć pewność, że gdzieś głęboko wewnątrz MFC zostanie wykonany kod podobny do kodu z listingu 6.1. Ponieważ to MFC wykonuje całą "brudną robotę", Ty nie musisz już sobie "brudzić rąk".
Tak więc, co wolisz pisać? Jeśli weźmiesz pod uwagę, że otwarcie okna jest czynnością dość powszechną i którą będziesz często wykonywał w swojej karierze programisty, zalety MFC stają się coraz wyraźniejsze.
Właściwości, właściwości, właściwości
MFC posiada ogromną ilość właściwości. Najważniejsze z nich to:
Architektura dokument-widok
Interfejs wielodokumentowy (MDI)
Obsługa wydruku i podglądu wydruku
Wykorzystywanie i tworzenie kontrolek ActiveX
Obsługa baz danych ODBC i Access
Wsparcie dla programowania dla Internetu (TCP/IP)
Obsługa standardowych kontrolek Windows 95/Windows 98/Windows NT
Obsługa wielu wątków działania programu
NadajÄ…ca siÄ™ do rozbudowy architektura
Ponieważ MFC jest napisane w C++, możesz skorzystać z mechanizmów tego języka, wyprowadzając własne klasy z klas należących do biblioteki. W ten sposób możesz zaoszczędzić sobie ogromne ilości czasu i energii. Zamiast samodzielnie implementować własne obiekty Windows, możesz oprzeć się na dobrze przetestowanej bazie kodu MFC i dodać jedynie te funkcje, które nie występują w MFC.
Hierarchiczna struktura MFC pozwala na łatwe rozszerzenie szkieletu dla swoich własnych celów. Zawartych jest w niej już kilka specjalistycznych rodzajów okien, takich jak csplitterWnd, implementujących dzielone okna stosowane między innymi w Eksploratorze Windows. MFC zawiera także klasy dla elementów interfejsu użytkownika, takie jak przyciski czy rozwijane listy, a także klasy dla elementów systemu operacyjnego, takich jak wątki lub semafory.
Potrzebujesz klasy reprezentującej specjalne okno dla swojej aplikacji? Żaden problem, po prostu wyprowadź własną klasę z klasy MFC cwnd. Chcesz zaimplementować nowy styl przycisku interfejsu użytkownika? Dalej, wyprowadź swoją klasę przycisku z klasy CButton. Chcesz użyć oddzielnego wątku wykonania dla funkcji w swojej aplikacji? Użyj funkcji MFC AfxBeginThread(). We wszystkich tych przykładach możesz skorzystać z pracy wykonanej już przez kogoś innego, uzupełniając ją o to, co Ci jest potrzebne.
Hierarchia klas MFC
Gdy poznałeś już MFC na wyższym poziomie, przejdźmy głębiej i zajmijmy się hierarchią obiektów tej biblioteki. Hierarchia obiektów MFC przypomina organizację struktury kartotek. MFC posiada główny obiekt, cobject, z którego jest wyprowadzona większość wszystkich pozostałych obiektów. Wewnątrz hierarchii obiekty podobnych typów są pogrupowane według kategorii. Cała biblioteka MFC składa się z ponad stu różnych klas.
Konieczność przeczytania informacji o wszystkich klasach MFC mogłaby być nieco przytłaczająca. Zamiast więc przytaczać listing klas MFC, w tej sekcji zajmiemy się tylko najczęściej wykorzystywanymi klasami, grupując je w łatwe do opanowania kategorie. Szczegółowe informacje na temat każdej z tych klas, a także innych, takich jak cstring czy CException, możesz łatwo znaleźć w dokumentacji elektronicznej dostarczanej wraz z Developer Studio.
Usługi plików
Ta rodzina klas MFC, wyprowadzonych bezpośrednio z klasy cobject, zapewnia ogólną obsługę plików. W tym kontekście termin plik (ang. file) nie odnosi się jedynie do pliku na dysku, lecz obejmuje także żądania stron WWW, pliki odwzorowane w pamięci oraz gniazda TCP/IP. Klasy zawarte w tej kategorii zostały zebrane w tabeli 6. l.
Okna
Czasem można odnieść wrażenie, że wszystko w Windows to okna. Każdy element interfejsu użytkownika, od prostego przycisku poprzez rozwijane listy aż po paski narzędzi, posiada związany z nim uchwyt okna. A jakby tego było mało, MFC wprowadza także okienkową koncepcję modelu dokument-widok.
RozdziaÅ‚ 6. • PrzeglÄ…d programowania w MFC
121
Tabela 6.1 Klasy obsługi plików
Nazwa klasy
Opis
Cfile-Dostarcza niebuforowanych, binarnych usług wejścia-wyjścia.
CrecentFileList-Zapewnia kontrolę nad listą ostatnio używanych plików (MRU - Most Recently Used).

CmemFile-
Zapewnia dostęp do plików odwzorowanych w pamięci. COleStreamFile-Reprezentuje strumień danych w strukturalnym pliku danych OLE. CSocketFile-Używana do wysyłania i odbierania danych poprzez łącze TCP/1P.
CStdioFile-Zapewnia usługi buforowanego wejścia-wyjścia podobne do strumieni w C.

CSharedFile-Obsługuje wspólne pliki w pamięci.
CMonikerFile-Reprezentuje strumień danych w pliku złożonym w ten sam sposób, w jaki ścieżka dostępu identyfikuje standardowy plik na dysku.

CAsyncMonikerFile-Obsługuje zdolność kontrolek ActiveX do asynchronicznego ładowania danych ze strumienia danych.
CDataPathProperty-Umożliwia kontrolce ActiveX asynchroniczne ładowanie danych właściwości kontro l ki.

CCachedDataPath-Property-Umożliwia kontrolce ActiveX asynchroniczne ładowanie danych właściwości kontrolki i buforowanie ich w pamięci RAM.

CGopherFile-Obsługuje pobieranie danych z serwera Gopher. CHttpFile-Obsługuje pobieranie danych z serwera WWW.

Pozostając w zgodzie ze wszystkimi innymi rodzajami okien, MFC oferuje dodatkowo kilka zupełnie innych klas okien. Te klasy okien można rozbić na cztery szerokie kategorie: okna ramek, okna widoków, okna dialogowe oraz kontrolki. Każda z tych klas oferuje inne właściwości. Jedynymi wspólnymi cechami jest to, że każda z klas reprezentuje jakieś okno i że wszystkie one są wyprowadzone z klasy CWnd.
Okna ramek stanowią kontener dla aplikacji opartych na modelu dokument-widok. Okno ramki zawiera okno widoku, które z kolei zawiera reprezentację danych dokumentu. Tabela 6.2 zawiera listę różnych klas okien ramek, zaś tabela 6.3 zawiera listę różnych klas okien widoków.
Tabela 6.2. Klasv okien ramek
Nazwa klasy
Opis
CFrameWnd-Okno ramki SDI

CMDIChildWnd-Okno potomne SDI

CMDIFrameWnd-Okno ramki MDI

COlelPFrameWnd-Klasa wykorzystywana przy edycji danych "na miejscu'

CSplitterWnd-Dzielone okno w stylu Eksploratora

Tabela 6.3. Klasy okien widoku
Nazwa klasy
Opis
CView-Obsługuje podstawowy widok w aplikacjach dokument-widok.
CCtrlView-Stosuje architekturę dokument-widok do standardowych kontrolek.Windows. Służy jako klasa bazowa dla czterech następnych klas.
CEditView-Stosuje architekturÄ™ dokument-widok do standardowej kontrolki pola edycji w Windows. CListView-Stosuje architekturÄ™ dokument-widok do standardowej kontrolki listy w Windows.
CRichEditView-Stosuje architekturÄ™ dokument-widok do standardowej kontrolki rich edit w Windows.
CTreeView-Stosuje architekturÄ™ dokument-widok do standardowej kontrolki drzewa w Windows.

CScrollView-Podobnie do klasy CView, lecz z wbudowanymi możliwościami przewijania.

CFormView-Klasa podstawowa dla widoków zawierających kontrolki, takich jak okna dialogowe. Układ formularza jest oparty na zasobie dialogu zapisywanym w pliku aplikacji w momencie kompilacji.

CDaoRecordView-Rodzaj klasy CView wyświetlający w kontrolkach informacje z rekordsetu bazy danych Jet.
CRecordView-Rodzaj klasy CView wyświetlający w kontrolkach informacje z rekordsetu bazy danych ODBC.

Rodzina klas okien obejmuje także klasy okien dialogowych. Jak każdy użytkownik Windows wie, w systemie występują miriady różnych okien dialogowych, takich jak okna wyboru plików, okna komunikatów błędów czy okna wyboru czcionek. Każde z nich posiada własną klasę MFC. Różne klasy okien dialogowych zostały zebrane w tabeli 6.4.
Tabela 6.4. Klasy okien dialogowych
Nazwa klasy
Opis
CDialog-Klasa podstawowa dla wyświetlania okien dialogowych.
CCommonDia log - Reprezentuje podstawowe funkcje dla wszystkich standardowych okien dialogowych Windows i służy jako klasa podstawowa dla pięciu następnych klas.
CColorDialog-Reprezentuje standardowe okno dialogowe wyboru koloru w Windows. CFileDialog - Reprezentuje standardowe okno dialogowe wyboru pliku w Windows.
CFindReplace--Dialog- Reprezentuje standardowe okno dialogowe wyszukiwania i zastępowania tekstu w Windows.
CFontDialog-Reprezentuje standardowe okno dialogowe wyboru czcionek w Windows.
CPrintDialog-Reprezentuje standardowe okno dialogowe opcji wydruku w Windows. Dostarcza łatwy sposób dla implementacji okien dialogowych wydruku i podglądu wydruku.
CPropertyPage - Reprezentuje pojedynczą kartę arkusza właściwości.
Do rodziny klas okienkowych MFC należą wszystkie obiekty Windows posiadające powiązany ze sobą uchwyt okna. Do tego typu obiektów należą wszystkie kontrolki Windows, takie jak przyciski czy rozwijane listy. Klasy kontrolek zostały zebrane w tabeli 6.5.
Tabela 6.5. Klasy kontrolek
Nazwa klasy
Opis
CButton-Zwykły wciskany przycisk.

CBitmapButton-Zwykły przycisk posiadający zamiast tekstu bitmapę.

CComboBoK-Pole edycji z dołączoną rozwijaną listą.

CEdit-Pole tekstowe.

CHeaderCtrl-Okno umieszczone powyżej kolumn tekstu, zawierające nagłówki kolumn. Reprezentuje standardową kontrolkę nagłówka.

CHotKeyCtrl-Reprezentuje (opakowuje) standardowÄ… kontrolkÄ™ ,,hot key".
CListBox-Kontrolka zawierajÄ…ca listÄ™ pozycji.

CCheckListBox-Kontrolka zawierająca listę opcji, które mogą być włączone lub wyłączone.

CDragListBox-Reprezentuje standardową kontrolkę listy, z tym że pozwalającą użytkownikowi na zmianę kolejności poprzez przeciąganie elementów.
CListCtrl-Reprezentuje standardową kontrolkę listy. Kontrolka listy zapewnia kilka sposobów przeglądania danych. Kontrolki tego typu są stosowane przez Eksploratora Windows.

COleCtrl-Podstawowa klasa dla tworzenia kontrolek ActiveX.
CProgressCtrl-Reprezentuje standardową kontrolkę paska postępu i udostępnia funkcje składowe służące do manipulowania sposobem wyświetlania kontrolki.

CRichEditCtrl-Reprezentuje standardową kontrolkę Rich Edit. Kontrolka Rich Edit umożliwia użytkownikowi wpisywanie, edycję i formatowanie tekstu.

•CScrollBar-Dostarcza funkcji paska przewijania.
CSliderCtrl-Reprezentuje standardową kontrolkę suwaka. Dostarcza funkcji składowych do określania rozmiaru, skali i częstotliwości znaczników skali.

CSpinButttonCtrl-Reprezentuje standardową kontrolkę pokrętła. Pokrętło "dołącza" się do innych kontrolek, najczęściej pól tekstowych. Kliknięcie górnego lub dolnego przycisku powoduje zwiększenie lub zmniejszenie wartości w dołączonym okienku.

CStatic-Reprezentuje standardową statyczną kontrolkę. Statyczne kontrolki mogą wyświetlać napisy, prostokąty, ikony, bitmapy lub kursory.

CStatusBarCtrl-Reprezentuje standardową kontrolkę paska stanu. Pasek stanu to małe okienko wyświetlane zwykle w dolnej części okna nadrzędnego. Pasek stanu jest używany do wyświetlania różnych informacji o stanie aplikacji.

CTabCtrl-Reprezentuje standardową kontrolkę zakładek. Zakładki są używane do reprezentowania różnych stron tego samego okna dialogowego. Zakładki wyglądają podobnie do zakładek stosowanych w notatnikach.

Tabela 6.5. cd. Klasy kontrolek
Nazwa klasy
Opis
CToolBarCtrl-Reprezentuje standardową kontrolkę paska narzędzi. Pasek narzędzi to umieszczone swobodnie okienko zawierające przyciski lub kontrolki pola edycji, listy lub rozwijanej listy.
CToolTip-Reprezentuje standardową kontrolkę etykietki przycisku. Etykietka przycisku to małe okienko pojawiające się, gdy wskaźnik myszy zatrzyma się nad przyciskiem na okres około sekundy.
CTreeCtrl-Reprezentuje standardową kontrolkę drzewa. Kontrolka drzewa wyświetla dane aplikacji w postaci hierarchicznej. Eksplorator Windows a także stary Menedżer Plików wykorzystują kontrolki drzewa do wyświetlania informacji o strukturze plików i kartotek.
Grafika
Kolejną ważną rodziną klas MFC jest rodzina klas graficznych. Wewnątrz tej kategorii można dokonać następnego podziału na dwie podkategorie: konteksty urządzeń oraz urządzenia graficzne. Kontekst urządzenia reprezentuje kontener graficzny, taki jak okno czy plik, w którym można narysować tekst lub grafikę. Wszystkie klasy kontekstów urządzeń zostały wyprowadzone z klasy CDC, która z kolei została wyprowadzona z klasy cobject. Urządzenie graficzne to obiekt służący do operacji lysowania. Wszystkie klasy urządzeń graficznych są wyprowadzone z klasy CGdiObject, która z kolei jest wyprowadzona z klasy cobject. Nazwy klas urządzeń graficznych brzmią podobnie do nazw rzeczywistych przyborów rysunkowych, takich jak CPen dla rysowania linii czy CBrush dla malowania ekranu. Każda z klas graficznych MFC została zebrana w tabeli 6.6.
Tabela 6.6. Klasy kontrolek
Nazwa klasy
Opis

CDC-Reprezentuje kontekst urządzenia i dostarcza funkcji składowych do manipulowania tym kontekstem.

CClientDC-Reprezentuje kontekst urzÄ…dzenia powiÄ…zany z obszarem roboczym okna.
CMetFileDC-Tworzy kontekst urzÄ…dzenia powiÄ…zany z metaplikiem Windows.

CPaintDC=Tworzy kontekst urządzenia, który może być użyty wyłącznie w odpowiedzi na komunikat WM_PAINT.

CBitmap-Reprezentuje bitmapę Windows i dostarcza funkcji składowych służących do manipulowania bitmapą.

CBrush-Reprezentuje pędzel GDI Windows.
CFont-Reprezentuje czcionkÄ™ GDI Windows.
CPalette-Reprezentuje paletÄ™ GDI Windows.
CPen-Reprezentuje pióro GDI Windows.
CRgn-Reprezentuje region GDI Windows.

Obsługa baz danych
Biblioteka MFC obsługuje dwa rodzaje baz danych: ODBC i Microsoft Jet (ta.ostatnia jest znana także jako Microsoft Access). Używając tych klas, możesz odwołać się do praktycznie każdej wykorzystywanej obecnie bazy danych. Klasy ODBC zapewniają dostęp do wielu platform baz danych typu klient-serwer, takich jak Oracle, Sybase, In-formix czy własnego serwera SQL Microsoftu.
Klasy baz danych Jet pozwalają na użycie modelu obiektowego, nazywanego DAO (Data Access Objects), wbudowanego w każą bazę danych opartą na bazie Access lub Jet. DAO dostarcza własną bogatą hierarchię odpowiednią dla manipulowania tabelami i kwerendami bazy danych, a także zarządzania ochroną użytkowników i grup. Dostępne klasy baz danych zostały zebrane w tabeli 6.7.
Tabela 6.7. Klasy baz danych
Nazwa klasy
Rodzaj bazy danych
Opis
CDatabase ODBC-Reprezentuje połączenie z bazą danych ODBC.
CRecordset ODBC-Reprezentuje rekordset oparty na bazie ODBC.

CLongBinary ODBCUmożliwia manipulowanie w bazie danych ODBC dużymi obiektami binarnymi, takimi jak na przykład obrazki.
-
CDaoDatabase-DAO Reprezentuje połączenie z bazą danych.Microsoft Jet (Access).
CDaoQueryDef-DAO Reprezentuje definicjÄ™ kwerendy bazy danych Jet.

CDaoRecordsetDAO Reprezentuje rekordset bazy danych Jet.
-CDaoTableDef-DAO Reprezentuje definicjÄ™ tabeli bazy danych Jet.
CDaoWorkspace-DAO Reprezentuje obszar roboczy bazy danych Jet.

Na tym kończymy naszą wycieczkę po bibliotece MFC. Choć wymieniliśmy najczęściej używane klasy, jednak to dopiero wierzchołek całej góry lodowej. W pozostałej części książki będziemy pracować nie tylko z klasami wymienionymi w tym rozdziale, ale także z kilkoma innymi, znajdującymi się poza zakresem tego krótkiego wprowadzenia.
Nie używasz MFC?
Choć MFC udostępnia programiście aplikacji wiele korzyści, istnieją przypadki, gdy możesz nie chcieć korzystać z zalet tej biblioteki. Twórcy MFC pracowali nad tym, aby zminimalizować ilość i rozmiar wymaganych plików. W tradycyjnych aplikacjach takie wspomagające pliki zwykle nie są problemem, gdyż są instalowane obok głównych plików aplikacji.
Wzrost popularności Internetu spowodował dalszą ewolucję MFC. Internet zmienił tradycyjny model programowania. W dawnych czasach powszechnie przyjęte było, że aplikacja była instalowana całkowicie i w całości na poszczególnych komputerach. Aplikacja była samodzielna i samowystarczająca. Taki model aplikacji nosi nazwę aplikacji monolitycznej. MFC zapewniało wszystkie funkcje wymagane przez aplikacje monolityczne. Ponieważ cały kod był wykonywany w pojedynczym komputerze, MFC doskonale nadawało się do tego modelu programowania.
Gdy na scenie pojawił się model programowania typu klient-serwer, pewne części aplikacji zostały przeniesione do serwera. Jednak interfejs użytkownika oraz pewne niezbyt obciążające zadania aplikacji pozostały w komputerze klienta. Ponieważ interfejs użytkownika w dużym stopniu wiąże się z wykorzystaniem MFC, biblioteka MFC także w tym przypadku może być z powodzeniem wykorzystana.
Wraz ze wzrostem wpływu Internetu ponownie zmieniły się wymagania co do programowania. W wielu przypadkach aplikacja jest w pełni dystrybuowana, gdzie serwer bazy danych dostarcza dostępu do danych, serwer WWW dostarcza usług aplikacji, zaś przeglądarka WWW zapewnia interfejs użytkownika. Biorąc pod uwagę rozdystrybuowaną naturę tego modelu programowania, MFC nie zawsze jest odpowiednie.
Obecna technologia internetowa umożliwia osadzanie kontrolek ActiveX na stronie WWW. Gdy przeglądarka (klient) pobiera stronę, wraz z nią pobiera również kontrolki i wykonuje je. Ponieważ większość użytkowników wciąż korzysta z Internetu za pośrednictwem powolnych modemów, kluczowym zagadnieniem jest redukcja ilości danych, które muszą zostać przekazane.
MFC wymaga wsparcia ze strony kilku obszernych bibliotek DLL, z których większość przekracza rozmiar 100K. Jeśli przeglądarka musiałaby ściągnąć oprócz strony i kontrolek także kilkaset kilobajtów dodatkowych plików, oczywiste jest że taka strona ściągałaby się bardzo długo. Próbując rozwiązać ten problem, Microsoft zaprezentował inną bibliotekę o nazwie ATL (Active Template Library). ATL umożliwia tworzenie niewielkich kontrolek o małych rozmiarach plików, dobrze nadających się do przekazywania poprzez sieć WWW. Z biblioteką ATL zapoznamy się w rozdziale 33.
Podsumowanie
Na tym kończy się nasze wprowadzenie do biblioteki MFC. Mamy nadzieję, że teraz nie tylko wiesz czym jest ta biblioteka, ale także jakie cele przyświecały jej tworzeniu. Powinieneś także już mieć pojęcie o jej organizacji oraz znać przynajmniej nazwy jej podstawowych klas.