Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Aktywny kontener dokumentów, taki jak Microsoft Office Binder lub Internet Explorer, umożliwia pracę z kilkoma dokumentami różnych typów aplikacji w ramach jednej ramki (zamiast wymuszać tworzenie i używanie wielu ramek aplikacji dla każdego typu dokumentu).
Usługa MFC zapewnia pełną obsługę aktywnych kontenerów dokumentów w COleDocObjectItem
klasie . Kreatora aplikacji MFC można użyć do utworzenia aktywnego kontenera dokumentów, zaznaczając pole wyboru Aktywny kontener dokumentów na stronie Obsługa dokumentów złożonych Kreatora aplikacji MFC. Aby uzyskać więcej informacji, zobacz Tworzenie aktywnej aplikacji kontenera dokumentów.
Aby uzyskać więcej informacji na temat aktywnych kontenerów dokumentów, zobacz:
Wymagania dotyczące kontenera
Obsługa aktywnego dokumentu w aktywnym kontenerze dokumentów oznacza więcej niż tylko implementacje interfejsu: wymaga również znajomości interfejsów zawartego obiektu. Dotyczy to również aktywnych rozszerzeń dokumentów, w których kontener musi również wiedzieć, jak używać tych interfejsów rozszerzeń w samych aktywnych dokumentach.
Aktywny kontener dokumentów, który integruje aktywne dokumenty, musi:
Być w stanie obsługiwać magazyn obiektów za pośrednictwem interfejsu
IPersistStorage
, czyli musi dostarczyć instancjęIStorage
do każdego aktywnego dokumentu.Wspieranie podstawowych funkcji osadzania dokumentów OLE, co wymaga obiektów "witryny" (jednego na dokument lub osadzanie), które implementują
IOleClientSite
iIAdviseSink
.Obsługa aktywacji na miejscu obiektów osadzonych lub aktywnych dokumentów. Obiekty witryny kontenera muszą implementować
IOleInPlaceSite
, a obiekt ramki kontenera musi udostępniaćIOleInPlaceFrame
.Wspieraj rozszerzenia aktywnych dokumentów poprzez zaimplementowanie
IOleDocumentSite
w celu zapewnienia mechanizmu, który umożliwia kontenerowi komunikację z dokumentem. Opcjonalnie kontener może implementować interfejsy aktywnego dokumentuIOleCommandTarget
iIContinueCallback
w celu obsługi prostych poleceń, takich jak drukowanie lub zapisywanie.
Obiekt ramki, obiekty widoku i obiekt kontenera można opcjonalnie zaimplementować IOleCommandTarget
w celu obsługi wysyłania określonych poleceń, zgodnie z opisem w temacie Command Targets (Obiekty docelowe poleceń). Obiekty widoku i kontenera mogą również opcjonalnie implementować IPrint
i IContinueCallback
, aby obsługiwać drukowanie programowe, zgodnie z opisem w temacie Drukowanie programowe.
Na poniższej ilustracji przedstawiono relacje koncepcyjne między kontenerem a jego składnikami (po lewej) oraz aktywnym dokumentem i jego widokami (po prawej stronie). Aktywny dokument zarządza przechowywaniem i danymi, a widok wyświetla lub opcjonalnie drukuje te dane. Interfejsy pogrubione są wymagane do aktywnego uczestnictwa w dokumencie; te pogrubienie i kursywa są opcjonalne. Wszystkie inne interfejsy są wymagane.
Dokument obsługujący tylko jeden widok może implementować zarówno składniki widoku, jak i dokumentu (czyli odpowiadające im interfejsy) w pojedynczej klasie. Ponadto witryna kontenera, która obsługuje tylko jeden widok jednocześnie, może połączyć witrynę dokumentu i witrynę widoku w jedną konkretną klasę witryny. Obiekt ramki kontenera musi jednak pozostać odrębny, a składnik dokumentu kontenera jest jedynie uwzględniony w tym miejscu, aby przedstawić pełny obraz architektury; nie ma to wpływu na architekturę zawierania dokumentów aktywnych.
Obiekty witryny dokumentu
W architekturze zawierającej aktywny dokument lokacja dokumentu jest taka sama jak obiekt lokacji klienta w dokumentach OLE z dodatkiem interfejsu IOleDocument
:
interface IOleDocumentSite : IUnknown
{
HRESULT ActivateMe(IOleDocumentView *pViewToActivate);
}
Witryna dokumentu jest koncepcyjnie kontenerem dla co najmniej jednego obiektu "wyświetl witrynę". Każdy obiekt witryny widoku jest skojarzony z poszczególnymi obiektami widoku dokumentu zarządzanymi przez witrynę dokumentu. Jeśli kontener obsługuje tylko jeden widok na każde miejsce dokumentu, może zaimplementować zarówno miejsce dokumentu, jak i miejsce widoku przy użyciu pojedynczej klasy.
Wyświetlanie obiektów witryny
Obiekt widoku witryny kontenera zarządza przestrzenią wyświetlania dla określonego widoku dokumentu. Oprócz obsługi standardowego IOleInPlaceSite
interfejsu, witryna widoku zwykle implementuje również IContinueCallback
dla kontroli drukowania programatycznego. (Należy pamiętać, że obiekt widoku nigdy nie wykonuje zapytań do IContinueCallback
, więc można go zaimplementować w dowolnym obiekcie, którego chce kontener).
Kontener, który obsługuje wiele widoków, powinien móc tworzyć wiele obiektów strony widoku w obszarze dokumentu. Każdemu widokowi są zapewniane oddzielne usługi aktywacji i dezaktywacji dostępne za pośrednictwem IOleInPlaceSite
.
Element ramki
Obiekt ramki kontenera to w dużej mierze ta sama ramka, która jest używana do aktywacji w miejscu w dokumentach OLE, czyli ramka obsługująca negocjacje menu i paska narzędzi. Obiekt widoku ma dostęp do tego obiektu ramki za pośrednictwem IOleInPlaceSite::GetWindowContext
, który również zapewnia dostęp do obiektu kontenera reprezentującego dokument kontenera (może on obsługiwać negocjacje dotyczące paska narzędzi na poziomie okienka oraz enumerację zawartych obiektów).
Aktywny kontener dokumentów może rozszerzyć ramkę, dodając IOleCommandTarget
element. Dzięki temu system może odbierać polecenia pochodzące z interfejsu użytkownika aktywnego dokumentu w taki sam sposób, jak ten interfejs może umożliwić kontenerowi wysyłanie tych samych poleceń (takich jak Plik nowy, Otwórz, Zapisz jako, Drukuj, Edytuj: Kopiuj, Wklej, Cofnij i inne). Aby uzyskać więcej informacji, zobacz cele poleceń.