關於本地C++,MFC應用程式調用.NET控制項做顯示層的方法

首先聲明我是比較熟悉C++，對C#等.NET環境語言基本不懂。周末花了不少時間，收集很多相關的資料並做了一些嘗試，發現這樣做是可行的，有一定的實用價值。

 

 

問題來源，我發現在C++下做介面真是太痛苦了，往往分析清楚了問題，寫底層的資料結構和邏輯相當順利，但是一涉及介面，進度往往就不能很好的控制。於是覬覦.NET架構做介面的便捷性，很想嘗試在本地的C++程式中通過調用.NET設計的介面部分解決我所面臨的問題。

 

 

解決思路，C++/MFC介面可以做的很薄，很簡單;需要用到美觀介面的時候調用.NET表單或者控制項（包括.NET寫的ActiveX和WPF控制項），在.NET表單或控制項上操作的訊息能夠發回C++，這樣即可形成很好的開發迴路。

 

 

解決途徑，為了確保開發的連貫性，主程式依舊採用非託管的MFC/Win32，因為一旦主程式改用clr編譯，將出現很多無法預料的問題，並且會給項目組的其它同仁帶來很多困惑，畢竟不是每個同志都有精力研究和維護兩套代碼。那麼主程式不變的前提下，是如何相容解決這個問題的呢？我在.NET控制項，.NET表單,WPF控制項，ActiveX控制項之間做了一個中介層，該層採用MFC擴充動態連結程式庫為基礎，匯出函數為能夠與本地MFC程式相容的函數(匯出函數內不帶.NET的變數和函數)，如此一來這個中介層內部是如何完成的，使用者就不需要關心了，只要知道介面函數即可開啟或者內嵌dll中匯出的表單了。

 

 

解決內容：1.NET表單，2.NET控制項，3.WPF控制項，4.ActiveX（這個本身沒問題，這裡特指用.NET架構寫的ActiveX，運行時估計需要.NET Framework）。

 

 

遺留問題，1.由於我對.NET幾乎一竅不通，因此訊息通訊和資料轉換需要在今後的實踐中繼續摸索。這裡我在做訊息的時候發現C#採用的是委託(代理？術語我不太確定)的方式做的，在Managed C++中響應訊息的時候發現/VC/include/msclr檔案夾event.h中的委託宏定義不能解決單(多)參數的問題，這裡的委託預設就是2個參數，由於某些使用者自行製作的控制項委託方法需要用到非2個參數的情況，我建議讀者可以嘗試自行擴充宏定義(擴充event.h中的宏)，千萬別被它束縛（我開始不敢改，想通過其它方法完成，後來繞回來發現，擴充宏是最便捷的，也最能解決問題的）;2.由於我是基於MFC擴充動態連結程式庫做的探索，想在上面加個表單試試看，發現這種模式下不讓我用表單設計器（大概是M$設計上的難題），不過這個被我繞過去了，我做一個純.NET的Managed C++工程，設計完成所需要的WinForm後，將ref myForm類複製到原工程，發現可以使用。

 

 

 

邏輯難題，1.昨晚上我在做完技術研究和編程嘗試之後回過頭來思考，發現這樣做表面上是很方便，介面寫起來很快很美觀，不過重要的是主程式在邏輯上如何做到無縫，也就是說C++程式中的對象傳遞過來的能用性有多少？譬如我在主程式中自己定義了一個類的對象，能將對象傳遞到這種介面下進行調用嗎？似乎是可以的，但我不能確信，畢竟用到了.NET的東西。即對應用情況我還得多總結，什麼情況試用這種開發模式，各個分模組相對獨立情況下應該可行。2.有對.NET非常熟悉的同事告訴我說應該倒過來，以.NET架構為主，C++模組為輔助，可惜我對.NET不熟悉。也許這樣做很醜陋，如果的確是那麼僅供大家參考。

 

 

希望有興趣的朋友回帖，也許有更好的方法解決這些問題。