DLLHUSK-Beispiel: Verknüpft die MFC-Bibliothek dynamisch

  • Artikel

Aktualisiert: November 2007

Das DLLHUSK-Beispiel verknüpft die MFC-Bibliothek dynamisch mit Anwendungen und benutzerdefinierten Dynamic Link Libraries (DLL), die denselben Klassenbibliothekscode verwenden. Auf diese Weise wird der durch die Ausführung mehrerer Anwendungen benötigte Speicherbedarf reduziert.

Dynamische Verknüpfungen stellen zudem weitere mögliche Anwendungsarchitekturen bereit, in denen Teile der Anwendung in einer benutzerdefinierten DLL implementiert werden und sowohl die Anwendung als auch die benutzerdefinierte DLL die MFC-DLL (Mfcxx.dll) gemeinsam nutzen. Eine benutzerdefinierte DLL, die Frameworkfunktionen gemeinsam mit einer Anwendung nutzt, wird als MFC-Erweiterungs-DLL bezeichnet.

Sicherheitshinweis:

Dieser Beispielcode dient dazu, ein Konzept zu veranschaulichen. Er sollte nicht für Anwendungen oder Websites verwendet werden, da dieser Code unter Umständen nicht die sicherste Codierungstechnik darstellt. Microsoft übernimmt keine Haftung für beiläufig entstandene Schäden oder Folgeschäden, falls der Beispielcode nicht bestimmungsgemäß verwendet wird.

So rufen Sie Beispiele und Anweisungen für ihre Installation ab

  • Klicken Sie in Visual Studio im Menü Hilfe auf Beispiele.

    Weitere Informationen finden Sie unter Suchen von Beispieldateien.

  • Die neueste Version und vollständige Liste mit Beispielen ist online unter Visual Studio 2008 Samples verfügbar.

  • Sie können auch Beispiele auf der Festplatte des Computers suchen. Standardmäßig werden Beispiele und eine Infodatei in einen Ordner unter \Programme\Visual Studio 9.0\Samples\ kopiert. Für Express Editions von Visual Studio sind alle Beispiele online verfügbar.

Erstellen und Ausführen des Beispiels

So erstellen Sie das DLLHUSK-Beispiel und führen es aus

  1. Öffnen Sie die Projektmappe dllhusk.sln.

  2. Klicken Sie im Menü Erstellen auf Erstellen.

  3. Klicken Sie im Menü Debuggen auf Starten ohne Debuggen.

Die Projektmappe DLLHUSK erstellt sowohl die Anwendung Dllhusk.exe als auch die beiden DLLs (TESTDLL1.DLL und TESTDLL2.DLL), mit denen die Anwendung dynamisch verknüpft ist. DLLHUSK benötigt MFCxx.DLL oder MFCxxD.DLL zur Laufzeit. Diese DLLs werden standardmäßig in das Windows-Systemverzeichnis installiert.

MFC-Erweiterungs-DLLs in DLLHUSK

DLLHUSK veranschaulicht MFC-Erweiterungs-DLLs mit Klassenexport. C++-Klassen in den DLLs (Testdll1.dll und Testdll2.dll) werden mithilfe des Makros AFX_EXT_CLASS exportiert. In der ersten MFC-Erweiterungs-DLL (TESTDLL1) wird auf alle C++-Klassenschnittstellen der benutzerdefinierten DLL nur über das Framework zugegriffen, nicht direkt über die Anwendung. Die benutzerdefinierte DLL exportiert nur externe "C"-Funktionen in die Anwendung. Die benutzerdefinierte DLL muss nicht die Funktionen der von Frameworkklassen abgeleiteten Klassen exportieren. Alle Aufrufe vom Framework an abgeleitete Klassen in der benutzerdefinierten DLL werden über die virtuellen C++-Funktionen aufgelöst.

In der zweiten MFC-Erweiterungs-DLL (TESTDLL2) werden einige C++-Klassenschnittstellen der benutzerdefinierten DLL direkt in die Anwendung exportiert, wo auch der Zugriff darauf erfolgt.

Testdll1.dll

Testdll1.dll bietet die Implementierung für DLLHUSK-Dokument- und Ansichtsklassen für beide Dokumenttypen (den TEXT-Dokumenttyp sowie den HELLO-Dokumenttyp). Dllhusk.exe implementiert die MDI-Rahmenfensterklasse, und das Framework implementiert die untergeordnete Fensterklasse (CMDIChildWnd) der mehrfachen Dokumentschnittstelle (MDI). Zwei Dokumentvorlagenobjekte richten die Zuordnungen zwischen CTextDoc, CMDIChildWnd und CEditView sowie zwischen CDummyDoc, CMDIChildWnd und CHelloView ein. DLLHUSK veranschaulicht daher, dass das Framework die Beziehung zwischen vom Framework definierten Objekten auch dann koordinieren kann, wenn die Klassen für diese Objekte in der Anwendung, der benutzerdefinierten (MFC-Erweiterungs-)DLL und der Mfcxx.dll des Frameworks implementiert sind.

