上述示例程式的幾個關鍵點：

1. WPF 窗體為主窗體，窗體風格為 AllowsTransparency = true
2. 分別對主窗體內建 WPF 的 Webbrowser 控制元件和 Winform 的 Webbrowser 控制元件進行了演示
3. 完美的窗體縮放、移動、最大化等操作
4. 演示隨意調整窗體背景透明度
5. 示例程式碼簡單易操作，是可以找得到的最完美，而且的確是完美的解決辦法

       山寨關鍵點

       一、關鍵程式碼如下：

WPF

WebBrowserOverlay wbo = new WebBrowserOverlay(_webBrowserPlacementTarget);
System.Windows.Controls.WebBrowser wb = wbo.WebBrowser;
wb.Navigate(new Uri(“

http://blog.csdn.net/hikaliv/”));

Winform

WebBrowserOverlayWF wbo = new WebBrowserOverlayWF(_webBrowserPlacementTarget);
System.Windows.Forms.WebBrowser wb = wbo.WebBrowser;
wb.Navigate(new Uri(“http://blog.csdn.net/hikaliv”));

       這兩段程式碼分別是你在程式裡面安置 WPF 的 Webbrowser 控制元件或 Winform 的 Webbrowser 控制元件的方法——關鍵在你不能放錯地方。注意

       二、別忘了在工程 References 裡面新增 System.Windows.Presentation.dll，若要用到 Winform 的控制元件，還需要新增 System.Windows.Forms.dll 引用。

       三、不得設定 WindowStartupLocation 屬性。

       這不是我的方法和示例程式碼，這是微軟工程師的方法和示例程式碼，詳見我轉載他們的幾篇關鍵文章：

       此示例完整地詮釋了一種最可取的辦法——在主窗體上劃出一塊區域，由一塊 FrameworkELement Object 的可視域（CompositionTarget）

       此法三個關鍵點用紅字標出。這三個關鍵點也道出了此法作為最可取之法——其實也是唯一可取之法的原因。或許還有其它辦法，但效果一定都不理想，靈活性也差。最終的效果是需要“視覺上內嵌”，而事實上並不需要邏輯上內嵌——因為邏輯內嵌的結果是不想要的，否則也不會有這個困難了。這個問題出現的關鍵在於上面第三篇文章介紹的內容，還有一點是 WPF（DirectX）和 Win32（GDI）的渲染順序——其實這些倒並不噁心，真正噁心的地方在於 Webbrowser 這個控制元件……你會發現 template 對它無用，而且用你能找到的最強大的內查工具看它是鉛板一塊，透視不得。WPF 的 Webbrowser 到底是個什麼神祕的東西需要這麼保密？——不僅神祕，而且古老——關鍵是古老，Winform 和 WPF 其實都沒有對它進行重寫以使它至少在 UI 上可以更強大，不，不僅 UI 體驗上沒有加強，而且事實功能上反而一代比一代更加弱小——建議大夥兒徹底放棄 system.windows.controls.webbrowser 好了，當它根本沒存在過，視而不見，只用 system.windows.forms.webbrowser，或者直接用 MFC 的，反正只不過需要加層 WindowsHost 或者 HWNDSOURCE 而已。

       正因為 Webbrowser 的噁心，因此唯一正確的思路則是必須將它和 WPF 主窗體邏輯解體。否則只能取締 WPF 窗體的 AllowsTransparency = true 屬性約束，使 WPF 的 Transparent/Alpha 通道渲染和這個控制元件的底層渲染不衝突。想闖闖沒有 AllowsTransparency = true 屬性約束的 WPF 自制窗體嗎？自己去處理無盡的 WINDOWS MESSAGE 麻煩吧——友情提示一聲—— WPF 渲染和系統（GDI）渲染是兩層，截訊息的辦法是行不通的……如果你還想再架層 DWM 渲染的話……祝你被愉快。

       總之，WPF 自制窗體“內嵌”Webbrowser 控制元件必須的兩點：

1. AllowsTransparency = true。這簡簡單單一句話……其實背後的水很深很深……沒它你試試……
2. 控制元件與主窗體必須邏輯解體。

       問題癥結

       一句話概括就是“窗體的邏輯和渲染衝突”。我不知道非 WIN 系統是否會存在這個問題，然而在 WINDOWS 系統上，這是一個很噁心的問題。而且這也並非是個案，因為說得不好聽點兒，這根本就是版本間不可相容的事兒，是微軟產品的通病。我不瞭解 Apple 的 MAC 系統是如何渲染的，但我體會到了 WPF 渲染的代價——這麼多層、重複渲染、渲染衝突，而且還不如 MAC 的效果好，對硬體寬容，效能高……唉……

       抱怨一下，為何微軟的 WPF 開發團隊這麼“懶”呢？把 system.windows.controls.webbrowser 寫得比 system.windows.forms.webbrowser 要差，殘廢，而且 WPF 下面的 Datagrid 也遠不如 Winform 的 Datagridview。MS 平臺軟體開發的方向，從 MFC 的實打實，經過 Winform 越來越向 WPF 的華而不實的方向走……WPF 確立了一種全新的窗體組織形式，讓 UI 和控制元件開發實現了鬆耦合、自動化，但不能用實用性的缺失為交換。記得 .net framework 剛出來的時候，全新的 C#.net 體驗讓學長傳達給我他在微軟工程院從工程師那裡聽到的一句話——MFC 的末日到了……效率不效率的其實並非重點，重點是新框架下的控制元件比舊框架下的控制元件不實用……那又如何宣判得了舊框架的死刑呢？