[ Pobierz całość w formacie PDF ]
.pas';end.Moduły rejestracyjnePodobnie jak komponenty VCL, także komponenty CLX zawarte w pakietach środowiskowych wymagająrejestracji.Rejestrację tę wykonuje procedura Register() zawarta w jednym z modułów wymienionych wdyrektywie contains.Wydruk 13.11 prezentuje kod zródłowy modułu rejestracyjnego QddgSamples_regpakietu QddgSamples_Dsgn rejestracji podlegają komponenty TddgSpinner, TddgDesignSpinner iTddgImgListSpinner oraz edytorTddgRadioGroupEditor.Wydruk 13.11.Moduł rejestracyjny pakietu QddgSamples_Dsgn{==================================================================QddgSamples_RegModuł rejestracyjny dla komponentów niebazodanowychCopyright � 2001 by Ray Konopka==================================================================}unit QddgSamples_Reg;interfaceprocedure Register;implementationusesClasses, DesignIntf, DesignEditors, QExtCtrls,QddgSpin, QddgDsnSpn, QddgILSpin,QddgRgpEdt;{=============================}{== procedura rejestracyjna ==}{=============================}procedure Register;begin{== rejestracja komponentów ==}RegisterComponents( 'DDG-CLX',[ TddgSpinner,TddgDesignSpinner,TddgImgListSpinner ] );{== rejestracja edytora komponentu ==}RegisterComponentEditor( TRadioGroup, TddgRadioGroupEditor );end;end. Ikony komponentówNowo stworzonym komponentom można przyporządkować ikony identyfikujące je w palecie komponentów ikony te muszą być 16-kolorowymi bitmapami o rozmiarze 24�24 piksele.Zgodnie z sugestiami zawartymi wsystemie pomocy Delphi i Kyliksa, należy utworzyć odrębne zasoby bitmap dla każdego z komponentów.Tymczasem edytor pakietów dla każdego dodawanego do pakietu modułu.dcu poszukuje odpowiadającego mupliku.dcr nawet wtedy, gdy pakiet jest pakietem wykonywalnym; wspomniane bitmapy nie są w pakieciewykonywalnym do niczego potrzebne i tylko bezproduktywnie zajmują miejsce.Tak więc, zamiast tworzyć osobne pliki.dcr dla każdego z komponentów, należy raczej utworzyć pojedynczyplik z bitmapami dla wszystkich komponentów w pakiecie.Tak się szczęśliwie składa, że pliki zasobowedołączane do wykonywalnych plików Linuksa mają format identyczny z plikami zasobowymi Win32 (mimo iżsame pliki wykonywalne różnią się w obydwu tych środowiskach).Można więc, używając dowolnego edytorazasobów windowsowych, utworzyć żądany plik.res i zmienić jego rozszerzenie na.dcr.Edycję bitmapy dla jednego z opisywanych wcześniej komponentów przedstawia rysunek 13.9.Rysunek 13.9.Edycja bitmapy zawartej w pliku.dcrZwróć uwagę na to, iż w obydwu naszych przykładowych pakietach środowiskowych plik.dcr ma taką samąnazwę jak odpowiedni moduł rejestracyjny; umieszczając więc ten ostatni w pakiecie, automatyczniepowodujemy również dołączenie stosownej bitmapy.Dla pakietów wykonywalnych nie istnieją modułyrejestracyjne, nie ma więc też niepotrzebnych bitmap.Na zakończenie jeszcze dobra rada: mimo iż ikona reprezentująca komponent w palecie nie ma żadnego wpływuna jego funkcjonowanie, nie można nie doceniać jej znaczenia.Jest ona wizytówką komponentu i kształtujepierwsze wyobrażenie o nim; niedbała wizytówka może stwarzać (być może niesłusznie) wrażenie, iż opatrzonynią komponent wykonany jest równie niedbale.Jak istotne jest to w przypadku komponentów wykonywanychdla celów komercyjnych, nie trzeba nikogo przekonywać& PodsumowanieNiniejszy rozdział poświęciliśmy pewnemu rzec by można: rozwojowemu aspektowi tworzenia aplikacji ikomponentów w środowisku typu RAD, mianowicie uwzględnieniu przyszłej ich migracji na platformy inne niżMS Windows.To właśnie Delphi, jako pierwsze popularne narzędzie do błyskawicznego tworzenia aplikacji,przekroczyło zaklętą granicę Windows, gdy pod postacią Kyliksa zaistniało w systemie Linux.Możliwośćtworzenia aplikacji uniwersalnych, akceptowanych zarówno w Delphi, jak i w Kyliksie, pojawiła się w Delphi 6pod postacią biblioteki CLX, będącej zestawem komponentów i zrealizowanej na podstawiemiędzyplatformowych mechanizmów biblioteki Qt.Tworzenie aplikacji międzyplatformowych wiąże się z pewnymi ograniczeniami w stosunku do aplikacjiopartych na bibliotece VCL; ograniczenia te wynikają po prostu z braku pewnych mechanizmów Windows winnych systemach operacyjnych, między innymi w Linuksie, i są naturalną ceną płaconą za uniwersalność.Nawet podczas tworzenia aplikacji przeznaczonych wyłącznie dla Windows warto zdawać sobie sprawę z faktu,iż (ewentualne) ich przystosowanie do wymogów CLX (w przyszłości) będzie tym łatwiejsze, w im większymstopniu respektowane będą owe ograniczenia.�w respekt wyrażać się powinien przede wszystkim w unikaniu(wszędzie, gdzie to tylko możliwe i akceptowalne) mechanizmów specyficznych dla Windows główniekomunikatów, których obsługę należy zastąpić metodami dyspozycyjnymi, oraz bezpośrednich odwołań dofunkcji GDI, które powinny ustąpić miejsca odpowiednim metodom płótna.Zaprezentowane w niniejszymrozdziale implementacje przykładowych komponentów obfitują w takie właśnie eliminacje .Jednym z najistotniejszych przejawów uniwersalności aplikacji międzyplatformowej jest akceptowalność jejjedynego kodu zródłowego na różnych platformach (na razie w Delphi 6 i Kyliksie).W sytuacji, gdy pewnerozwiązania nie dadzą się łatwo zaprogramować w sposób uniwersalny, możliwe jest wydzielenie fragmentówkodu dedykowanych tylko konkretnemu środowisku; temu celowi służą odpowiednie symbole kompilacjiwarunkowej (na razie MSWINDOWS i LINUX)
[ Pobierz całość w formacie PDF ]
