15.doc

(319 KB) Pobierz

 

Część III

W następnym rozdziale nadamy nieco tempa naszej pracy. Trzecia część rozpocznie się od rozważań na temat technologii COM i ActiveX. Nauczysz się tworzyć komponenty ActiveX, a także kontrolki ActiveX szczególnego rodzaju nazywane formularzami aktywnymi (ang. ActiveForm). Komponenty ActiveX wykazują podobieństwo do komponentów VCL, niemniej jednak posiadają całkowicie odmienną architekturę.

Po omówieniu technologii COM i ActiveX przejdziemy do problematyki programowania baz danych. Poznasz architekturę bazy danych, a także sposoby implementowania operacji na bazach danych przez Delphi i VCL; zaczynając od podstaw będziesz podążał w stronę bardziej zaawansowanych technik programowania.

W następnej kolejności przyjdzie pora, by stawić czoła bibliotekom łączonym dynamicznie (DLL). Użytkowanie bibliotek DLL w aplikacjach jest sprawą niebagatelną, a więc – wymagającą pewnego przygotowania. Bibliotekom DLL poświęcony został cały rozdział dziewiętnasty, po jego przeczytaniu będziesz mógł zdecydować czy chcesz z nich korzystać, czy też nie. Bez wątpienia, na pewnym etapie zmagań programistycznych odkryjesz, że jesteś w stanie wykorzystać biblioteki DLL dla własnych celów.

W rozdziale dwudziestym przejdziesz do bardziej zaawansowanego zagadnienia, jakim jest pisanie komponentów. Utworzenie komponentu wymaga dogłębniejszego rozumienia właściwości, metod i zdarzeń, z którymi kontakt miałeś całkiem niedawno. Pisanie komponentów nie jest przeznaczone dla ludzi słabej kondycji programistycznej – jest to prawdziwe programowanie, które możesz pokochać lub też nie. Jeżeli odkryjesz, że pisanie komponentów nie jest Ci przeznaczone, nie stanie się nic strasznego. Istnieje mnóstwo komponentów typu shareware, freeware i komercyjnych, które wykonają niemal wszystkie zadania, jakie sobie zażyczysz.

Na końcu poznasz różnice i podobieństwa zachodzące między Delphi i C++ Builderem. Jedną z wielkich zalet formularzy Delphi jest to, że możesz korzystać z nich również środowisku C++ Builder. Delphi i C++ Builder nie są produktami konkurującymi ze sobą, a raczej –wzajemnie uzupełniającymi się.

Do końca pozostała już tylko jedna część książki. Możesz zacząć, kiedy tylko będziesz gotów.










\\printsrv\skład\Robin\Delphi 4 dla kazdego\15.doc              639


Rozdział 15.
Obiekty typu COM i ActiveX










Rozdzia³ 15. ¨ Obiekty typu COM i ActiveX              639

OLE, ActiveX, COM, DCOM, VCL, CORBA, MTS... przemysł komputerowy z pewnością nie cierpi na brak skrótów z zakresu architektury komponentów! W niniejszym rozdziale niektóre z tych skrótów zostaną rozszyfrowane, a inne przynajmniej wspomniane. Wyjaśnię znaczenie tych terminów i spróbuję rzucić trochę światła na często nie do końca zrozumiały świat technologii COM i ActiveX. W szczególności zajmiemy się:

u                                          Omówieniem istoty technologii COM

u                                          Tworzeniem obiektów COM

u                                          Omówieniem edytora biblioteki typu

u                                          Tworzeniem kontrolek ActiveX

u                                          Tworzeniem formularzy aktywnych

u                                          Umieszczaniem kontrolek ActiveX w sieci

Skłamałbym mówiąc, że technologie COM, ActiveX, czy OLE są łatwe do zrozumienia. Nie są. Na początku wszystko może wydawać się mylące. Nie jestem w stanie dobrze oddać tego tematu w jednym rozdziale. Moim celem jest tutaj przekazanie wiedzy wystarczającej do lepszego zrozumienia funkcjonujących obecnie skrótów różnych architektur komponentów. Oprócz tego przejdziesz dobry trening praktyczny z zakresu tworzenia kontrolek COM i ActiveX. Szczęśliwie Delphi pozbawia nas sporej dawki utrapień związanych z konstruowaniem tego typu interfejsów.

Zrozumieć COM

Nie można mówić o OLE i ActiveX nie wspominając o technologii COM.

COM (Component Object Model) to specyfikacja firmy Microsoft dotycząca tworzenia i implementacji komponentów wielokrotnego użytku.

„Komponenty? Myślałem, że Delphi korzysta z komponentów VCL”. Oczywiście komponenty VCL są najefektywniej wykorzystywanymi komponentami w Delphi – nie są one jednak jedyną możliwością. Twój obraz dotyczący współdziałania technologii COM i ActiveX z Delphi stanie się w najbliższym czasie bardziej klarowny.

