Buforowanie widoku

Aplikacja kontenera musi mieć możliwość uzyskania prezentacji obiektu na potrzeby wyświetlania lub drukowania go dla użytkowników, gdy dokument jest otwarty, ale aplikacja serwera obiektu nie jest uruchomiona lub nie jest zainstalowana na komputerze użytkownika. Załóżmy jednak, że serwery dla wszystkich obiektów, które mogą zostać znalezione w dokumencie, są instalowane na maszynie każdego użytkownika i zawsze mogą być uruchamiane na żądanie, jest nierealne. Domyślna procedura obsługi obiektów, która jest dostępna przez cały czas, rozwiązuje ten dylemat, buforując prezentacje obiektów w magazynie dokumentu i manipulując tymi prezentacjami na dowolnej platformie niezależnie od dostępności serwera obiektów w dowolnej określonej instalacji kontenera.

Kontenery mogą obsługiwać prezentacje rysunkowe dla jednego lub więcej określonych urządzeń docelowych oprócz urządzenia wymaganego do utrzymania obiektu na ekranie. Ponadto w przypadku przenoszenia obiektu z jednej platformy do innej obiekt OLE automatycznie konwertuje formaty danych obiektu na te obsługiwane na nowej platformie. Jeśli na przykład przeniesiesz obiekt z systemu Windows do komputerów Macintosh, obiekt OLE przekonwertuje prezentacje metaplików na formaty PICT.

Aby przedstawić użytkownikowi dokładną reprezentację obiektu osadzonego, aplikacja kontenera obiektu inicjuje dialog z procedurą obsługi obiektów, żądając danych i instrukcji rysowania. Aby móc spełnić żądania kontenera, program obsługi musi zaimplementować interfejsy IDataObject, IViewObject2i IOleCache.

IDataObject umożliwia aplikacji kontenera OLE pobieranie danych z osadzonych lub połączonych obiektów i wysyłanie ich do ich obiektów. Gdy dane zmieniają się w obiekcie, ten interfejs umożliwia obiektowi udostępnienie nowych danych swojemu kontenerowi, a także zapewnia kontenerowi sposób na zaktualizowanie danych w jego kopii obiektu. (Ogólne omówienie transferu danych można znaleźć w rozdziale 4, Transfer danych).

Interfejs IViewObject2 jest bardzo podobny do interfejsu IDataObject, z wyjątkiem tego, że prosi obiekt o rysowanie się w kontekście urządzenia, na przykład ekranu, drukarki lub metapliku, a nie przenoszenia lub kopiowania danych do pamięci lub innego nośnika transferu. Celem interfejsu jest umożliwienie kontenerowi OLE uzyskania alternatywnych obrazowych reprezentacji swoich obiektów osadzonych, których dane już mają, unikając w ten sposób konieczności transferu całkowicie nowych wystąpień tych samych obiektów danych po prostu w celu uzyskania nowych instrukcji rysowania. Zamiast tego interfejs IViewObject2umożliwia kontenerowi zwrócenie się do obiektu o przedstawienie obrazowej reprezentacji siebie, rysując w kontekście urządzenia określonym przez kontener.

Podczas wywoływania interfejsu IViewObject2 aplikacja kontenera może również określić, że obiekt narysuje się na urządzeniu docelowym innym niż ten, na którym faktycznie będzie renderowany. Dzięki temu kontener może w razie potrzeby wygenerować różne renderowanie z pojedynczego obiektu. Na przykład wzywający może poprosić obiekt o dopasowanie się dla drukarki, mimo że ostateczny rysunek ma być wyświetlany na ekranie. Wynikiem będzie oczywiście podgląd wydruku obiektu.

Interfejs IViewObject2udostępnia również metody umożliwiające kontenerom rejestrowanie na potrzeby powiadomień o zmianie widoku. Podobnie jak w przypadku danych i porad OLE, połączenie z poradami dotyczącymi widoku umożliwia kontenerowi aktualizowanie renderowania obiektu według własnych potrzeb, a nie w odpowiedzi na wywołanie z obiektu. Jeśli na przykład nowa wersja aplikacji serwera obiektu miała oferować dodatkowe widoki tych samych danych, domyślna procedura obsługi obiektu wywoła implementację każdego kontenera IAdviseSink::OnViewChange, aby poinformować ich, że nowe prezentacje były dostępne. Kontener pobiera te informacje z modułu obsługi tylko wtedy, gdy jest to konieczne.

Ponieważ konteksty urządzeń z systemem Windows mają znaczenie tylko w ramach jednego procesu, nie można przekazać IViewObject2 wskaźników przez granice procesu. W związku z tym serwery lokalne i zdalne OLE nie muszą w ogóle implementować interfejsu, co nie działałoby prawidłowo, nawet jeśli tak się stało. Tylko programy obsługi obiektów i serwery przetwarzania implementują interfejs IViewObject2. OLE udostępnia domyślną implementację, której można używać we własnych zintegrowanych serwerach OLE i programach obsługi obiektów, po prostu poprzez agregację domyślnego programu obsługującego OLE. Możesz też napisać własną implementację IViewObject2.

Obiekt implementuje interfejs IOleCache, aby poinformować program obsługi o tym, jakie możliwości powinny być pamięciowane. Handler obiektów jest również właścicielem pamięci podręcznej i zapewnia, że jest ona aktualizowana na bieżąco. Gdy osadzony obiekt przechodzi w stan uruchomienia, moduł obsługi konfiguruje odpowiednie połączenia doradcze w obiekcie serwera, pełniąc funkcję odbiornika. Implementacje interfejsu IDataObject i IViewObject2działają na danych buforowanych po stronie klienta. Implementacja programu obsługi IViewObject2jest odpowiedzialna za określenie formatów danych do zapasowywania w celu spełnienia żądań rysowania klienta. Implementacja programu obsługi IDataObject odpowiada za uzyskiwanie danych w różnych formatach i przenoszenie ich między pamięcią a bazowym IStorage wystąpieniem obiektu osadzonego. Niestandardowe programy obsługi mogą używać tych implementacji poprzez agregowanie na domyślnym programie obsługi.

Tematy pokrewne

Dokumenty złożone