2010-12-21 4 views
1

Ich entwickle ein WPF Frontend (mit MVVM und Prism) für eine bestehende MFC-Anwendung. Diese Anwendung wird nicht wesentlich geändert, da sie monolithisch ist und keinerlei Dokumentation enthält. Gibt es Technologien, die diese beiden Plattformen entweder in den gleichen Speicherbereich bringen (beste Option) oder ihnen erlauben, synchron zu kommunizieren (da die MFC-Anwendung keinesfalls threadsicher ist)? Um die Stabilität zu erhalten, muss WPF eine ausführbare Datei sein. Ich habe versucht, es als eine DLL an die MFC-Anwendung anzuhängen, aber dies führt zu extremer Instabilität.Wie kann meine WPF-Anwendung (w/MVVM, Prism) mit einer monolithischen MFC-Anwendung interagieren?

+1

Beware von AirSpace-Problemen. Wenn Sie WPF- und MFC-Ansichten mischen möchten, lesen Sie die Informationen unter http://msdn.microsoft.com/en-us/library/aa970688.aspx. Wir hatten Probleme mit WPF und Winforms, daher könnte es für MFC besonders schwierig sein. Alles Gute, um es zum Laufen zu bekommen – aqwert

Antwort

1

Eine Option, die Sie haben, besteht darin, Ihr MFC direkt in WPF zu hosten oder das WPF in Ihre MFC-App einzubetten, wie im MSDN-Artikel WPF and Win32 Interoperation beschrieben. Überprüfen Sie speziell die zwei Schritte, die oben in diesem Artikel erwähnt werden.

Ich fand WPF in Ihrem MFC-Code viel einfacher einbetten als Rehosting Ihre MFC-Anwendung in WPF.

WPF in MFC-Hosting ist einfach eine Frage der richtig die HwndSource-Klasse (wenn Sie der Verwendung von Managed C furchtlos sind ++ Sie eine schöne Interop-Schicht erstellen und die/clr Flagge in Ihrem MFC-Projekt ganz vermeiden.)

Das Hosten Ihrer MFC-Anwendung in einer WPF-Anwendung ist komplizierter, wenn Sie versuchen, eine MDI-Anwendung neu zu hosten, aber Sie können die einzelnen Rahmen in Ihrem WPF-Code an beliebiger Stelle hosten (z. B. in Prism-Regionen) Am Ende habe ich alle MDI-Frame-Management-Codes manuell entfernt.

Um dies zu tun, habe ich meine eigene CMultiDocTemplate-abgeleitete Klasse erstellt und überschreiben die OpenDocumentFile() virtuelle Methode, um meine eigenen Frame-Öffnungsverhalten. Diese Methode erstellte manuell einen speziellen CMDIChildWnd-abgeleiteten Rahmen, den ich erstellt hatte, der jede Methode überschrieb, die mit dem übergeordneten MDI-Rahmenfenster interagiert und sie an den zugrunde liegenden CFrameWnd (unter Umgehung der CMDIChildWnd) übergeben.

Zuerst wird eine Hilfsfunktion Objekt, das den Rahmen erzeugt (m_pFrameClass ist Ihre speziellen CMDIChildWnd abgeleitete Klasse oben beschrieben)

HWND CreateHostedFrame (HWND Mutter)

CFrameWnd* pFrame = (CFrameWnd*)m_pFrameClass->CreateObject(); 

CWnd parentWnd; 
parentWnd.Attach(parent); 
pFrame->LoadFrame(resourceID, WS_CHILD, &parentWnd, pContext); 
parentWnd.Detach(); 

return pFrame->m_hWnd; 

Dann Verfahren Ihre überschriebene DocTemplate (oder wo immer Sie Ihre Bilder erstellen)

CHostedMultiDocTemplate :: OpenDocumentFile:

CDocument* pDocument = CreateNewDocument(); 

// the following is just for demo purposes. Use your own mechanism 
m_MyWpfShellOrSomething->PleaseCreateAHostedWindowUsing(&CreateHostedFrame); 

InitialUpdateFrame(pFrame, pDocument, bMakeVisible); 

return pDocument; 

Ihre CMDIChildWnd abgeleitete Klasse wollen wahrscheinlich etwas außer Kraft zu setzen, die dem übergeordneten MDI-Rahmen bezieht (die MFC CMDIChildWnd Quelle für MDIParent() oder etwas suchen.)

Natürlich ist der letzte Schritt ist die Aktualisierung Ihrer CMyApp :: OnInitInstance() -Methode, um Ihre spezialisierte MultiDoc-Vorlage und den untergeordneten Rahmen anstelle der anderen zu verwenden.

+0

Ich bin von diesem Problem weggezogen, indem ich einen IPC-Kanal benutzt habe und die MFC-Anwendung in meinem WPF als externen Prozess gehostet habe. Ich verwende die Kopierdatenmethode. (ähnlich dem: http://www.codeproject.com/KB/threads/InterprocessCommunicator.aspx), aber danke. – Jordan