Udostępnij za pośrednictwem


TN025: tworzenie dokumentów, widoków i ramek

Uwaga

Następująca uwaga techniczna nie została zaktualizowana, ponieważ została po raz pierwszy uwzględniona w dokumentacji online. W związku z tym niektóre procedury i tematy mogą być nieaktualne lub nieprawidłowe. Aby uzyskać najnowsze informacje, zaleca się wyszukanie interesującego tematu w indeksie dokumentacji online.

Ta uwaga zawiera opis problemów z tworzeniem i własnością aplikacji WinApps, DocTemplates, dokumentów, ramek i widoków.

WinApp

W systemie znajduje się jeden CWinApp obiekt.

Jest on statycznie skonstruowany i zainicjowany przez wewnętrzną implementację platformy WinMain. Musisz pochodzić z CWinApp , aby wykonać wszystko przydatne (wyjątek: biblioteki DLL rozszerzeń MFC nie powinny mieć CWinApp wystąpienia — inicjowanie jest wykonywane w DllMain zamian).

CWinApp Jeden obiekt jest właścicielem listy szablonów dokumentów (a CPtrList). Istnieje co najmniej jeden szablon dokumentu na aplikację. DocTemplates są zwykle ładowane z pliku zasobu (czyli tablicy ciągów) w pliku CWinApp::InitInstance.

pTemplate = new CDocTemplate(IDR_MYDOCUMENT, ...);

AddDocTemplate(pTemplate);

Jeden CWinApp obiekt jest właścicielem wszystkich okien ramek w aplikacji. Główne okno ramki dla aplikacji powinno być przechowywane w CWinApp::m_pMainWndpliku ; zwykle ustawia się m_pMainWnd w InitInstance implementacji, jeśli nie zezwalasz aplikacji AppWizard zrobić to za Ciebie. W przypadku interfejsu pojedynczego dokumentu (SDI) jest to jeden CFrameWnd , który służy jako główne okno ramki aplikacji, a także jedyne okno ramki dokumentu. W przypadku wielu interfejsów dokumentów (MDI) jest to ramka MDI-Frame (klasa CMDIFrameWnd), która służy jako główne okno ramki aplikacji zawierające wszystkie elementy podrzędne CFrameWnd. Każde okno podrzędne jest klasą CMDIChildWnd (pochodną CFrameWnd) i służy jako jedno z potencjalnie wielu okien ramek dokumentów.

DocTemplates

Jest CDocTemplate twórcą i menedżerem dokumentów. Jest właścicielem tworzonych dokumentów. Jeśli aplikacja korzysta z opisanego poniżej podejścia opartego na zasobach, nie będzie musiała pochodzić z metody CDocTemplate.

W przypadku aplikacji SDI klasa CSingleDocTemplate śledzi jeden otwarty dokument. W przypadku aplikacji MDI klasa CMultiDocTemplate przechowuje listę (a CPtrList) wszystkich aktualnie otwartych dokumentów utworzonych na podstawie tego szablonu. CDocTemplate::AddDocument i CDocTemplate::RemoveDocument udostępniają wirtualne funkcje członkowskie do dodawania lub usuwania dokumentu z szablonu. CDocTemplate jest przyjacielem CDocument , dzięki czemu możemy ustawić chroniony CDocument::m_pDocTemplate wskaźnik wsteczny, aby wskazywał z powrotem na szablon dokumentu, który utworzył dokument.

CWinApp obsługuje domyślną OnFileOpen implementację, która z kolei będzie wykonywać zapytania względem wszystkich szablonów dokumentów. Implementacja obejmuje wyszukiwanie już otwartych dokumentów i podejmowanie decyzji o formacie otwierania nowych dokumentów.

CDocTemplate zarządza powiązaniem interfejsu użytkownika dla dokumentów i ramek.

CDocTemplate przechowuje liczbę nienazwanych dokumentów.

Cdocument

Element jest CDocument własnością .CDocTemplate

Dokumenty mają listę aktualnie otwartych widoków (pochodzących z CViewprogramu ), które wyświetlają dokument (a CPtrList).

Dokumenty nie tworzą/nie niszczą widoków, ale są one dołączane do siebie po ich utworzeniu. Po zamknięciu dokumentu (czyli za pośrednictwem pliku/zamknięcia), wszystkie dołączone widoki zostaną zamknięte. Po zamknięciu ostatniego widoku dokumentu (tj. oknie/zamknięciu) dokument zostanie zamknięty.

RemoveView Interfejs CDocument::AddViewsłuży do obsługi listy widoków. CDocument jest przyjacielem CView , więc możemy ustawić CView::m_pDocument wskaźnik wstecz.

CFrameWnd

Klasa CFrameWnd (znana również jako ramka) odgrywa taką samą rolę jak w MFC 1.0, ale teraz CFrameWnd klasa jest przeznaczona do użycia w wielu przypadkach bez wyprowadzania nowej klasy. Klasy CMDIFrameWnd pochodne i CMDIChildWnd są również ulepszone tak wiele standardowych poleceń są już implementowane.

Obiekt CFrameWnd jest odpowiedzialny za tworzenie okien w obszarze klienta ramki. Zwykle istnieje jedno główne okno wypełniające obszar klienta ramki.

W przypadku okna ramka MDI obszar klienta jest wypełniony kontrolką MDICLIENT, która jest z kolei elementem nadrzędnym wszystkich okien ramowych MDI-Child. W przypadku okna ramki SDI lub okna ramowego MDI-Child obszar klienta jest zwykle wypełniony obiektem CView-pochodnego okna. W przypadku CSplitterWndprogramu obszar klienta widoku jest wypełniony CSplitterWnd obiektem okna, a CViewobiekty -pochodne okna (jeden na okienko podziału) są tworzone jako okna podrzędne obiektu CSplitterWnd.

Zobacz też

Uwagi techniczne według numerów
Uwagi techniczne według kategorii