Model COM stanowi podstawę dla obydwu specyfikacji – OLE i ActiveX. Analogią dla niego w środowisku VCL mogłaby być klasa TObject. Wszystkie klasy Object Pascala automatycznie dziedziczą właściwości i metody klasy TObject, a oprócz tego wprowadzają własne metody i właściwości zwiększając w ten sposób stopień swojej funkcjonalności. Podobnie, obiekty OLE i ActiveX są budowane na bazie modelu COM – COM jest fundamentem dla ActiveX i OLE.

Jako architektura komponentów, model COM posiada dwie podstawowe zalety:

u                                          Proces tworzenia obiektu COM nie zależy od języka programowania. (Obiekty COM mogą być pisane w wielu różnych językach programowania.)

u                                          Praktycznie rzecz biorąc, obiekt COM może być wykorzystany w dowolnym środowisku programistycznym Windows włączając w to Delphi, C++ Builder, Visual C++, Visual Basic, PowerBuilder, Visual dBASE i wiele innych.

 

Jedną z głównych wad modelu COM jest jego zbytnie przywiązanie do platformy WinTel (Windows/Intel). W związku z tym możliwość wykorzystania obiektu COM w wielu środowiskach programistycznych Windows niekoniecznie będzie oznaczała możliwość wykorzystania go w środowisku programistycznym np. Unixa. Od niedawna Microsoft próbuje przenieść model COM na platformy nie związane z Windows, ale kwestia ostatecznego osiągnięcia tego celu pozostaje nadal otwarta. Rozdział ten dotyczy jedynie specyfikacji COM i ActiveX egzystujących w ramach środowiska programistycznego Win32.

Do tworzenia obiektów COM można wykorzystywać wiele języków i środowisk programistycznych (Delphi, C++ Builder, Visual C++, Visual Basic i prawdopodobnie wiele innych). Po utworzeniu obiekt COM może zostać użyty w jeszcze szerszym kręgu środowisk projektowych. Obiekt COM wykreowany w Delphi może zostać użyty przez programistów pracujących w środowiskach Visual Basic, C++ Builder lub nawet Visual dBASE, czy PowerBuilder.

Obiekt COM jest zazwyczaj przechowywany w bibliotece DLL. Biblioteka może nosić rozszerzenie .DLL lub – równie dobrze – .OCX. Pojedynczy plik biblioteki (DLL lub OCX) może zwierać jeden lub kilka obiektów COM.

Terminologia COM

Terminologia związana z COM jest pełna zawiłych pojęć. Poniższe sekcje tłumaczą niektóre z terminów stosowanych w specyfikacji COM, a także wyjaśniają, w jaki sposób liczne elementy modelu COM pasują do siebie. Wszystkie te elementy są ze sobą wzajemnie powiązane, dlatego będziesz musiał przeczytać całą sekcję aby otrzymać obraz całości.

Obiekty COM

 

Obiekt COM jest fragmentem kodu binarnego, który wykonuje określoną funkcję.

Obiekt COM ujawnia aplikacji pewne metody, dając jej w ten sposób dostęp do swojej funkcjonalności. Dostęp do tych metod następuje poprzez tzw. interfejsy COM. Obiekt COM może zawierać tylko jeden lub kilka interfejsów. Z punktu widzenia programisty obiekty COM zachowują się w sposób przypominający klasy Object Pascala.

Interfejsy COM

 

Interfejs COM jest środkiem, poprzez który użytkownik obiektu COM uzyskuje dostęp do jego funkcjonalności.

Interfejs COM pozwala na dostęp do obiektu COM – na jego używanie. W efekcie interfejs COM reklamuje to, co obiekt COM ma do zaoferowania. Obiekt COM może posiadać tylko jeden interfejs, może również posiadać ich kilka. Dodatkowo pojedynczy interfejs może implementować jeden lub kilka dodatkowych interfejsów COM.

Nazwy interfejsów zwyczajowo zaczynają się od litery I. Przykładowo, powłoka Windows implementuje interfejsy o nazwach IShellLink, IShellFolder i IShellExtInit.

Nic nie stoi na przeszkodzie, aby zastosować dowolną konwencję nazewnictwa, jednak znajdująca się na czele litera I w sposób uniwersalny i natychmiastowy identyfikuje klasę jako interfejs COM.

Interfejsy COM są zarządzane w całości przez Windows zgodnie z tzw. identyfikatorami interfejsu (IID). IID jest wartością liczbową, zawartą w strukturze danych (rekordzie) i identyfikującą interfejs w sposób jednoznaczny.

Klasy COM

 

Klasa COM (czasem określana jako ko-klasa – ang. coclass) jest klasą, która zawiera jeden lub więcej interfejsów COM.

 

Nie ma możliwości uzyskania bezpośredniego dostępu do interfejsu COM. Zamiast tego, należy skorzystać z klasy COM. Klasa COM zawiera generator klas, który tworzy żądany interfejs i zwraca wskaźnik do niego. Klasy COM są identyfikowane przez identyfikatory klas (CLSID). CLSID, podobnie jak IID, jest wartością liczbową identyfikującą klasę COM w sposób unikalny.