TESTDLL1 ruft schließlich zweimal die AddDocTemplate-Memberfunktion des Anwendungsobjekts auf, um die beiden Dokumentvorlagenobjekte zu registrieren. Dies geschieht bei der Implementierung der InitTestDLL1-Funktion von TESTDLL1, der einzigen von TESTDLL1 exportierten Funktion. Diese Funktion wird mit extern "C" deklariert, sodass die DLLHUSK-Anwendung diese als eigenständige C-Funktion aufrufen kann.

Die Testdll1.h-Headerdatei (hinzugefügt als #include durch Dllhusk.cpp) beinhaltet nicht nur die Deklarierung von InitTestDLL1, sondern auch die Deklarierungen der TESTDLL1-Klassen. Dllhusk.cpp bezieht sich direkt nur auf die InitTestDLL1-Funktion. DLLHUSK hingegen verwendet direkt die in Testdll.dll implementierten Dokument- und Ansichtsklassen.

Testdll2.dll

Testdll2.dll stellt die Implementierungen für die CListOutputFrame-Klasse von DLLHUSK bereit. Wenn die Benutzer über das Kontextmenü einen Diagnosebefehl aufrufen, erstellt die Anwendung ein CListOutputFrame-Objekt und sendet anschließend durch Aufruf von CListOutputFrame::AddString Diagnosemeldungen an das Listenausgabefenster.

Alle öffentlichen Memberfunktionen von CListOutputFrame werden in die Datei Testdll2.def exportiert. Der Export beinhaltet nicht nur AddString, sondern auch den öffentlichen CListOutputFrame-Konstruktor und -Destruktor.

Es ist schwieriger, eine MFC-Erweiterungs-DLL zu implementieren, die Klassenmemberfunktionen exportiert, als eine, die nur C-Funktionen exportiert. Dies liegt vor allem daran, dass Sie die Exporte der C++-Funktion mit dem ergänzten Namen manuell zur DEF-Datei der DLL hinzufügen müssen. Ein Verfahren hierfür finden Sie unter Technischer Hinweis 33.

Weitere DLLHUSK-Features

DLLHUSK veranschaulicht darüber hinaus Folgendes:

  • Aufteilen mehrerer Ressourcen für eine einzelne Anwendung in mehrere RC-Dateien, die im Visual C++-Ressourcen-Editor bearbeitet werden können.

  • Verwenden der beiden Diagnosefunktionen AfxDoForAllClasses und AfxDoForAllObjects.

  • Enumeration von CDynLinkLibrary-Objekten.

Schlüsselwörter

Dieses Beispiel demonstriert die Verwendung der folgenden Schlüsselwörter:

AfxDoForAllClasses; AfxDoForAllObjects; AfxGetApp; AfxGetResourceHandle; AfxMessageBox; AfxSetResourceHandle; AfxThrowMemoryException; CCmdUI::SetCheck; CColorDialog::DoModal; CColorDialog::GetColor; CDC::DrawText; CDC::SetBkColor; CDC::SetTextColor; CDialogBar::Create; CDocTemplate::GetDocString; CEditView::SerializeRaw; CFrameWnd::LoadFrame; CListBox::AddString; CListBox::Create; CListBox::GetCount; CListBox::GetText; CListBox::GetTextLen; CListBox::ResetContent; CListBox::SetCurSel; CMDIChildWnd::Create; CMenu::GetSubMenu; CMenu::LoadMenu; CMenu::TrackPopupMenu; CObject::AssertValid; CObject::Dump; CObject::Serialize; CStatusBar::Create; CStatusBar::SetIndicators; CToolBar::Create; CToolBar::LoadBitmap; CToolBar::SetButtons; CView::OnDraw; CWinApp::AddDocTemplate; CWinApp::InitInstance; CWinApp::LoadStdProfileSettings; CWinApp::OnFileNew; CWinApp::OpenDocumentFile; CWnd::GetClientRect; CWnd::GetCurrentMessage; CWnd::GetFont; CWnd::Invalidate; CWnd::OnCreate; CWnd::OnNcRButtonDown; CWnd::OpenClipboard; CWnd::SetFont; CWnd::ShowWindow; CWnd::UpdateWindow; CloseClipboard; EmptyClipboard; GetModuleFileName; GetSysColor; GlobalAlloc; GlobalLock; LOWORD; RGB; SetClipboardData; lstrlen; wsprintf

Hinweis:

In diesem und einigen anderen Beispielen wurden die Änderungen an den Visual C++-Assistenten, -Bibliotheken und -Compilern noch nicht nachvollzogen. Sie demonstrieren aber dennoch, wie Sie die gewünschte Aufgabe durchführen können.

Siehe auch

Weitere Ressourcen

MFC-Beispiele