[ Pobierz całość w formacie PDF ]
Al Williams Czarna Księga MFC Wstęp Jesteś programistą używającym MFC? To dobrze. Są dwa typy programistów korzystających z MFC. Ciekawe, do którego z nich należysz? Pierwszym typem są “dobrzy" programiści, którzy używają tej biblioteki w taki sposób w jaki chcieliby jej twórcy. Drugim rodzajem są “dzicy anarchiści", którzy wszystko muszą robić swoimi własnymi sposobami. Prawdę mówiąc, ja zaliczam się do tej drugiej grupy. Jeśli płyniesz na tej samej łódce co ja (lub jeśli przynajmniej tego chcesz), to książka ta będzie dla Ciebie doskonała. Ta książka nie nauczy Cię MFC; a przynajmniej nie w tradycyjnym znaczeniu tego słowa. Powinieneś zabierać się do niej z dobrą znajomością podstaw użytkowania MFC i z przemożną chęcią na robienie wszystkiego w inny sposób. To nie jest przykładowy program Scribble (chociaż w pierwszym rozdziale przypomnę podstawowe wiadomości o sposobach używania biblioteki). W tej książce nauczysz się wykorzystywać w swoich programach wszystkie, nawet najdrobniejsze i najbardziej ukryte, możliwości MFC. Poznasz sposoby używania, omijania oraz wypaczania poprawnego sposobu użycia architektury dokument/widok. Jeśli zawsze chciałeś stworzyć własne archiwa, to wreszcie zobaczysz jak to można zrobić. Dlaczego ta książka? Musisz mieć pozwolenie na prowadzenie praktyki medycznej. Czyż nie? Czytywałem artykuły w tych dniach gdy sugerowano, że niektórzy pracownicy HMO i agencji ubezpieczeniowych praktykowali usługi medyczne bez specjalnego wykształcenia i pozwoleń. Oto na jakiej zasadzie to działa: Twój lekarz sugeruje Ci kosztowną kurację, jednakże Twoja agencja ubezpieczeniowa nie zgadza się na refundację kosztów leczenia, gdyż (według nich) nie jest to konieczne. No i nie masz leczenia. A agencja ubezpieczeniowa twierdzi, że nie zajmują się medycyną. Oczywiście nic nie stoi na przeszkodzie, abyś samemu zapłacił cały koszt leczenia; jednakże, wziąwszy pod uwagę koszty z tym związane, odmowa refundacji kosztów leczenia przez agencję ubezpieczeniową, jest równoznaczna z uniemożliwieniem Ci tego leczenia. Programowanie w systemie Windows ma kilka interesujących podobieństw do powyższej sytuacji. Technologia OLE jest bardzo trudna do użycia, a więc używasz MFC. To bardzo wiele upraszcza. Oczywiście możesz samemu spróbować zaimplementować obsługę OLE (zabierze Ci to około roku ciężkiej pracy). Jeśli jednak będziesz chciał to zrobić w trzy dni, to najprawdopodobniej będziesz musiał skorzystać z MFC. Ogólnie rzecz biorąc MFC jest bardzo dobrą biblioteką. Jeśli jednak chcesz użyć jakichkolwiek jej możliwości, to automatycznie musisz zaakceptować wszystkie rozwiązania, które narzuca. Nie możesz użyć tylko fragmentu MFC obsługującego OLE (tak jak nie możesz używać samego podglądu wydruku lub okien dzielonych). Jeśli chcesz używać MFC, to musisz się zgodzić na to, iż wszystko będziesz musiał robić w sposób narzucony przez MFC. Wewnątrz MFC można znaleźć kilka interesujących fenomenów. Czy wiedziałeś, że można używać dynamicznej wymiany danych (DDX) z każdym kontrolowanym oknem potomnym? Jednakże Class Wizard pomaga Ci w obsłudze okien jedynie kilku określonych typów (na przykład — okien dialogowych). Ze względu na to, że używanie DDX bez kreatora Class Wizard jest mało udokumentowane, prowadzi to w efekcie do ograniczenia Twoich możliwości używania DDX. Jedną ze wspaniałych rzeczy wynikających z bycia programistą, jest to, że musisz tworzyć. Czasami myślę, że dobrze wykonane oprogramowanie jest jedną z najczystszych form kreacji jakie są dostępne dla człowieka. Pomyśl o tym. We śnie przychodzi Ci do głowy pomysł na nowy program; stukasz kilka godzin w klawiaturę, no i proszę - stworzone zostało nowe dzieło. Jeśli piszesz dostatecznie dobrze i szybko, to dzieje się to tak, jak gdyby program “wlewał" się z Twojego mózgu do komputera. Narzędzia takie jak MFC powinny pomagać Ci w tworzeniu i realizowaniu Twoich pomysłów - nie przeszkadzać im. Dawno temu... Pierwszymi komputerami na jakich tworzyłem swoje pierwsze poważne programy były projektowane przeze mnie mikroprocesory. Wtedy pomysłowość była najważniejsza. Napisać mogłem wszystko co mi się przyśniło (oczywiście w granicach możliwości pamięci operacyjnej o wielkości 4KB). Problem polegał na tym, że musiałeś wymyślić każdy, nawet najdrobniejszy szczegół oprogramowania. Za tamtych dni spędzałem długie godziny tworząc kod pobierający i wysyłający bajty przez obsługiwany programowo port RS232. Musiałem liczyć przerwania, aby wiedzieć jaka jest pora dnia. Cóż, jak widać konieczność zbyt dużej twórczości nie jest rzeczą dobrą. Dziś nie musisz już zawracać sobie głowy tymi drobnymi szczegółami. Jeśli chcesz coś wysłać RS-em, to po prostu “otwierasz" go i wpisujesz do niego poszczególne bajty. Może być jeszcze lepiej -jeśli chcesz obsługiwać mysz, modem lub drukarkę, to istnieją procedury wyższego poziomu umożliwiające bezpośredni dostęp do tych urządzeń z pominięciem portu szeregowego, przy pomocy którego urządzenia te są podłączone do Twojego komputera. Jednakże to co jest zyskiem w szybkości tworzenia oprogramowania, jest jednocześnie stratą na kreatywności. Podczas gdy kiedyś mogłeś kontrolować każdy szczegół, teraz musisz się zadowalać możliwościami udostępnianymi Ci przez system operacyjny. Szczerze mówiąc, nie musi to od razu być złą rzeczą. Kto przy zdrowych zmysłach chciałby pisać swoje własne procedury obsługujące odczyt i zapis na twardym dysku? Czy procedury takie działałyby ze wszystkimi dyskami dostępnymi na rynku? Czy naprawdę chcesz pisać procedury obsługujące wszystkie dostępne na rynku drukarki i karty graficzne? Zazwyczaj odpowiedź brzmi: nie. Jednakże, to właśnie są szczegóły niskiego poziomu. A co ze szczegółami wysokiego poziomu, takimi jak styl interfejsu użytkownika? System Windows narzuca na Ciebie ograniczenia nawet na tym poziomie. Ale właśnie w tym tkwi sedno sprawy - im wyższego poziomu jest narzędzie, tym większe narzuca ono ograniczenia. Wspaniałym przykładem jest język programowania Visual Basic. VB jest językiem doskonałym do tworzenia pewnego typu programów. Jeśli Twój program robi rzeczy, które można napisać w Visual Basicu, to byłbyś szalony gdybyś nie użył tego właśnie języka. Wskazujesz myszką, klikasz - i gotowe. Ale co się dzieje w momencie, gdy Twój program ma robić rzeczy, do których Visual Basic nie jest przystosowany? Teraz sprawa się komplikuje. Czasami możesz nagiąć Visual Basic i zmusić go do wykonania rzeczy, do których nie jest on przystosowany; jednakże to wymaga wiele pracy. Czasami może to wymagać ogromnej pracy. Może dojść do tego, że znacznie lepiej będzie użyć innego - bardziej elastycznego języka programowania. Visual Basic, podobnie jak wszelkie inne narzędzia narzuca pewne ograniczenia na sposób tworzenia oprogramowania. Ograniczenia narzucane przez MFC Jakie ograniczenia narzuca na Ciebie MFC? Jest ich wiele, nawet jeśli nie zdajesz sobie z tego sprawy. MFC ogranicza Cię na kilka sposobów: • MFC ma ściśle określoną architekturę, od której zależy poprawne działanie poszczególnych elementów biblioteki. • Gdy MFC udostępnia komponent lub klasę, to czasami znacznie łatwiej jest użyć tej udostępnianej klasy (niezależnie do jej możliwości) niż samemu tworzyć podobną klasę lub komponent. • Narzędzia udostępniane przez MFC (App Wizard oraz Class Wizard) działają tylko i wyłącznie z określonymi typami programów. Tworzenie programów innego typu jest znacznie trudniejsze, gdyż narzędzi tych nie możesz użyć. Cała ta książka poświęcona jest sposobom przezwyciężania ograniczeń narzucanych na Ciebie przez MFC. Czasami sprowadza się to do dyskusji o trudnych i pracochłonnych rozwiązaniach. Czasami rozwiązania te będą całkiem proste, zwłaszcza jeśli dysponujesz odpowiednimi wiadomościami. Za każdym razem jednak będziesz osiągał swoje cele wykorzystując do tego MFC. Nie masz czasu na sztuczki, które mogą nie działać z kolejnymi wersjami biblioteki. Oczywiście bycie odmiennym dla samej idei nie jest dobre. Dla przykładu, umieszczenie menu Plik w samym środku paska menu łamie słynną Zasadę Minimalizacji Szoku (ang.: Shock Minimization Principle - SMP). Zasada ta jest jednym z aksjomatów projektowania oprogramowania, głosi ona iż: Oprogramowanie powinno działać w taki sposób, aby minimalizować szok wywierany na użytkownikach. Z drugiej jednak strony, istnieje wiele przypadków, w których chciałbyś zrobić coś troszkę inaczej. Na pewno chciałbyś wypróbować swoją kreatywność i stworzyć coś, czego nikt inny jeszcze nie widział, nieprawdaż? Taki właśnie jest cel niniejszej książki: pomóc Ci w realizacji Twoich wizji oprogramowania. Jak używać tej książki Aby w pełni wykorzystać informacje dostarczane przez tę książkę powinieneś dysponować Visual C++ 5.0 lub wersją późniejszą. Najprawdopodobniej będziesz mógł wykorzystywać większość prezentowanych technik używając innych wersji kompilatorów C++ stworzonych przez firmę Microsoft jak i inne firmy; jednakże wszystkie przykłady umieszczone w tekście książki oraz na CD ROMie używają VC++ 5.0. Każdy rozdział poświęcony jest innym zagadnieniom. Pierwsza część rozdziału zawiera szczegółowe informacje dotyczące omawianego zagadnienia. Część druga, przedstawia konkretne problemy oraz gotowe “przepisy" na ich rozwiązanie. Mogą się tam także pojawić odwołania do artykułów technicznych dotyczących MFC, stron WWW oraz artykułów prasowych. Każdy rozdział może być traktowany jako odrębna część, niezależna od pozostałych rozdziałów. Jeśli chcesz rozwiązać konkretny problem, to najlepiej zrobisz przeglądając praktyczny przewodnik umieszczony na końcu każdego z rozdziałów. Oczywiści, umieszczone tam przykłady służą jedynie wskazaniu Ci możliwych sposobów rozwiązywania problemów, W końcu chcesz sprawdzić swoje możliwości twórcze. Może masz swoją własną wizję oprogramowania, które chcesz tworzyć. Może Twoi klienci, Twój szef lub konkurencja wymusza na Tobie użycie konkretnych sposobów tworzenia oprogramowania. W każdym z tych przypadków przeczytaj odpowiedni rozdział i poznaj w jaki sposób możesz rozwiązać stojący przed Tobą problem innymi metodami. Rozdział 1 Architektura Zanim rozpoczniesz zgłębianie zaawansowanych technik programistycznych z wykorzystaniem MFC, będziesz musiał posiąść bardzo solidną znajomość (i zrozumienie) podstawowej architektury MFC - w tym architektury dokument/widok, map komunikatów, analizy linii poleceń, wyprowadzania klas potomnych oraz używania kolekcji. Starożytni Rzymianie nie byli dobrymi z matematykami. Oczywiście nie pomógł im także fakt, iż nie zadali sobie trudu odkrycia liczby zero. W świecie starożytnym największymi matematykami byli arabowie. Swoją wiedzę zdobywali od uczonych ze starożytnych Indii, którzy zaczęli interesować się matematyką około 200 roku p.n.e. Z drugiej strony atlantyckiej sadzawki Majowie także znali liczbę zero i byli bardzo zaawansowanymi i wyrafinowanymi matematykami. Ich kalendarz był znacznie doskonały od tego, którego my używamy dzisiaj. Wyobraź sobie co by się stało, gdyby starożytni mędrcy zaczęli liczyć w systemie dwójkowym, a nie w dziesiętnym - moglibyśmy policzyć na palcach do 1024. To w cale nie jest tak abstrakcyjne, jak mógł byś pomyśleć. Germanie oraz Celtowie posługiwali się systemem dwunastko wy m. Oto dlaczego cały czas używamy tuzinów, a na zegarkach jest dwanaście godzin (nie wspominając już o dwunastu calach na stopę). Ale chodzi o to, aby zdać sobie sprawę z tego, że narzędzia jakich używamy mogą mieć znaczny wpływ na sposób rozwiązania problemu. Weźmy na przykład języki piktograficzne używane w Chinach i Japonii. Języki te ciężko zastosować w komputerach. Fakt ten był głównym problemem wprowadzania komputeryzacji na Dalekim Wschodzie. Dla przykładu, użytkownik piszący na laptopie mógł zapisać słowo fonetycznie używając do tego alfabetu Kanji. Po wpisaniu słowa program mógłby wyświetlić kilka piktogramów (o tych samych znaczeniach), a użytkownik mógłby wybrać ten, którego chce użyć. Rozwiązanie takie nie byłoby jednak zbyt efektywne. Z drugiej jednak strony, języki piktograficzne są znacznie prostsze do pisania ręcznego. Wiele japońskich komputerów typu palmtop pozwala na ręczne wpisywanie znaków na monitorze. Takimi samymi możliwościami dysponują jedynie nieliczne komputery tej samej klasy produkowane w krajach anglojęzycznych, a jeśli już, możliwości te nie są zbytnio zaawansowane i dobre. Nasze pisane litery nie są dostatecznie charakterystyczne, aby komputery były w sianie je bez problemów rozpoznać. Każda cecha używanego środowiska programistycznego ma wpływ na Twoje programy. Fakt, iż piszesz programy, które mają działać w systemie Windows, ma kolosalny wpływ na sposób w jaki będziesz tworzył programy. MFC, C++ oraz inne narzędzia, których będziesz używał przy tworzeniu kodu, także będą miały wpływ na tworzone przez Ciebie oprogramowanie. Jednym z zadań tej książki jest nauczenie Cię rozwiązywania problemów w niestandardowy sposób; zanim jednak będziesz mógł zabrać się do pracy, musisz zrozumieć zasady działania używanych przez Ciebie narzędzi (w naszym wypadku VC++ oraz MFC). Istnieją po temu dwa główne powody. Po pierwsze, musisz wiedzieć jak działa MFC, aby zmusić je do zrobienia tego, czego chcesz. Po drugie, nie jesteś w stanie dowiedzieć się jak niektóre rzeczy są robione w MFC, gdyż do ich zrobienia wykorzystujesz narzędzia (np.: Class Wizard lub App Wizard), które, de facto, wykonują całą robotę za Ciebie. Kreatory podobne są do narzędzi VCR wykorzystujących kody VCR Plus. Wszystko jest w porządku, do momentu gdy dysponujesz odpowiednimi kodami. Jeśli jednak chcesz napisać, coś co nie posiada odpowiadającego sobie kodu VCR Plus, masz duży problem. Nie tylko będziesz musiał stworzyć własne oprogramowanie VCR, lecz, co gorsza, zapewne nawet nie będziesz wiedział jak się do tego zabrać. Pierwszym celem tego rozdziału jest omówienie wszystkich podstawowych składników MFC oraz ich związku z ogólną architekturą biblioteki. Drugim celem jest rozebranie na części programu wygenerowanego przez App Wizarda i poznanie tajemnic jego zachowania. Jeśli już dużo programowałeś przy użyciu MFC, możesz myśleć, że przeczytanie tego rozdziału nic Ci nie da. Jeśli nie chcesz, nie musisz go czytać. Ale spróbuj odpowiedzieć na zadane poniżej pytania; jeśli będziesz potrafił podać odpowiedzi, pomiń ten rozdział. Zawsze jednak warto przeczytać praktyczny przewodnik umieszczony na końcu tego rozdziału. Poniżej podane zostały pytania: • Jaka jest jedyna klasa, którą musi posiadać program wykorzystujący MFC? • W jaki sposób możesz ręcznie stworzyć mapę komunikatów? • W jaki sposób dołączyć do dokumentu dodatkowe widoki? • W jaki sposób można stworzyć nowe typy dokumentów? • Kiedy dokument nie obsługuje poleceń wejścia/wyjścia? • Kiedy widok nie realizuje wizualizacji danych zawartych w dokumencie? • Czy można umieścić uchwyt do menu w klasie dokumentu? • Dlaczego klasa CRect nie może być klasą potomną klasy CObject? • Czy szablony dokumentów muszą być przechowywane w obiekcie aplikacji? • Dlaczego trudno jest stworzyć dwuwymiarową tablicę za pomocą szablonów i klasy CArray? Warcaby W skład biblioteki MFC wchodzi wiele klas. Jednak tylko kilka z nich należy do podstawowych komponentów, które mają wpływ na architekturę tworzonych programów. Pozostałe z nich nie mają większego wpływu na sposób, w jaki piszesz programy. Tymi podstawowymi klasami są: CWinApp, CView, CDocument, CFrameWnd oraz CDocTemplate. Chociaż klasy te tworzą fundament większości programów pisanych przy użyciu MFC, to jednak nie musisz z nich korzystać za każdym razem. De facto, jedyną klasą absolutnie konieczną do stworzenie programu MFC jest klasa CWinApp. Aby móc jednak w pełni wykorzystać możliwości dostarczane przez MFC, będziesz musiał użyć także pozostałych czterech podstawowych klas (lub ich klas potomnych). Potęgą MFC jest technika zwana czasami “projektowaniem poprzez różnice". Pomysł ten polega na tym, iż MFC dostarcza klas, za pomocą których można stworzyć modelowy program działający w systemie Windows. Jednakże ten modelowy program nie robi niczego ciekawego. Twoim zadaniem, jako programisty wykorzystującego MFC, jest stworzenie kodu, który spowoduje, iż Twój program będzie się różnił do wszystkich innych programów. MFC zadba o zapewnienie standardowego zachowania programu, natomiast Ty będziesz mógł wybiórczo zmodyfikować sposób jego działania. Klasa CWinApp reprezentuje Twój program działający w pamięci operacyjnej komputera. Użytkownik nigdy bezpośrednio nie widzi niczego, co jest związane z tą klasą. Jest to kluczowe miejsce, w którym można uzyskać dane dotyczące aplikacji (na przykład, parametry wywołania programu, zasoby, uchwyt instancji, itd.). Podstawowe metody klasy CWinApp przedstawione zostały w tabeli 1.1. Najważniejsze z nich są dwie metody, które użytkownik może przesłaniać w swoich aplikacjach - Initlnstance oraz Exitlnstance. Zazwyczaj w metodzie InitInstance kreator App Wizard umieszcza kod tworzący główne okno aplikacji oraz wykonujący inne czynności inicjalizacyjne. Można sobie wyobrazić sytuację, w której wszystkie operacje programu byłyby wykonywane właśnie w tej metodzie. Po ich wykonaniu metoda InitInstance zwróciłaby wartość FALSE kończąc działanie programu. Kreator App Wizard postąpi w opisany powyżej sposób w momencie, gdy poprosisz go o stworzenie aplikacji, której oknem głównym jest okno dialogowe (patrz Listing 1.1). W takim przypadku program powoduje wyświetlenie okna dialogowego; jednakże jeśli chcesz, może on zrobić cokolwiek innego (o ile nie jest do tego konieczna pętla przetwarzająca komunikaty). Tabela 1.1 Podstawowe metody i dane klasy CWinApp Nazwa Opis m_pszAppName Nazwa aplikacji. m_lpCmdLine Linia poleceń użyta do uruchomienia aplikacji. m_hInstance Uchwyt aplikacji. m_hPrevInstance Poprzedni uchwyt aplikacji. m_pMainWnd Główne okno aplikacji. m_bHelpMode TRUE jeśli aplikacja korzysta z pomocy kontekstowej. m_pszExeName Nazwa pliku EXE. m__pszProf ileName Nazwa pliku INI. m_pszRegisteryKey Nazwa klucza rejestru systemowego który może być używany zamiast pliku INI. LoadCursor Ładuje kursor aplikacji. LoadStandardCursor Ładuje kursor systemowy (IDC_ *). LoadOemCursor Ładuje kursor OEM (OCR_ *). Loadlcon Ładuje ikonę aplikacji. LoadStandardlcon Ładuje ikonę systemową (IDI_ *). LoadOemlcon Ładuje ikonę OEM (OIC_ *). ParseCommandLine Powoduje inicjalizację obiektu klasy CCommandLinelnfo na podstawie danych umieszczonych w linii wywołania programu. ProcessShellCommand Obsługuje polecenia systemowe umieszczone w obiekcie CCommandLinelnfo. GetProfileInt Pobiera liczbę całkowitą z pliku INI. WriteProfileInt Zapisuje liczbę całkowitą do pliku INI. GetProfileString Pobiera łańcuch znaków z pliku INI. WriteProfileString Zapisuje łańcuch znaków do pliku INI. AddDocTemplate Dodaje szablon dokumentu do aplikacji. GetFirstDocTemplatePosition ...
[ Pobierz całość w formacie PDF ]
zanotowane.pldoc.pisz.plpdf.pisz.plrumian.htw.pl
|
