MFC Dll/MFC Extension Dll

HaJo.

Hallo!

Zwei Sachen die ich noch nicht ganz verstanden habe. Funtionen, die aus der Dll exportiert werden sollen um sie in der Exe zu nutzen deklariere ich in einer MFC Extension Dll wie folgt:

// Headerdatei.h
extern "C" AFX_EXT_API bool WINAPI Foo();

// Quellcodedatei.cpp
extern "C" bool WINAPI Foo()
{
  // Some Code
}

So, kann ich die Headerdatei für die Exe und Dll nutzen, da AFX_EXT_API sicherstellt, das entweder declspec(export)/declspec(import) genutzt wird.
1.) Gilt das gleiche Deklarationsschema auch für normale MFC Dlls? Eine .def-Datei möchte ich nicht nutzen.

2.) Und nun noch eine Frage zu AFX_MANAGE_STATE. Wenn ich bei einer normalen MFC Dll z.B. einen Dialog über eine exportierte Funktion lade, soll

AFX_MANAGE_STATE(AfxGetStaticModuleState( ));

zu Begin der Funktion aufgerufen werden. Wie verhält es sich bei exportierten Funktionen, die *keinen* Zugriff auf Resourcen - weder Dll noch Exe - benötigen? Muss ich dann auch

AFX_MANAGE_STATE(AfxGetStaticModuleState( ));

zu Beginn aufrufen?

Martin Richter

zu 1. Das hat nichts mit MFC zu tun sondern wie Symbole exportiert werden und deklariert werden.

http://blog.m-ri.de/index.php/2008/02/22/vs-tipps-tricks-benoetigt-man-eigentlich-noch-def-dateien/

zu 2. AFX_MANAGE_STATE solltest Du immer verwenden wenn Du die MFC dynamisch bindest! Es werden nicht nur die Ressourcen Zeiger umgebogen sondern auch das Main Window und die Applikations Zeiger etc.
Sprich was bekommst Du zurück, wenn AfxGetApp() aufgrufen wird... etc.
http://blog.m-ri.de/index.php/2008/02/25/warum-man-manchmal-afx_manage_state-auch-in-seiner-eigenen-exe-aufrufen-muss/

HaJo.

Martin Richter schrieb:

zu 1. Das hat nichts mit MFC zu tun sondern wie Symbole exportiert werden und deklariert werden.

http://blog.m-ri.de/index.php/2008/02/22/vs-tipps-tricks-benoetigt-man-eigentlich-noch-def-dateien/

Vielleicht habe ich mich etwas unklar ausgedrückt. Bei C(++) Dlls verwende ich meistens die __stdcall Aufrufkonvention inkl. einer .def-Datei. In diesem Fall handelt es sich wie gesagt um zwei MFC Dll - normal und Erweiterungs-Dll, die die MFC dynamisch linken - und ich wollte keine .def-Datei nutzen da ich diese hier wegen der declspec(export/import) Aufrufkonvention nicht benötige. Ich wollte mich nur vergewissern, dass die "automatische", korrekte Aufrufkonvention mit AFX_EXT_API auch bei normalen MFC Dlls funktioniert und ich somit die gleiche Headerdatei nutzen kann.

Martin Richter schrieb:

zu 2. AFX_MANAGE_STATE solltest Du immer verwenden wenn Du die MFC dynamisch bindest! Es werden nicht nur die Ressourcen Zeiger umgebogen sondern auch das Main Window und die Applikations Zeiger etc.
Sprich was bekommst Du zurück, wenn AfxGetApp() aufgrufen wird... etc.
http://blog.m-ri.de/index.php/2008/02/25/warum-man-manchmal-afx_manage_state-auch-in-seiner-eigenen-exe-aufrufen-muss/

Hier hätte ich dann noch zwei Fragen. 1.) Wenn ich in einer MFC Dll, mal den Zeiger auf Hauptfenster benötige und diesen nicht als Parameter übergeben kann/will, ist dann folgendes "erlaubt"

extern "C" AFX_EXT_API void WINAPI Foo(LPARAM lParam, WPARAM wParam)
{
  // Kein AFX_MANAGE_STATE aufrufen um das Hauptfenster zu erhalten
  AfxGetMainWnd()->SendMessage(MY_MESSAGE, lParam, wParam);
}

oder ist das "schlechter" Stil?

2.) Ich habe es jetzt so verstanden, dass ich bei MFC Extension Dll AFX_MANAGE_STATE nicht aufrufen muss, da es intern richtig gesetzt wird. Das Laden von Resourcen klappt nämlich auch ohne wie gewünscht.

Martin Richter

Wie Du Deine DLL-Entries bindest, definierst und erreichtst ist Deine Sache. Das ist generell alles erlaubt. Das hat erstmal mit DLL Technik zu tun und mit nichts anderem...

zu 1. Ja das geht. Das ist genau der Sinn, warum es einen Module State gibt.
AfxGetApp liefert das Singleton CWinApp, für Deinen Prozess.
Aber Achtung Das kan bei einer Standard DLL aber auch das interne CWinApp Objekt der DLL sein! Eine Extension DLL hat ja genau kein CWinApp Objekt!

zu 2. AFX_MANAGE_STATE darf Extension DLLs nicht verwendet werden.
IMHO bekommst Du dann Linker Fehler: LNK2005 _DllMain@12 already defined (o.Ä)

Extension DLLs klinken sich in eine interne DLL-Liste ein. In allen Extension DLLs werden Ressourcen gesucht. Aber Achtung!
Wenn Du Ressourcen ID Überscheindungen hast bekommst Du Probleme.

Ich würde den evtl. ein eigenes Makro aber grundsätzlich ertsmal verwenden um eine evtl. Umstellung auf eine Standard DLL vorzusehen. Außer die Nutzung ist sowieso nur als Extension DLL möglich...

Siehe detailierte Infos in TN011+TN033+TN058
http://msdn2.microsoft.com/es-es/library/zfz4xb9a(VS.80).aspx
http://msdn2.microsoft.com/es-es/library/hw85e4bb(VS.80).aspx
http://msdn2.microsoft.com/es-es/library/ft1t4bbc(VS.80).aspx

HaJo.

Recht schönen Dank auch.