GUID

Obiekty COM muszą być zarejestrowane w Windows. To właśnie w tym miejscu swoją rolę odgrywają identyfikatory CLSID i IID. W rzeczywistości CLSID i IID to dwie różne nazwy określające tę samą bazową strukturę danych: unikalny identyfikator globalny (GUID – ang. Globally Unique Identifier).

 

GUID jest 128 bitową (16 bajtową) wartością.

Identyfikatory GUID są tworzone przy pomocy funkcji biblioteki COM o nazwie CoCreateGUID. Funkcja ta w celu utworzenia identyfikatora GUID używa kombinacji informacji o specyficznym komputerze, losowo wygenerowanej liczby, a także czasu. Chociaż istnieje możliwość, że CoCreateGUID wygeneruje dwa jednakowe identyfikatory, jest ona wysoce nieprawdopodobna (bliska statystycznej niemożliwości).

Na szczęście, programiści Delphi nie muszą martwić się o identyfikatory GUID. Delphi tworzy taki identyfikator automatycznie gdy utworzony zostanie nowy obiekt automatyzacji, COM, ActiveX lub kontrolka formularza aktywnego. Identyfikatory GUID są definiowane w Delphi poprzez rekord TGUID. TGUID został zadeklarowany w module System.pas w sposób następujący:

 

TGUID = record

              D1 : Integer;

              D2 : Word;

              D2 : Word;

              D4 : array[0..7] of Byte;

end;

W chwili utworzenia przez nas obiektu COM, Delphi automatycznie tworzy identyfikator GUID. Dla przykładu, poniżej znajduje się identyfikator GUID dla stworzonego przeze mnie obiektu COM:

 

Class_Test: TGUID = '{F34107A1-ECCF-11D1-B47A-0040052A81F8}';

Ponieważ identyfikatory GUID są obsługiwane przez Delphi, nie wymagają zazwyczaj zbytniego zainteresowania z naszej strony. Sytuacja zmienia jednak postać rzeczy w przypadku, gdy zajmiemy się tworzeniem i użytkowaniem obiektów COM (włączając w to kontrolki ActiveX).

 

Delphi umożliwia wygenerowanie na żądanie unikalnego identyfikatora GIUD – należy w tym celu nacisnąć kombinację klawiszy Ctrl+Shift+G, w wyniku czego identyfikator zostanie wpisany w miejscu aktualnej pozycji kursora.

Biblioteki typu

Obiekt COM często korzysta z biblioteki typu.

 

Biblioteka typu to specjalny plik zawierający informacje o obiekcie COM, w skład których wchodzą listy właściwości, metod, interfejsów, struktur i innych elementów, które zawiera kontrolka. Biblioteka typu udostępnia również informacje na temat typów danych każdej właściwości oraz typu zwracanego przez metody, a także parametrów metod obiektu.

Do informacji zawartych w tym pliku zaliczają się również typy danych w obiekcie, metody i właściwości obiektu, dane o wersji, interfejsy obiektu, itd. Biblioteki mogą być zawarte w obiekcie COM jako zasoby lub mogą stanowić samodzielny plik. Pliki bibliotek typu posiadają rozszerzenie .TLB. Biblioteka typu jest niezbędna, jeżeli stworzone przez nas obiekty COM będą wykorzystywane jako komponenty aplikacji tworzonych przez innych programistów. Biblioteka typu obiektu COM zawiera więcej informacji niż jest w stanie dostarczyć proste zapytanie obiektu o jego interfejsy. Dla przykładu, środowisko Delphi używa informacji znalezionej w bibliotekach typu do wyświetlenia kontrolek ActiveX na Palecie Komponentów. Użytkownicy obiektu COM mogą przeanalizować bibliotekę typu, aby dokładnie określić, jakie metody i interfejsy zawiera ten obiekt.

DCOM

Rozproszona technologia COM, w oryginale nazywana Distributed COM (DCOM), jest podzbiorem specyfikacji COM umożliwiającym korzystanie z obiektów COM poprzez sieci lokalne lub Internet. DCOM rozszerza model COM przez udostępnienie mechanizmu pozwalającego na użytkowanie modelu COM w otoczeniu sieciowym. Dokładne omówienie mechanizmu DCOM przekracza możliwości tej książki, należy jednak zwrócić uwagę na fakt, iż model DCOM jest powszechny w niektórych typach programowania sieciowego.

 

Technologią konkurencyjną w stosunku do DCOM jest CORBA (ang. Common Object Request Broker Architecture). CORBA jest niezależna od platformy, co czyni ją wielce atrakcyjną. Ponadto CORBA posiada architekturę otwartą wspieraną przez konsorcjum firm wytwarzających oprogramowanie (w przeciwieństwie do specyfikacji DCOM, będącej samodzielnym rozwiązaniem firmy Microsoft). Na szczęście, Delphi daje możliwość tworzenia obu typów obiektów – DCOM i CORBA.

...

Zgłoś jeśli naruszono regulamin