generelle Frage: WinAPI und MFC mischen?

Hallo,
ich kenne mich in der GUI-Programmierung mit MFC nun jetzt nicht sooo gut aus, was sich aber verbessern soll.

Ich habe ein MFC-Programm als Basis (SDI oder MDI) und möchte 'alten' WinApi-Code benutzen (der registriert seine Fensterklasse, erzeugt per CreateWindow(...) ein Fenster, das einen Fensterhandler also einen LRESULT CALLBACK MainWndProc(..) hat).

Frage 1: das per CreateWindow() erzeugte Fenster hat doch eine eigene, vom MFC-Framework unabhängige Msg-Pump?

Frage 2: muss ich mit irgendwelchen Problemen bzgl. Msg-Verarbeitung rechnen?

Frage 3: kann ich innerhalb des MainWndProc MFC-Dialoge instanziieren, also modale oder nichtmodale? Oder kann es da zu "Verklemmungen" kommen?

Ich hoffe, meine Fragen sind halbwegs verständlich formuliert....

Martin Richter

zu 1. Nein. Die Messageloop liegt immer in der MFC. Würde auch sonst nicht gehen, außer Dein Fenster ist modal.
zu 2. Nein. Nur umgekehrt kann es Probleme geben. Win32 Programm mit MFC Klassen.
zu 3. Ja. Solange die Messageloop durch dir MFC kontrolliert wird.

Nur mal als Denkhinweis:
Jedes stink normale Dialog Control ist solch ein Fenster, dass mit der MFC nichts zu tun hat, wenn kein Subclass erfolgt.

Hallo Martin, Danke für die Antwort.

Ich hab mittlerweile etwas im MSDN geschmökert. Eine Frage bzgl. MsgPumps hätte ich noch (im Zusammenhang mit CWinThreads).

Es gibt ja Worker-Threads und GUI-Threads. Worker sind mir soweit geläufig. Wenn ich es richtig gelesen und interpretiert habe, haben GUI-Threads eine *eigene* MsgPump, oder?

Ich habe bisher eigentlich nur Worker benutzt. Wenn die GUI Threads eine eigene MsgPump haben, worin besteht dann eigentlich der Vorteil eines Workers? Ich meine, einer GUI-Thread kann man einfech per PostMessage() Nachrichten senden, bei den Workern benutzt man i.d.R. andere (ggfs. umständlichere) Kommunikationsmechanismen.