6.32. Tworzenie serwerów automatyzacji ActiveX z użyciem MFC

[ Pobierz całość w formacie PDF ]
.12.Listing 32.12.Implementacja obs�ugi dzielenia serwera CTracker//.EnableAutomation ( ) ;// upewniamy si�, �e aplikacja nie zostanie wy�adowana przed // wyzerowaniem licznika odwo�a� : :Afx01eLockApp( ) ;// zerujemy sk�adow� m_dwRegister = NULL;// QI dla lUnknown = pami�tajmy, �e bez AddRef LPUNKNOWN plUnknown = this->Get!nterface ( &IID_IUnknown) ;// je�li mamy lUnknownif (plUnknown){// rejestrujemy clsid jako aktywny obiekt, dzi�ki czemu // inne aplikacje otrzymaj� ten sam obiekt if (: :RegisterActiveObject (plUnknown, CLSID_TRACKER, ACTIVEOBJECT_STRONG, &m_dwRegister ) != S_OK) // zerujemy odwo�anie m_dwRegister = NULL;}// ustawiamy rozdzielczo�� timeram_lTimeBegin = timeBeginPeriod (1) ;m IHiResTime = m ILastHiResTime = timeGetTime//.W naszej implementacji pierwszym krokiem jest wyzerowanie zmiennej sk�adowej.Implementacja jest zale�na od tej zmiennej przy sprawdzaniu, czy serwer zosta� poprawnie zarejestrowany jako dzia�aj�cy.Nast�pnie musimy pobra� interfejs lUnknown obiektu i, je�li to si� powiedzie, przekaza� go wraz z adresem zmiennej sk�adowej do funkcji RegisterActiveObject ().Wymagamy �mocnej" rejestracji, powoduj�cej dodatkowe zwi�kszenie liczby odwo�a� do serwera w celu utrzymania go w pami�ci.Je�li nie powiod�o si� zarejestrowanie serwera, dla pewno�ci i tak zerujemy zmienn� sk�adow�.Ostatnim krokiem jest wywo�anie funkcji RevokeActiveObject () w celu usuni�cia serwera z tablicy dzia�aj�cych obiektów.Ten krok jest najbardziej krytycznym aspektem obs�ugi dzielonych obiektów.Nie nale�y jednak dodawa� tego kodu do destruktora serwera, gdy� nigdy nie zostanie wywo�any.Destruktor jest wywo�ywany w odpowiedzi na niszczenie serwera, nast�puj�ce w momencie, gdy licznik odwo�a� do serwera osi�gnie zero.Jednak poniewa� w wywo�aniu RegisterActiveObject () za��dali�my dodatkowego zwi�kszenia licznika odwo�a�, licznik nigdy nie osi�gnie tego stanu.W celu zapewnienia poprawnego usuni�cia serwera z tabeli najlepiej jest zaimplementowa� ponownie funkcj� ReleaseO interfejsu lUnknown serwera, dzi�ki której b�dzie mo�na monitorowa� licznik odwo�a� do serwera.Implementacja funkcji Release () usuwaj�cej obiekt z tablicy dzia�aj�cych obiektów zosta�a przedstawiona na listingu 32.13.Listing 32.13.Implementacja funkcji Release()//.ULONG FAR EXPORT CTracker::KSubDispatch::Release(} {METHOD_PROLOGUE(CTracker, SubDispatch)// wywo�anie funkcji i sprawdzenie licznika odwo�a� long IRefCount = pThis->ExternalRelease();// gdy jeste�my zarejestrowani jako dzia�aj�cy serwer// i jest to jedyne odwo�anieif(pThis->m_dwRegister && IRefCount == 1){// zwi�kszamy licznik odwo�a�, aby�my si� nie zniszczyli// przed zako�czeniem funkcjipThis->ExternalAddRef();// pobieramy identyfikator rejestracji DWORD tdwRegister = pThis->m_dwRegister;// zerujemy zmienn� sk�adow�, aby zabezpieczy� si� przed // ponownym wywo�aniem tej metody pThis->m_dwRegister = 0;// usuwamy interfejs z tablicy dzia�aj�cych obiektów ::RevokeActiveObject(tdwRegister, NULL);// To wywo�anie powinno zniszczy� nasz serwer, wi�c // musimy zmniejszy� licznik odwo�a�, return pThis->ExternalRelease();}// wyj�cie return IRefCount;}//.Za ka�dym razem gdy program wywo�uje funkcj� Release (), zaczyna ona dzia�anie od zmniejszenia licznika odwo�a� do obiektu i zachowania zwróconej warto�ci.Nast�pnie funkcja sprawdza, czy serwer zosta� zarejestrowany jako dzia�aj�cy (o zarejestrowaniu serwera �wiadczy niezerowa warto�� zmiennej sk�adowej).Funkcja sprawdza tak�e, czy licznik odwo�a� ma warto�� 1.Je�li tak, oznacza to, �e serwer jest gotów do usuni�cia, gdy� jedyn� aplikacj�, która si� do niego odwo�uje, jest tablica dzia�aj�cych obiektów.Jednak przed wywo�aniem funkcji RevokeActiveObject () wa�ne jest, by zwi�kszy� licznik odwo�a� i wyzerowa� zmienn� sk�adow�.Funkcja RevokeActiveObject () re-kursywnie wywo�uje funkcj� Release (), a nie chcemy, by serwer zosta� natychmiast zniszczony (gdy� spowodowa�oby to naruszenie pami�ci i za�amanie programu).Po powrocie z funkcji RevokeActiveObject () wywo�ujemy ostatni raz funkcj� Release (), aby rzeczywi�cie zniszczy� serwer i usun�� go z pami�ci.W czasie istnienia serwera mo�emy otrzymywa� ten sam egzemplarz serwera i u�ywa� go w wielu ró�nych aplikacjach.W Visual Basicu do pobierania dzia�aj�cego egzemplarza serwera s�u�y funkcja Getobject (), za� w Yisual C++ funkcja GetActiveObject ().Gdy kontener otrzyma wska�nik do serwera, mo�e z niego korzysta� tak, jakby utworzy� go poprzez standardowe mechanizmy OLE.Ta metoda dzielenia obiektów jest poprawna, lecz wymaga, by aplikacja korzystaj�ca z serwera bra�a czynn� rol� w decydowaniu, czy powinna korzysta� ze wspólnego obiektu czy te� stworzy� w�asny obiekt.Mo�na przyj�� inne podej�cie: mo�esz dostarczy� egzemplarz dzia�aj�cego serwera aplikacji wywo�uj�cej funkcj� CreateObject (), zamiast polega� na wywo�aniu przez aplikacj� funkcji Getobject o.Taki serwer jest nazywany serwerem w pojedynczym egzemplarzu, gdy� programy kontenerów nie mog� tworzy� wi�cej ni� pojedynczy egzemplarz obiektu.Serwer w pojedynczym egzemplarzuAby stworzy� serwer w pojedynczym egzemplarzu, konieczne jest wykonanie wszystkich kroków opisanych w poprzedniej sekcji, �Tworzenie dzielonych serwerów", lecz nie z wn�trza samej implementacji serwera, ale poprzez fabryk� klas dla serwera.Implementuj�c obiekt dzielenia serwera wewn�trz fabryki klas, jeste�my w stanie kontrolowa� ilo�� egzemplarzy obiektu bez konieczno�ci opierania si� na dobrej woli aplikacji korzystaj�cych z serwera.Niestety, MFC nie umo�liwia w prosty sposób dost�pu do klasy coieObjectFactory, odpowiedzialnej za tworzenie serwerów OLE i umo�liwiaj�cej ten rodzaj implementacji.Jednak dzi�ki dziedziczeniu klas C++ mo�emy stworzy� now�, specjaln� wersj� klasy coieObjectFactory obs�uguj�c� dzielenie egzemplarzy serwera.W celu umo�liwienia obs�ugi dzielenia serwera musimy doda� dwa makra do deklaracji i implementacji klasy serwera.W pliku �ród�owym serwera makro DECLARE_OLECREATE_SHARED musi zast�pi� makro DECLARE_OLECREATE, za� makro IMPLEMENT_OLECREATE musi by� zast�pione makrem IMPLEMENT_OLECREATE_SHARED.Jedyna ró�nica w nowych makrach polega na tym, �e do serwera zamiast klasy coieObjectFactory jest dodawana klasa coieObjectFactoryShared.Tworzenie kodu obs�uguj�cego serwer w pojedynczym egzemplarzu jest podobne do tworzenia kodu obs�uguj�cego normalny dzielony serwer.Kod implementuj�cy serwer w pojedynczym egzemplarzu jest zawarty w plikach sharedobject.cpp oraz sharedobject.h umieszczonych na do��czonej do ksi��ki p�ytce CD-ROM, w kartotece Rozdz32\MFCServer.PodsumowanieW tym rozdziale nauczy�e� si� tworzy� podstawow� implementacj� serwera automatyzacji MFC.Nauczy�e� si� równie� rozbudowywa� podstawowy szkielet dostarczony przez MFC o nowe, interesuj�ce elementy implementacji.Do innych obszarów implementacji serwera, które mo�na rozbudowa�, nale�y dodawanie do serwera interfejsu u�ytkownika, tak�e w formie okien dialogowych oraz interfejsów zdarze�.U�ycie standardowych okien dialogowych MFC sprawia, �e implementacja interfejsu u�ytkownika jest �atw� i przyjemn� cz�ci� implementacji.Jednak obecnie �adna z aplikacji kontenera nie potrafi skorzysta� z �adnego z takich elementów serwera.Je�li aplikacja ma takie wymagania, musisz sam okre�li�, jak je zaimplementowa�.Mo�liwo�� tworzenia us�ug i zdalnych serwerów tak�e sprawia, �e tworzenie serwerów automatyzacji mo�e by� bardzo interesuj�ce.Ka�dego dnia coraz wi�cej programistów korzysta z automatyzacji i do��cza j� do podstawowych elementów swoich aplikacji.O ile dawniej przy wymianie danych mo�na by�o korzysta� tylko z mechanizmu DDE lub, co gorsza, z wymiany danych poprzez pliki, obecnie w ka�dej sytuacji wymagaj�cej przekazania danych pomi�dzy aplikacjami mo�na korzysta� z automatyzacji OLE [ Pobierz całość w formacie PDF ]

�

download / ebook / pobieranie / pdf / do ÂściÂągnięcia

Odnośniki