Share via

簡介Windows Presentation Foundation

  • 發行項

 

David Chappell
Chappell & Associates

2006 年 9 月

適用於：
   Windows Vista
   Windows Presentation Foundation
   Microsoft .NET Framework 3.0

總結：Windows Presentation Foundation (WPF) 的主要目標是協助開發人員建立具吸引力且有效的使用者介面。 瞭解 WPF 整合平臺如何協助設計工具在建立使用者介面時主動參與，並為獨立和瀏覽器應用程式提供常見的程式設計模型。 (34 個列印頁面)

目錄

描述Windows Presentation Foundation
   說明問題
   解決問題：Windows Presentation Foundation提供的內容
使用Windows Presentation Foundation
   Windows Presentation Foundation的技術
   套用Windows Presentation Foundation
適用于Windows Presentation Foundation的工具
   適用于開發人員：Visual Studio
   針對設計工具：運算式互動式Designer
Windows Presentation Foundation和其他 Microsoft 技術
   Windows Presentation Foundation和Windows Forms
   Windows Presentation Foundation 和 Win32/MFC
   Windows Presentation Foundation 和 Direct3D
   Windows Presentation Foundation和 AJAX/「Atlas」
   Windows Presentation Foundation和 「WPF/E」
結論
關於作者

描述Windows Presentation Foundation

根據定義，技術人員最關心技術。 許多軟體專業人員對於應用程式的運作方式，比起應用程式與其使用者互動的方式，更有興趣。 不過，這些使用者，在一切之後，支付所有費用的使用者，在意使用者介面。 應用程式的介面是使用該軟體的完整使用者體驗的主要部分，而且對於其使用者，體驗 是 應用程式。 透過更好的介面提供更佳的使用者體驗，可以改善生產力、協助建立新客戶、增加網站上的銷售量等等。

一旦滿意純字元型介面，使用者現在已習慣使用圖形化介面。 但使用者介面的需求仍會繼續前進。 圖形和媒體已廣泛使用，且 Web 已設定一代人員預期與軟體的輕鬆互動。 人們花在與應用程式互動的時間越多，這些應用程式的介面就越重要。 為了跟上增加的期望，用來建立使用者介面的技術也必須前進。

Windows Presentation Foundation (WPF) 的目標是為 Windows 提供這些進階。 包含在 Microsoft .NET Framework 3.0 版中，WPF 允許建置包含檔、媒體、二維和三維圖形、動畫、類似 Web 的特性等的介面。 就像.NET Framework 3.0 中的其他專案一樣，WPF 適用于 Windows Vista、Windows XP 和 Windows Server 2003，並排定在 Windows Vista 隨附時發行。 本檔介紹 WPF，描述其各種部分。 目標是厘清這項技術所解決的問題，然後調查 WPF 所提供的解決方案。

說明問題

假設醫院想要建立新的應用程式來檢查和監視病患。 這個新應用程式使用者介面的需求可能包括下列各項：

  • 顯示病患的相關影像和文字。
  • 顯示和更新二維圖形，其中顯示病患的生命徵兆，例如心力和壓力。
  • 提供病患資訊的三維檢視和重迭。
  • 展示醫生和其他診斷的影片，或許允許醫生和醫生新增批註。
  • 允許醫院員工讀取和標記法，以描述病患和她的狀況的檔。
  • 以 Windows 應用程式的形式執行，允許醫院員工的完整功能，以及在受安全性限制的網頁瀏覽器應用程式中執行，允許遠端醫生透過網際網路進行更有限的存取。

這些需求並不合理，但並不合理。 在正確時間以正確方式呈現正確資訊的使用者介面可能會有顯著的商業價值。 在此所述的醫療保健範例這類情況下，他們實際上可以節省生活。 在較不重要的案例中，例如線上商家或其他消費者導向的應用程式，提供強大的使用者體驗，可協助區分公司的供應專案與其競爭對手，增加公司的品牌銷售額和價值。 其中一點在於，許多現代化應用程式都可以受益于提供整合圖形、媒體、檔，以及新式使用者體驗之其他元素的介面。

使用 2006 的技術，在 Windows 上建置這種介面是可行的，但相當具挑戰性。 其中一些主要障礙如下：

  • 現今會使用許多不同的技術來處理圖形、影像和視訊。 尋找想要使用這些各種技術的開發人員可能很困難且昂貴，因為維護他們建立的應用程式。
  • 設計可有效地向使用者呈現所有此功能的介面是一項挑戰。 需要專業設計人員—軟體發展人員沒有正確的技能，但設計人員和開發人員在共同作業時面臨重大挑戰，特別是這裡所述的完整功能介面。
  • 提供功能完整的介面作為獨立 Windows 傳統型應用程式和瀏覽器裝載的版本，需要使用兩組不同的技術來建置兩個不同的實作。 Windows 傳統型應用程式可能會使用Windows Forms和其他原生 Windows 技術，而瀏覽器裝載的應用程式則會使用 HTML 和 JavaScript。 需要兩個不同的開發人員群組，其中包含兩個完全不同的技能集。

建立強大、現代化使用者介面應該相當複雜，因此沒有固有原因。 常見的基礎可以解決所有這些挑戰，為開發人員提供統一的方法，同時讓設計工具扮演重要的角色。 如下所述，這是 WPF 的意圖。

解決問題：Windows Presentation Foundation提供的內容

WPF 所提供的三個層面都十分重要。 它們是：適用于新式使用者介面的統一平臺、開發人員和設計人員共同作業的能力，以及 Windows 和網頁瀏覽器使用者介面的通用技術。 本節說明這三個。

新式使用者介面的整合平臺

在 WPF 前世界中，建立 Windows 使用者介面，就像先前所述的介面一樣，需要使用數種不同的技術。 下表摘要說明情況。

  Windows Forms PDF Windows Forms/
GDI+		 Windows Media Player Direct3D WPF
圖形化介面，例如表單和控制項 X         X
螢幕上的檔 X         X
固定格式的檔   X       X
影像     X     X
視訊和音訊       X   X
二維圖形ics     X     X
三維圖形         X X

若要建立 Windows 圖形化使用者介面的表單、控制項和其他一般層面，開發人員最有可能選擇Windows Forms，這是.NET Framework的一部分。 如果介面需要顯示檔，Windows Forms對螢幕檔有一些支援，而固定格式的檔可能會使用 Adobe 的 PDF。 對於影像和二維圖形，該開發人員將使用 GDI+，這是一種也可以透過 Windows Forms 存取的不同程式設計模型。 若要顯示視訊和音訊，他可能依賴Windows 媒體播放機，而對於三維圖形，他將會使用 Direct3D，這是 Windows 的標準部分。

這種複雜的情況只基於歷史原因而存在。 沒有人會認為這很合理。 合理的做法是提供單一統一的解決方案：WPF。 為已安裝 WPF 的電腦建立應用程式的開發人員可能會使用它來解決上面所列的所有區域。 當然，為何不要使用一個一致的基礎來建立使用者介面，而不是各種獨立技術集合？

當然，WPF 不會取代此清單上的所有內容。 Windows Forms應用程式會繼續具有價值，即使在 WPF 世界中，某些新的應用程式仍會繼續使用Windows Forms。 (值得注意的是 WPF 可以與Windows Forms交互操作，本檔稍後會更詳細地說明。) Windows 媒體播放機會繼續扮演獨立的角色，而且會繼續使用 PDF 檔。 Direct3D 也是遊戲和其他一些應用程式的重要技術。 (事實上，WPF 本身依賴 Direct3D 來進行所有轉譯。)

不過，透過在單一技術中提供廣泛的功能，WPF 可以大幅簡化新式使用者介面的建立。 若要瞭解這種統一方法所允許的內容，以下是上述以 WPF 為基礎的健康照護應用程式版本可能會向使用者呈現的一般畫面：

Aa663364.introducingwpf1 (en-us，MSDN.10) .gif

圖 1. WPF 介面可以結合影像、文字、2D 和 3D 圖形等等。

此畫面包含文字和影像，以及二維和三維圖形。 這全部都是使用 WPF 產生，開發人員不需要撰寫使用 GDI+ 或 Direct3D 等特製化圖形技術的程式碼。 同樣地，WPF 也允許顯示和批註視訊，例如如下所示的摘要。

Aa663364.introducingwpf2 (en-us，MSDN.10) .gif

圖 2. WPF 介面可以包含影片，讓使用者能夠製作文字批註。

WPF 也允許以可讀取的方式顯示檔。 例如，在醫院應用程式中，醫生可能能夠查閱病患治療的相關注意事項，或存取相關主題的目前醫療研究。 同樣地，醫生可能會新增批註，如下列畫面所示。

Aa663364.introducingwpf3 (en-us，MSDN.10) .gif

圖 3. WPF 介面可以顯示多欄檔，包括批註。

請注意，檔會顯示在可讀取的資料行中，而且使用者可以一次移動頁面，而不是捲動。 改善螢幕上的可讀性是值得的目標，而且是 WPF 的重要目標。 不過，在螢幕檔上很有用，但固定格式的檔有時可能是正確的選擇。 因為它們在畫面和印表機上看起來相同，所以固定格式的檔會在任何情況下提供標準外觀。 為了定義這種類型的檔，Microsoft 已建立 XML 檔規格 (XPS) 。 WPF 也提供一組應用程式開發介面， (API) 開發人員可用來建立和使用 XPS 檔。

但建立新式使用者介面，表示不只是統一各種技術一次。 這也表示利用新式圖形卡，因此 WPF 會利用任何圖形處理單位 (GPU) ，盡可能卸載系統上的工作。 新式介面也應該不受位對應圖形的限制所限制。 因此，WPF 完全依賴向量圖形，讓影像自動調整大小以符合顯示畫面的大小和解析度。 開發人員可以讓 WPF 本身處理此問題，而不是在小型監視器和大螢幕電視上建立不同的圖形來顯示。

藉由將建立使用者介面所需的所有技術整合成單一基礎，WPF 可以讓建立這些介面的人員更容易生活。 藉由要求這些人員只學習單一環境，WPF 可以讓建立和維護應用程式的成本較低。 而且，藉由直接建置包含圖形、視訊等的介面，WPF 可以改善使用者與 Windows 應用程式互動的品質和商業價值。

開發人員和設計工具共同作業的能力

提供統一的技術基礎來建立功能完整的使用者介面是一件好事。 但預期開發人員會明智地使用此能力，建立容易理解且容易使用的介面，可能要求太多。 建立良好的使用者介面，特別是當它們與剛才描述的醫院範例一樣全面時，通常需要大部分軟體專業人員都不需要的技能。 雖然許多應用程式都是在沒有應用程式的情況下建置的，但事實上，建置絕佳的使用者介面需要使用專業介面設計工具。

但設計人員和開發人員如何共同運作？ 現今兩個專業領域互動的方式有問題。 通常，設計工具會使用圖形化工具來建立應用程式應該顯示的螢幕配置靜態影像。 然後，他會將這些影像提供給開發人員，其工作是建立讓這些映射成為真正的程式碼。 不過，設計工具很容易繪製的內容，可能很難或不可能讓開發人員實作。 技術限制、排程壓力、缺乏技能、誤解或簡單爭議，可能會導致開發人員無法完全實現設計工具的願景。 需要的是讓這兩個相互依存專業領域的成員能夠共同合作，而不需要危害介面品質的更好方式。

為了允許此情況，WPF 引進了 eXtensible Application Markup Language (XAML) 。 XAML 會定義一組 XML 元素，例如 Button、 TextBox、 Label等等，以確切定義使用者介面的外觀。 XAML 元素通常也有屬性，允許設定各種選項。 例如，這個簡單的 XAML 程式碼片段會建立紅色按鈕，其中包含 「No」 這個字：

<Button Background="Red">
 No
</Button>

每個 XAML 元素都會對應至 WPF 類別，而且每個元素的屬性在 類別中都有對應的屬性或事件。 例如，此 C# 程式碼可能會產生相同的紅色按鈕：

Button btn = new Button();
btn.Background = Brushes.Red;
btn.Content = "No";

如果 XAML 中可表達的所有專案在程式碼中也是可表達的，也就是 XAML 的價值為何？ 答案是，建置可產生及取用 XML 型描述的工具，比使用程式碼執行相同動作更容易。 因為 XAML 提供方便使用的工具來描述使用者介面，所以提供較好的方式讓開發人員和設計工具共同運作。 下圖說明此程式。

Aa663364.introducingwpf4 (en-us，MSDN.10) .png

圖 4. XAML 可協助設計人員和開發人員共同作業

設計工具可以使用 Microsoft Expression Interactive Designer之類的工具來指定使用者介面的外觀和互動方式。 針對定義 WPF 介面的外觀和風格，此工具會產生以 XAML 表示之介面的描述。 (雖然它可能包含類似此處所示的簡單按鈕，但此描述實際上比上述程式碼片段更複雜。) 開發人員接著將該 XAML 描述匯入 Microsoft Visual Studio 之類的工具。 介面定義本身不是根據設計工具所產生的靜態影像從頭重新建立介面，而是採用介面定義本身。 開發人員接著會撰寫介面的程式碼，例如事件處理常式，以及應用程式所需的任何其他功能。 您也可以建立可全域套用至應用程式介面的樣式，以便視需要針對不同情況加以自訂。

讓設計人員和開發人員像這樣一起運作，可減少開發人員從設計工具建立的映射實作介面時所發生的翻譯錯誤。 它也可以讓這兩個角色中的人員平行運作，並提供更快速的反復專案和更好的意見反應。 由於這兩個環境都使用相同的建置系統，因此可以在兩個開發環境之間來回傳遞 WPF 應用程式。 也提供設計 XAML 定義介面的更特製化工具，例如電力雨的 ZAM 3D 來建立三維介面元素。

更好的使用者介面可以提高生產力—他們具有可測量的商業價值。 但若要建立真正有效的介面，特別是在 WPF 提供的多面向世界中，設計工具必須成為程式中的第一級公民。 XAML 的主要目標，以及支援它的工具，就是讓這能夠達成此目的。

Windows 和網頁瀏覽器使用者介面的通用技術

為 Windows 應用程式建立有效的使用者介面很重要。 但為 Web 型應用程式建立有效的介面至少很重要。 根據定義，這些介面是由網頁瀏覽器提供，而最簡單的方法是讓瀏覽器被動顯示它所接收的任何 HTML。 更回應的瀏覽器介面提供在 JavaScript 中執行的邏輯，或許是使用非同步 JavaScript 和 XML (AJAX) 。 介面甚至可以使用 Adobe 的 Flash Player 或其他技術來支援動畫、視訊等等。 有時稱為 豐富的網際網路應用程式，提供這種完整功能介面的 Web 軟體可以大幅改善使用者體驗。 它也可以藉由讓 Web 應用程式對使用者更具吸引力，來增加大量的商業價值。

建置這種介面傳統上需要使用與原生 Windows 介面所使用的技術完全不同的技術集。 因此，開發人員通常會專注于下列其中一種方法：您是 Windows 介面開發人員，或您是 Web 介面開發人員。 但對於將從 Windows 存取的豐富網際網路應用程式，為什麼應該有這種區分？ 原生 Windows 介面和網頁瀏覽器介面無法使用相同技術的固有原因。

WPF 允許此專案。 開發人員可以使用在 Internet Explorer 中執行的 WPF，建立 XAML 瀏覽器應用程式 (XBAP) 。 事實上，相同的程式碼可用來建立獨立 WPF 應用程式和 XBAP。 例如，下列畫面會顯示以獨立 Windows 應用程式身分執行的金融服務應用程式。 就像稍早顯示的醫院應用程式一樣，這一個應用程式會混合文字、影像和各種圖形類型。 (此畫面也會說明 Windows Vista 桌面，包括時鐘和美化主題等小工具，提供應用程式視窗周圍的半透明框線。)

Aa663364.introducingwpf5 (en-us，MSDN.10) .png

圖 5. 金融服務應用程式可以當作獨立 WPF 應用程式執行。

以下是此介面在 Internet Explorer 內以 XBAP 的形式執行的方式：

Aa663364.introducingwpf6 (en-us，MSDN.10) .png

圖 6. 相同的應用程式可能會以 XBAP 的形式執行。

介面現在是由瀏覽器所框架，而不是在自己的視窗中執行，但其功能仍維持不變。 相同的程式碼也可用於這兩種情況，這可減少處理這兩種介面所需的工作量。 使用相同的程式碼也表示使用相同的開發人員技能。 WPF 不強制開發人員進入 Windows 介面開發人員或 Web 介面開發人員的不相鄰方塊，WPF 可以細分這些部門，允許在這兩種情況下使用相同的知識。

針對 Windows 和 Web 介面使用相同的技術的另一個優點是，應用程式的建立者不一定要事先決定應用程式應該擁有的介面類別型。 只要目標用戶端符合執行 XBAP 的需求，應用程式就可以提供 (或兩者) Windows 和 Web 介面，且使用大致相同的程式碼。

由於 XBAP 會視需要從網頁伺服器下載，因此會面臨比獨立 Windows 應用程式更嚴格的安全性需求。 因此，XBAP 會在.NET Framework代碼啟用安全性所提供的安全性沙箱中執行。 XBAP 也只會在已安裝 WPF 的 Windows 系統上執行，而且只執行 Internet Explorer 6 和 7 版。 不過，對於符合這些需求的應用程式，豐富的網際網路應用程式現在可以使用與獨立 Windows 應用程式相同的基礎。

使用Windows Presentation Foundation

瞭解 WPF 所解決的問題很有用，但對解決這些問題的方式有一些瞭解也很有用。 本節會調查 WPF 技術本身，然後查看它在 Windows 傳統型應用程式、XBAP 和 XPS 檔中套用的不同方式。

Windows Presentation Foundation的技術

即使 WPF 提供建立使用者介面的統一基礎，其所包含的技術仍可在離散且可理解的元件中檢查。 這些元件包括檔、影像、圖形、動畫等等。 不過，它們全都取決於 WPF 的基本應用程式模型，接下來會加以說明。

應用程式模型

如同.NET Framework的其他部分，WPF 會將其功能組織成一組命名空間，全部包含在System.Windows命名空間中。 無論此功能使用哪個部分，每個 WPF 應用程式的基本結構都大致相同。 無論是獨立 Windows 應用程式還是 XBAP，應用程式通常都包含一組與這些頁面相關聯的 XAML 頁面和程式碼。

在其根目錄中，每個應用程式都會繼承自 WPF 的標準 Application 類別。 這個類別提供一般服務，對每個應用程式都很有用。 這些包括必須可供整個應用程式使用的狀態，並提供標準方法，例如 Run、啟動應用程式，以及 終止應用程式的 Shutdown。

您可以使用XAML、透過 Application 元素或使用Application類別的程式碼來建立Application物件。 (這幾乎適用于 WPF 中的所有內容，但為了簡單起見，本檔一律使用 XAML 選項。) 以下是簡單的 XAML 圖例：

<Application xmlns=   
    "https://schemas.microsoft.com/winfx/2006/xaml/presentation"
              xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
     StartupUri="Page1.xaml"
     x:Class="Example.SimpleApp">
. . . 
</Application>

此定義會先指定 WPF 的命名空間做為此元素的預設值，然後定義 XAML 命名空間的前置詞。 (XAML 用於多個 WPF，因此這兩個命名空間不同義。) 接著會使用 StartupUri 屬性來指出應用程式啟動時應該載入和顯示的 XAML 頁面名稱。 最後一個屬性 Class是用來識別類別，其中包含與此應用程式相關聯的程式碼。 如先前所述，WPF 應用程式通常同時包含以 C# 或 Visual Basic 撰寫的 XAML 和程式碼，因此會使用程式 代碼後 置檔案來包含此類別的程式碼。 在此開啟的 Application 標籤之後，會顯示用來定義此應用程式的其餘 XAML，此處省略所有標記，後面接著 Application 元素的結束記號。

即使所有 WPF 應用程式都衍生自相同的根類別，開發人員仍需要進行許多選擇。 一個大型應用程式決定應用程式是否應該提供傳統的對話驅動介面或導覽介面。 對話方塊驅動介面會提供每個 Windows 使用者熟悉的按鈕和其他元素。 相反地，流覽介面的作用就像瀏覽器一樣。 例如，它通常會載入新的頁面，而不是開啟對話方塊的新視窗。 這類介面會實作為頁面群組，每個介面都包含 XAML 中定義的使用者介面，以及以程式設計語言表示的邏輯。 如同 HTML 定義的瀏覽器頁面，XAML 會提供 Hyperlink 元素，可用來將頁面連結在一起。 使用者會流覽這些頁面，就像她透過 Web 應用程式的頁面一樣，依賴 [歷程記錄] 清單來來回移動。 不過，請勿混淆，但這仍是 Windows 應用程式。 雖然 XBAP 通常會使用這種介面，但獨立 Windows 應用程式也可以透過導覽介面與使用者互動。 選擇是由建立應用程式的人員所組成。

應用程式使用的任何介面樣式，通常都會顯示一或多個視窗。 WPF 提供一些執行這項操作的選項。 簡單的 Window 類別提供基本的視窗化函式，例如顯示、隱藏和關閉視窗，而且通常由不使用導覽介面的 WPF 應用程式使用。 NavigationWindow，由具有導覽介面的應用程式使用，可擴充基本的 Window 類別，並支援流覽。 此支援包括 Navigate 方法，可讓應用程式移至新頁面、追蹤使用者流覽歷程記錄的日誌，以及各種導覽相關事件。

版面配置和控制項

為了組織介面的各個部分，WPF 應用程式會使用 面板 進行配置。 每個面板都可以包含子系，包括按鈕和文字方塊和其他面板等 控制項 。 不同類型的面板提供不同的版面配置選項。 例如 ，DockPanel可讓其子項目沿著面板的邊緣放置， 而 Grid 允許將其子系精確地放置在格線上，就像其名稱一樣。 開發人員定義方格中的資料列和資料行數目，然後指定應該放置任何子系的位置。 Canvas可讓開發人員自由地將其子系放在面板界限內的任何位置。

如同任何使用者介面技術，WPF 也提供一組大量的控制項，而開發人員也可以自由建立自訂控制項。 標準集合包括Button、Label、TextBox、ListBox、Menu、Slider和其他使用者介面設計的傳統 Atom。 也會提供更複雜的控制項，例如 SpellCheck、 PasswordBox、使用筆跡 (的控制項，如同平板電腦) 等等。

如同在圖形化介面中，使用者所產生的事件，例如滑鼠移動和按下按鍵，可由 WPF 應用程式中的控制項攔截和處理。 雖然可以使用 XAML 完整指定控制項和其他使用者介面元素，但必須在程式碼中處理事件。 例如，以下是Canvas上簡單按鈕的 XAML 定義：

<Canvas xmlns=
   "https://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
    x:Class="Example.CodeForCanvas">
  <Button Click="Button_Click">
   Click Here
  </Button>
</Canvas>

開頭 的 Canvas 標籤是從定義一般 WPF 和 XAML 命名空間開始。 然後，它會指定與這個 XAML 相關聯的程式碼可以在名為CodeForCanvas的類別中找到，該類別包含在.NET Framework命名空間Example中。 接下來會提供 Button 本身的定義，並指定 「Click Here」 作為其螢幕上的文字。 開啟的 Button標籤上的Click屬性工作表示此按鈕依賴稱為Button_Click的方法來處理 Click 事件。 該方法的程式碼可能如下所示：

namespace Example {
  public partial class CodeForCanvas : Canvas  {
    void Button_Click(object sender, RoutedEventArgs e)    {
      Button btn = e.Source as Button;
      btn.Background = Brushes.Purple; 
    }
  }
}

剛顯示的 Canvas 標籤中指定的命名空間和類別名稱相符。 CodeForCanvas類別繼承自 WPF 所提供的基底Canvas類別，並將其定義為部分類別。 部分類別是 .NET Framework 2.0 版的新增專案，而且允許將個別定義的程式碼合併成單一類別。 在此情況下，XAML 定義的 Canvas 會產生一個部分類別，該部分類別會與此處所示的部分類別結合。 結果是一個完整的類別，能夠同時顯示具有按鈕的畫布，並處理其事件。

在CodeForCanvas類別內會提供處理該事件的Button_Click方法。 它會遵循事件的一般.NET Framework慣例，不過事件的引數是使用 WPF 定義的RoutedEventArgs類別來傳達。 這個類別的 Source 屬性包含 產生事件的 Button 參考，此方法會使用這個方法將按鈕的色彩變更為紫色。

如這個簡單的範例所建議，WPF 使用者介面中的元素會組織成視覺化樹狀結構。 在這裡，樹狀結構只包含具有單一子按鈕的Canvas，但在實際的 WPF 應用程式中，此樹狀結構通常更為複雜。 若要實際建立螢幕上的介面，必須轉譯此視覺化樹狀結構。 可能的話，WPF 會依賴硬體轉譯，讓安裝在應用程式機器上的圖形卡處理工作。 不過，如果電腦的圖形硬體不是由作業決定，WPF 會使用自己的軟體來轉譯介面。 WPF 會在執行時間做出決策，開發人員不需要執行任何特殊動作。

無論轉譯是在硬體或軟體中完成，WPF 一律依賴稱為 保留模式 圖形的方法。 應用程式的建立者會定義視覺化樹狀結構的外觀，通常是使用 XAML 和程式碼的組合。 WPF 本身接著會保留此樹狀結構中的資訊。 例如，WPF 會自行處理它，而不是要求應用程式重新繪製視窗的所有或部分。 組成樹狀結構的元素會儲存為物件，而不是螢幕上的圖元，因此 WPF 有足夠的資訊可以處理這種轉譯。 即使視窗及其所包含的控制項調整大小，WPF 也可以自行重新呈現所有專案。 因為它瞭解圖形的形式—線條、橢圓形等等，而且它依賴向量圖形，而不是圖元的對應，因此 WPF 有足夠的資訊可在新的大小重新建立介面。

樣式和範本

通常很適合用來定義一次使用者介面元素的外觀，然後套用該外觀。 例如，級聯樣式表單 (CSS) 允許在 HTML 頁面中執行此動作。 WPF 提供類似 樣式的內容。 定義樣式的能力相當實用，因為 CSS 樣式表單的受歡迎程度建議。 例如，他們可以在設計工具與開發人員之間提供更好的區隔，讓設計工具建立介面的統一外觀，同時讓開發人員忽略這些詳細資料。

使用 XAML 的 Style 元素，WPF 應用程式的建立者可以定義一或多個外觀層面，然後將該樣式套用至上方。 例如，名為 ButtonStyle 的樣式可能會像這樣定義：

<Style x:Key="ButtonStyle">
  <Setter Property="Control.Background" Value="Red"/>
  <Setter Property="Control.FontSize" Value="16"/>
</Style>

使用此樣式定義的任何按鈕都會獲得紅色背景，並使用 16 的字型大小。 例如：

  <Button Style="{StaticResource ButtonStyle}">
   Click Here
  </Button>

由於此範例中 「StaticResource」 的外觀建議，WPF 樣式通常會定義為資源，這只是與應用程式程式碼分開定義的資料。

樣式允許比此處所示的簡單範例還多。 樣式可以衍生自另一種樣式，例如繼承並覆寫其設定。 樣式也可以定義 觸發程式 ，以指定互動式行為的常見層面。 例如，樣式可能會指定將滑鼠停留在 Button 上方，應該會導致按鈕的背景變成黃色。

WPF 也支援使用 範本。 範本類似于樣式，而且有兩種不同的類型可供使用：

  • 資料範本：允許使用 XAML 的 DataTemplate 元素來指定應該如何顯示資料的一組特性。 色彩、對齊方式等可以在資料範本中定義一次，然後在應用程式的使用者介面中其他地方使用。
  • 控制項範本：允許使用 XAML 的 ControlTemplate 元素來定義控制項的外觀。

為應用程式的建立者提供簡單的方式，以定義其介面的外觀相當合理。 在 WPF 中，樣式和範本是執行此動作的主要機制。

Text

大部分的使用者介面至少會顯示一些文字，有些則顯示其他部分。 不過，對於大部分的人而言，螢幕上的文字無法與閱讀列印的頁面進行比較。 我們習慣使用字母的高品質描述，以及它們之間的關聯性，通常是在書籍和雜誌中找到。 當我們閱讀螢幕上的文字時，只是不一樣，文字一樣不會像可讀一樣。

WPF 的目標是要關閉此間距，讓螢幕文字成為可讀的列印頁面。 在此結尾，WPF 支援業界標準的 OpenType 字型，允許使用現有的字型庫。 它也支援最近定義的 ClearType 技術。 透過子圖元定位，可個別光源化子項目的技術，可在新式顯示畫面上組成每個圖元，ClearType 可讓文字看起來更順暢。 WPF 也提供透過 字元 類別轉譯文字的低階支援。 如稍後所述，XPS 檔會使用此類別來表示字元。

為了進一步改善可讀性，WPF 也允許額外的專案，例如連字，其中一組字元會由單一連接的影像取代。 例如，群組 「ffi」 通常會以包含這三個字元的單一連線 Ligature 取代在列印頁面中。 將此新增至螢幕上的文字可讓讀者感覺更在家，即使她沒有察覺到建立該感覺的詳細資料也一樣。

文件

讓文字更容易閱讀是一件好事，因為文字會出現在按鈕和清單中，以及使用者介面中的許多其他位置。 但是，當我們讀取較長的文字區塊時，我們最關心文字，例如檔中的。 因此，改善螢幕上的可讀性也需要改善檔的顯示方式。 在此結尾，WPF 支援兩種檔： 固定 檔和 流程 檔。

已修正檔在畫面或印表機上呈現的方式完全相同。 瞭解檔一律對某些表單、法律檔和其他種類的發行集而言很重要，因此固定格式的檔在一些區域中很重要。 WPF 支援的固定格式檔是由 XPS 所定義，本文稍後會加以說明。 您可以使用 XAML 的 FixedDocument 元素來指定固定檔的內容。 這個簡單元素只包含 PageContent 元素的清單，每個元素都包含固定檔中的頁面名稱。 若要顯示固定的檔，WPF 會提供 DocumentViewer 控制項。 此控制項提供 XPS 檔的唯讀顯示，讓讀者在檔中往後移動和向前移動、搜尋特定文字等等。

雖然固定檔是要同時用於螢幕上和紙張上，但流程檔僅供螢幕顯示使用。 若要盡可能讀取其內容，流程檔可以根據視窗大小和其他因素來調整檔的文字和圖形顯示方式。 不小心，流程檔是使用名為 FlowDocument的 XAML 元素來定義。 以下是簡單的範例：

  <FlowDocument 
    ColumnWidth="300" 
    IsColumnWidthFlexible="True" 
    IsHyphenationEnabled="True">
      <Paragraph FontSize="12">
       <Bold>Describing WPF</Bold>
      </Paragraph>
      <Paragraph FontSize="10">
       WPF is the user interface technology for the .NET 
       Framework 3.0. It provides a unified foundation for modern 
       user interfaces, including support for documents, two- and 
       three-dimensional graphics, media, and more. It also 
       allows using the same approach (and the same code) for 
       creating standalone Windows applications and applications 
       that run inside a browser.
      </Paragraph>
  </FlowDocument>

本檔要求顯示在寬度不超過 300 的資料行中。 (寬度是以 裝置無關的圖元來測量，其中每一個寬度都定義為 1/96 英吋。) 在非常下一行中，檔建立者指出此寬度是彈性的，方法是將 IsColumnWidthFlexible 屬性設定為 true。 這會授權 WPF 變更將用來顯示此檔的寬度和欄數。 如果使用者變更顯示此檔的視窗寬度，例如，WPF 可以增加或減少用來顯示檔文字的資料行數目和寬度。

接下來，檔會藉由將 IsHyphenationEnabled 屬性設定為 true 來要求連字號。 以下是本檔包含的兩個段落。 每個元素內的文字都包含在 Paragraph 元素內，每個專案都會設定不同的字型大小。 第一個段落中的文字也表示應該以粗體顯示。

WPF 會定義更多 FlowDocument 選項，以改善可讀性。 例如，如果 IsOptimalParagraphEnabled 屬性設定為 true，WPF 會在段落中盡可能平均地分散空白字元。 這可以防止空白字元的「大流」造成可讀性，這是一般使用列印檔案完成的動作。 流程檔也允許批註，例如在一般文字中新增附注，或在平板電腦上以筆跡新增附注。 每個注釋都包含 一個錨點 ，可識別批註與批註相關聯之檔中的內容，以及包含批註本身內容的 貨物 。

若要顯示 FlowDocument，WPF 包含幾個不同的控制項。 這些特性如下所示：

  • FlowDocumentPageViewer：允許一次移動一個檔。 此控制項提供向前和返回按鈕以及縮放控制項，讓使用者調整其讀取的檔案大小。
  • FlowDocumentScrollViewer：提供較傳統的 FlowDocument捲動檢視，並在頁面右側完成捲軸。
  • FlowDocumentReader：結合 FlowDocumentPageViewer 和 FlowDocumentScrollViewer的功能。 此控制項可讓使用者在流程檔的頁面導向檢視之間切換 (，包括一次) 和捲動檢視看到兩個頁面。

隨著更多和更多資訊以數位方式傳遞，螢幕閱讀體驗的品質會變得更重要。 藉由透過流程檔提供資訊的自適性顯示，WPF 會嘗試改善 Windows 使用者的此體驗。

影像

無論它們代表公司標誌、終止圖片或其他專案，影像都是許多使用者介面的基本部分。 在 WPF 中，影像通常會使用 影像 控制項來顯示。 例如，若要顯示 JPEG 檔案，可以使用下列 XAML：

<Image 
 Width="200" 
 Source="C:\Documents and Settings\All Users\Documents\
  My Pictures\Ava.jpg" />

影像的寬度會設定為 200，同樣地，這裡的單位是裝置無關的圖元。 包含影像的檔案是使用 Source 屬性來識別。

影像檔可以包含影像的相關資訊—中繼資料，例如使用者所套用的關鍵字和評等，而 WPF 應用程式可以讀取和寫入此資訊。 影像也可以以更有趣的方式使用，例如將影像繪製到旋轉三維物件的一面上。 雖然這裡所示的簡單範例說明常見的案例，但 WPF 允許以大幅更廣泛的方式使用影像。

WPF 影像 控制項可以顯示以各種格式儲存的影像，包括 JPEG、BMP、TIFF、GIF 和 PNG。 它也可以顯示使用 Microsoft Windows Media Photo (WMPhoto) 格式儲存的影像，新的 Windows Vista。 無論使用何種格式，WPF 都會依賴 Windows 映像元件 (WIC) 來產生影像。 除了程式碼器/解碼器 (通常稱為 編解碼器 ，) 列出的所有影像格式，WIC 也提供一個架構來新增協力廠商編解碼器。

視訊和音訊

隨著網路和處理器速度增加，視訊已成為人們與軟體互動方式的較大部分。 人員也花很多時間接聽其電腦上的音樂和其他音訊。 因此，WPF 提供兩者的內建支援。

該支援取決於 MediaElement 控制項。 以下是如何使用此控制項的簡單 XAML 範例：

<MediaElement 
 Source="C:\Documents and Settings\All Users\Documents\
  My Videos\Ruby.wmv" />

此控制項可以播放 WMV、MPEG 和 AVI 視訊，以及各種音訊格式。

Two-Dimensional圖形

過去 20 年，Windows 中二維圖形的建立者依賴圖形裝置介面 (GDI) 及其後續專案 GDI+。 但即使是Windows Forms應用程式也必須透過不同的命名空間來存取這項功能，2D 圖形不會整合到使用者介面技術本身。 三維圖形的情況甚至更糟，因為需要完全不同的技術 Direct3D。 使用 WPF 時，大量應用程式會消失這種複雜性。 2D 和 3D 圖形都可以直接在 XAML 中或使用 WPF 程式庫在程式性程式碼中建立。 就像 WPF 中的其他專案一樣，它們所使用的元素只是應用程式視覺化樹狀結構的另一個部分。

針對 2D 圖形，WPF 會定義應用程式可用來建立 影像的圖形 群組。 其中包括：

  • 線條：在兩點之間繪製直線。
  • Elllipse：繪製橢圓形。
  • 矩形：繪製矩形。
  • 多邊形：繪製由一組連接直線所定義的封閉圖形。
  • 聚合線條：繪製由一組連接的直線所定義的開啟圖形。
  • 路徑：繪製任意路徑所描述的圖形。 圖形可以是開啟或封閉的，而路徑中的線條可以是直線或弧形。 事實上，所有其他圖形都只是為了方便起見，因為 Path 可以用來繪製線條、橢圓形、矩形、多邊形、多邊形等。

使用這些類別來建立簡單的圖形很簡單。 例如，下列 XAML 會繪製紅色橢圓形：

<Ellipse Width="30" Height="10" Fill="Red" />

填滿圖形依賴 筆刷。 上述範例使用預設值，這是純色筆刷，但 WPF 提供數個其他選項。 例如，填滿色彩漸層的矩形可以透過下列方式定義：以水準方式從紅色變更為黃色的漸層：

<Rectangle Width="30" Height="10" 
 Fill="HorizontalGradient Red Yellow" />

另外還有數個筆刷可供使用，包括垂直漸層、星形光度，以及使用影像、點陣圖等繪製的筆刷。 雖然此處未顯示，但圖形也可以使用 畫筆 來指定其外框的色彩、寬度和樣式。

瞭解 WPF 的重要事項是，因為所有專案都是建置在通用基礎上，所以結合不同層面很簡單。 應用程式可以在Rectangle內顯示影像、在Button中放置橢圓形等等。 因此，將 2D 圖形與 3D 圖形和介面的其他部分結合相當簡單。

除了圖形之外，WPF 也提供另一組類別來處理二維圖形。 稱為 幾何，這些類別在許多圖形方面都類似。 就像圖形一樣，包括Line、Rectangle、Ellipse和Path等選項，幾何會提供LineGeometry、RectangleGeometry、EllipseGeometry和PathGeometry等選項。 這兩種類別之間的最重要差異在於，雖然圖形通常用來繪製可見影像，但幾何更常用來定義區域。 例如，如果需要裁剪方形影像以符合圓形內，可以使用 EllipseGeometry 類別來指定圓形的界限。 同樣地，如果應用程式想要定義點擊測試區域，例如偵測到滑鼠按一下的區域，則可以指定該區域的幾何來執行此動作。

最後，值得一提的是，本節中所述的所有專案實際上都是在稱為 視覺層的較低層級介面上實作。 您可以使用此圖層直接建立圖形、影像和文字。 雖然在某些情況下這樣做可能很有用，例如建立簡單、高效能的圖形，但大部分的應用程式都會使用圖形，以及 WPF 所提供的其他較高層級抽象概念。

Three-Dimensional圖形

二維圖形是 Windows 介面的常見部分，因此 WPF 在此領域提供相當多的技術。 不過，即使透過更好的資料視覺效果、3D 圖表、產品轉譯等等，三維圖形目前較不常使用，但還是可以提供大量價值。 在 3D 中工作傳統上需要不同的技能集，在遊戲開發人員和其他特製化群組之外通常找不到。 藉由支援標準環境的 3D 圖形部分，WPF 的目標是要變更此專案。

如果沒有 WPF，Windows 上的 3D 開發通常會依賴 Direct3D API。 就像 WPF 中的其他所有專案一樣，其對 3D 圖形的支援會使用 Direct3D，但開發人員會以更簡單的世界呈現。 雖然仍有使用 Direct3D 而非 WPF 的案例，如本文稍後所述，Microsoft 的意圖是 Windows 介面的主要 3D 開發使用 WPF。

若要在 WPF 中顯示 3D 圖形，應用程式會使用 Viewport3D 控制項。 此控制項基本上會提供應用程式所描述之三維世界中的視窗。 Viewport3D控制項可以在 WPF 介面中的任何位置使用，讓 3D 圖形在需要的地方出現。

若要建立 3D 場景，開發人員會描述一或多個 模型，然後指定這些模型應該如何亮起並檢視。 如往常一樣，您可以使用 XAML、程式碼或混合兩者來指定所有這些專案。 為了描述模型，WPF 會提供 GeometryModel3D 類別，以允許定義模型的圖形。 定義模型之後，就可以套用不同類型的 材質來控制其外觀。 例如 ，SpecularMaterial 類別會讓表面看起來亮亮，而 DiffuseMaterial 類別則不會。

不論其使用何種材質，模型都可以以各種方式亮起。 DirectionLight 提供來自特定方向的光線， 而 AmbientLight 為場景中的所有專案提供統一光源。 最後，若要定義應該如何檢視模型，開發人員會指定 相機。 例如 ，PerspectiveCamera允許指定從中檢視模型的距離和透視，而 OrthographicCamera 會執行相同的動作，但不含檢視方塊：相機進一步的物件不會顯示較小。

直接在 XAML 或程式碼中建立複雜的 3D 場景並不簡單。 假設對於大部分使用 3D 的 WPF 應用程式而言，開發人員會依賴圖形工具來產生必要的定義。 不過，在標準使用者介面中使用 3D 圖形的能力，可能會大幅改善使用者在螢幕上看到的內容品質。

轉換和效果

除了提供定義圖形和其他元素的方法之外，WPF 也讓開發人員能夠藉由旋轉這些元素、變更其大小等等來轉換這些專案。 在 XAML 中， RotateTransform 和 ScaleTransform 等元素可用來執行此動作。 這些轉換可以套用至任何使用者介面專案。 以下是簡單的範例：

</Button>
  <Button Content="Click Here">
   <Button.RenderTransform>
    <RotateTransform Angle="45" />
   </Button.RenderTransform>
  </Button>

RotateTransform元素會將按鈕旋轉 45 度。 旋轉這類按鈕並不特別有用，但可能表示 WPF 設計的一般性。 由於使用者介面的各種層面並不依賴不同的基礎技術，因此可以透過各種方式加以結合。

WPF 也包含一些預先定義的效果。 就像轉換一樣，這些效果可以套用至使用者介面的各種層面，例如 Buttons、 ComboBoxes等等。 它們包含模糊效果，可讓介面元素看起來模糊、讓元素顯示為光暈的外部光暈效果，以及會在介面元素後方新增陰影的陰影效果。

動畫

讓介面中的元素變成動畫效果的能力非常實用。 按一下按鈕可能會導致按鈕向下移動，例如，為使用者提供更好的意見反應。 更複雜的動畫可協助建立介面，藉由指示其注意力和故事來吸引使用者。 WPF 的動畫支援可達成此效果。

如同轉換，動畫可以套用至介面的許多不同層面，包括按鈕、圖形、影像等等。 動畫是藉由在一段時間內變更一或多個物件屬性的值來完成。 例如， Ellipse 可能會以累加方式在兩秒內遞減其 Height 屬性來緩和。

定義一組相關的動畫通常很有用。 為了允許這種情況，WPF 會提供 Storyboard 類別。 每個 分鏡腳本 可以包含一或多個 時間軸，而且其中每一個都可以包含一或多個動畫。 提供各種時間軸，讓動畫可以循序或平行方式執行。 以下是簡單的 (，雖然稍微不完整) XAML 範例，但說明橢圓形：

    <Ellipse Width="100" Height="50" Fill="Blue"
     Name="EllipseForSquashing">
     . . . 
     <Storyboard>
      <DoubleAnimation
       Storyboard.TargetName="EllipseForSquashing" 
       Storyboard.TargetProperty="Height"
        From="50" To="25" Duration="0:0:2" />
       </Storyboard>
       . . . 
    </Ellipse>

此範例的開頭是 Ellipse的定義，如本文稍早所示。 不過，這裡也會使用 Name 屬性，指派識別碼，以便稍後參考此 橢圓 形。 省略一些詳細資料，但若要在 XAML 中定義動畫， 必須顯示 Storyboard 元素。 因為 Ellipse的 Height 屬性屬於 double 類型， 所以 Storyboard 包含 DoubleAnimation 元素。 此元素會指定要以動畫顯示 之 Ellipse 的名稱、將會變更的屬性，以及這些變更的確切名稱。 在這裡， Height 的值在兩秒內從 50 變更為 25。

動畫可能比這更複雜。 事件可以觸發它們，例如按一下滑鼠、暫停再繼續、設定為重複一些次數 (或永久) 等等。 目標是要讓開發人員建立使用者介面，以提供更好的意見反應、提供更多功能，而且可能更容易使用。

資料綁定

大部分的使用者介面都會顯示某種資料。 為了讓建立這些介面的開發人員更容易使用，資料系結可用來讓顯示資料更容易。 資料系結可讓您直接連接 WPF 控制項所顯示的內容，以及存在於該控制項外部的資料。 例如，WPF TextBox控制項中的Text屬性值可能會系結至Employee物件中名稱為Name的屬性，屬於此應用程式商務邏輯的一部分。 然後，任一屬性的變更可能會反映在另一個屬性中。 如果使用者更新 TextBox中的值， Employee 物件的 Name 屬性也會變更，反之亦然。

在兩個 物件中的屬性之間建立這種連線需要使用 WPF Binding 類別。 以下是一個稍微簡化的 XAML 圖例，說明其外觀：

<TextBox . . . >
 <TextBox.Text>
  <Binding Path="Name" />
 </TextBox.Text>
</TextBox>

在此範例中， Binding 元素的 Path 屬性是用來識別 TextBox的 Text 屬性應該系結至其中的 屬性。 當 此屬性是執行時間指定 (的物件時，會使用 Path) 是 Common Language Runtime (CLR) 物件，以 C# 或 Visual Basic 等語言定義。 除了 CLR 物件之外，WPF 的資料系結也可以使用 Binding的 XPath 屬性直接連接到 XML 資料。 此選項會建立 XPath 查詢，以選取參考指定資料的 XML 檔中的一或多個節點。

您也可以使用更複雜的資料系結選項。 例如，清單系結允許從任何實作標準IEnumerable介面的 CLR 物件填入ListBox控制項的內容。 如有必要，資料也可以在顯示之前進行篩選或排序。 (雖然可以系結至 ADO.NET 資料集，但 WPF 沒有直接支援系結至關係資料庫管理系統中的資料。) 使用任何資料系結選項時，意圖是盡可能直接地在使用者介面中顯示資料。

使用者介面自動化

WPF 介面最常見的使用者當然是人員。 但有時候使用者介面需要由人類驅動，而是由其他軟體驅動。 WPF 的使用者介面 (UI) 自動化可達成此動作。

例如，假設開發人員想要建立介面的自動化測試腳本。 她可以使用 UI 自動化所提供的程式設計存取，建立腳本來驅動介面，就像人類使用者一樣。 UI 自動化也有助於建立協助工具協助工具，例如可大聲讀出介面各種元素的工具。 因為它允許以程式設計方式逐步執行包含這些專案的樹狀結構，因此 UI 自動化可讓您建置這類工具。

為了允許此情況，WPF 會建立 UI 自動化樹狀結構。 此樹狀結構包含 AutomationElement 物件，每個物件都代表介面中的某個專案。 樹狀結構的根目錄是 Desktop，而每個開啟的應用程式都是這個根目錄的子系。 樹狀結構會繼續進入每個應用程式，每個 WPF 控制項都會以一個 (表示，或有時有多個) AutomationElement 物件。 為了允許完整以程式設計方式存取介面，使用者可以與其互動的所有專案都會以不同的 AutomationElement表示。 例如，具有多個按鈕的控制項本身和每個按鈕都會以不同的 AutomationElement 物件表示。 在 UI 自動化樹狀結構中建置此層級的資料細微性，可讓用戶端應用程式、測試腳本、協助工具協助工具或其他專案存取介面的每個元件，就如同人類使用者一樣。

UI 自動化不是 WPF 的最主要層面。 大部分的人可能永遠不會使用它。 不過，需要軟體測試人員和身心障礙的使用者 ，真的 需要它。 某些專案不一定要廣泛使用才能很重要。

套用Windows Presentation Foundation

WPF 包含顯著的技術量。 雖然所有技術都與人員互動有關，但技術目前會以三種相關方式套用：獨立 WPF 應用程式、XBAP 和 XPS 檔。 本節將探討這三者的每一個。

獨立 WPF 應用程式

使用 WPF 的最一般方式是在獨立應用程式中。 獨立 WPF 應用程式會像任何其他 Windows 應用程式一樣執行，它們不需要網頁瀏覽器。 因此，獨立應用程式可以完全信任，因此可以使用所有 WPF 的功能。 完全信任也表示獨立 WPF 應用程式可以自由使用電腦上可用的其他服務，例如 Windows Communication Foundation (WCF) 。

與其他 Windows 應用程式一樣，獨立 WPF 應用程式可以從本機磁片或網路伺服器安裝。 您也可以使用 ClickOnce 安裝，這是.NET Framework中的設施。 ClickOnce 提供一種直接的方式，讓 Internet Explorer 使用者下載並安裝 Windows 應用程式，包括 WPF 應用程式，以及讓這些應用程式在變更時自動更新。

XAML 瀏覽器應用程式：XBAP

雖然獨立 WPF 應用程式提供最多功能，但它們不一定是正確的選擇。 在網頁瀏覽器中執行的用戶端，而不是 Windows 應用程式時，有許多情況更合理。 為了允許這些用戶端轉譯新式使用者介面，WPF 會提供 XBAP。

如下圖所示，XBAP 會在 Internet Explorer 內執行。 XBAP 可作為使用 ASP.NET、JAVAServer Pages (JSP) 或其他 Web 技術所建置的 Web 應用程式的用戶端。 若要與這個 Web 應用程式通訊，XBAP 可以使用 HTTP 或 SOAP。 任何使用的伺服器平臺，XBAP 一律會透過 ClickOnce 載入。 不過，它不會在此程式期間向使用者顯示任何對話方塊或提示;XBAP 會像網頁一樣載入。 因此，XBAP 不會出現在 [ 開始 ] 功能表或 [ 新增/移除程式] 中。

Aa663364.introducingwpf7b (en-us，MSDN.10) .gif

圖 7. 在 Internet Explorer 內執行的 XBAP

雖然並非絕對必要，但 XBAP 通常會向使用者呈現導覽介面。 這可讓應用程式的行為與 Web 用戶端類似，這可能是使用者預期的情況。 在 Internet Explorer 7 中，XBAP 會使用瀏覽器本身的向前和返回按鈕，而使用者存取的 XAML 頁面會出現在瀏覽器的歷程記錄清單中。 在 Internet Explorer 6 中，XBAP 會顯示自己的向前和返回按鈕，以及維護自己的歷程記錄清單。 XBAP 可以判斷其執行所在的環境，並執行正確的動作;開發人員不需要為每個瀏覽器建立不同的版本。

因為從 Web 載入並在瀏覽器中執行，所以 XBAP 只會受到.NET Framework的程式碼存取安全性所限制的信任。 因此，有一些獨立 WPF 應用程式可以執行 XBAP 無法執行的動作。 例如，從網際網路區域部署的 XBAP 無法執行下列任何動作：

  • 建立獨立視窗。
  • 顯示應用程式定義的對話方塊。
  • 顯示 XBAP 本身啟動的 [ 儲存] 對話方塊。
  • 存取超出有限隔離儲存區域的檔案系統。
  • 做為使用者介面自動化用戶端。
  • 使用 WCF。 WCF 應用程式必須完全信任，因此從網際網路部署的 XBAP 無法使用它。 他們可改為使用 ASP.NET Web 服務，也就是 ASMX，與載入來源的 Web 應用程式通訊。
  • 使用以 Windows Forms、Microsoft Foundation Classes (MFC) 或直接 Win32 呼叫建立的任何使用者介面程式碼。 雖然獨立 WPF 應用程式可以與所有這些較舊的技術互通，如稍後所述，但 XBAP 的有限信任環境中不允許這些技術。
  • 使用 Unmanaged 程式碼。

如先前所述，可以針對獨立 WPF 應用程式和 XBAP 使用相同的程式碼基底。 若要允許這種情況，開發人員可能會使用條件式編譯，包裝 ifdefs 內 XBAP 中不允許的任何功能。 XBAP 版本可以執行獨立應用程式所能執行的大部分工作，包括使用二維和三維圖形、播放視訊和音訊等等來顯示檔。 它也可以利用其執行所在的電腦上可用的任何圖形硬體。

除了 XBAP 之外，您也可以直接在 Internet Explorer 中顯示純 XAML 頁面。 稱為 鬆散 XAML，這對於在瀏覽器中顯示靜態頁面很有用。 不過，處理事件需要程式碼，這表示建立 XBAP。

XBAP 可讓開發人員在瀏覽器應用程式中使用大部分的 WPF 功能。 它們也允許一般程式設計模型，在獨立應用程式和瀏覽器應用程式中使用大部分相同的程式碼。 對於用戶端以較新 Windows 平臺為目標的 Web 應用程式，XBAP 可能是吸引人的選擇。

XPS 文件

在 WPF 世界中，固定格式的檔表示 XPS 檔在使用者介面中顯然具有角色。 如先前所述，WPF 會提供 DocumentViewer 控制項來顯示 XPS 檔。 不過，雖然在 WPF 中包含此控制項確實合理，但 XPS 本身應該被視為 WPF 的一部分較不明顯。 同樣地，XPS 規格提供高度詳細的方法來定義固定格式的檔，而且檔本身可以使用不同的方式使用。 WPF 中所有其他專案只會著重于建立使用者介面。 假設其更廣泛的 purview，為什麼在 WPF 保護底下包含 XPS？

其中一大原因是 XPS 檔是使用 XAML 來定義。 只會使用一小部分的 XAML，包括 Layout 的 Canvas 元素、代表文字的 Glyphs 元素，以及用來建立二維圖形的 Path 元素，但每個 XPS 檔實際上是 XAML 檔。 因此，檢視 XPS 作為 WPF 的一部分是可行的。

不過，其中一個 XPS 最重要的應用程式不是關於螢幕上的使用者介面。 從 Windows Vista 開始，XPS 會成為 Windows 的原生列印格式。 XPS 可作為分頁描述語言，因此 XPS 檔可以直接由 XPS 感知印表機轉譯。 這允許使用單一描述格式-XAML，從螢幕到印表機。 它也會改善 Windows 中現有的 GDI 型印表機制，為複雜的圖形效果提供更好的列印支援，例如透明度和漸層。

除了 XAML 之外，XPS 檔也可以包含二進位資料，例如各種格式的影像 (，包括 JPEG、PNG、TIFF 和 WMPhoto) 、字型資料、檔結構的相關資訊等等。 如有必要，XPS 檔也可以使用 W3C XML 簽章定義和 X.509 憑證進行數位簽署。 不論它包含什麼，每個 XPS 檔都會以開放式封裝慣例所定義的格式儲存， (OPC) 。 OPC 指定 XML 檔的各種部分 (不只是 XPS 或 XAML 檔) 相關、它們如何以標準 ZIP 格式儲存等等。 Microsoft Office 2007 也會針對其 XML 格式使用 OPC，提供這兩種檔之間的一些共通性。

WPF 應用程式的使用者可以透過 WPF DocumentViewer 控制項檢視 XPS 檔，如先前所述。 Microsoft 也提供以 DocumentViewer 控制項為基礎的 XPS 檢視器應用程式，如下所示。 如同控制項，此應用程式可讓使用者逐頁流覽檔、搜尋文字等等。 XPS 檔並非 Windows 特定，因此 Microsoft 也計畫為其他平臺提供 XPS 檢視器，例如 Apple Macintosh。

Aa663364.introducingwpf7 (en-us，MSDN.10) .gif

圖 8. XPS 檢視器允許一次讀取 XPS 檔。

為了讓開發人員使用 XPS 檔，WPF 提供一組 API 來建立、載入及操作它們。 WPF 應用程式也可以在 OPC 層級使用檔，允許對 XPS 檔、Office 2007 檔和其他檔的一般化存取。 使用 Microsoft Windows Workflow Foundation 建置的應用程式也可以使用這些 API 來建立使用 XPS 檔的工作流程。

藉由允許應用程式顯示和使用固定格式檔，WPF 會將新式使用者介面的這個元件整合到其一致的方法中。 藉由使用相同的格式來列印檔案，Windows Vista 可讓人們在畫面上看到的內容和他們在紙張上看到的內容之間有更好的比對。 雖然這種類型的檔可能不是使用者介面技術預期的第一件事，但 XPS 的廣泛使用說明 WPF 等技術可以涵蓋的範圍。

適用于Windows Presentation Foundation的工具

WPF 為開發人員提供許多功能，這是件好事。 不過，無論其功能有多強大，一項技術都可以透過良好的工具更有用。 針對 WPF，Microsoft 提供一個專門以開發人員為目標的工具，另一個則以設計工具為目標。 本節會簡短探討這兩者。

適用于開發人員：Visual Studio

Visual Studio 是 Microsoft 的軟體發展人員工具。 一開始發行 WPF 時，Microsoft 會提供 Visual Studio 2005 的延伸模組，讓開發人員建立 WPF 應用程式。 下一個 Visual Studio 版本的程式碼命名為 「Orcas」，將會新增更多專案，包括 WPF 的 Visual Designer (，其程式碼名稱為 「Cider」) 。 使用此視覺化檢視，開發人員將能夠以圖形方式建立 WPF 介面，然後自動產生基礎 XAML。 雖然尚未宣佈正式發行日期，但 Orcas 已排定在 2007 年寄送。

針對設計工具：運算式互動式Designer

如先前所述，WPF 的主要目標是讓設計工具在建立使用者介面時成為第一級公民。 XAML 可達成此情況，但只有在提供可讓設計工具在此新世界中運作的工具時。 為此，Microsoft 已建立 Expression Interactive Designer。

如下列螢幕擷取畫面所示，Expression Interactive Designer提供傳統設計工具的一些層面，讓使用者能夠以熟悉的方式運作。 但Designer專門著重于建立 WPF 應用程式的介面。 (事實上，此工具的介面本身是使用 WPF.) 注意事項來建置，例如，螢幕右上方的 WPF 控制項清單，以及底部的圖形時間軸。 所有這些都對應至本文稍早所述的 WPF 功能，而且所有功能都可供介面設計工具使用。 動畫可以圖形方式建立，如同轉換、效果等等。 設計工具工作的結果會以工具所產生的 XAML 檔案表示，然後可以匯入 Visual Studio。

Aa663364.introducingwpf8 (en-us，MSDN.10) .gif

圖 9. 運算式互動式Designer可讓設計工具建立 WPF 介面。[圖 8]

運算式互動式Designer是 Microsoft Expression 系列三個成員的其中一個。 其他則是 Expression Web Designer、建立標準型 Web 介面的工具，以及運算式圖形Designer，這是用來建立向量和/或點陣圖影像的工具。 在三者中，只有 Expression Interactive Designer著重于建立 WPF 應用程式的使用者介面。 例如，設計工具可能會使用其他人來建立使用者介面的元件，可能是使用運算式圖形Designer來建立介面的 GIF 影像，但這些工具並非 WPF 特有的。 雖然尚未宣佈日期，但所有 Expression 工具都會排定在 WPF 發行之後傳送。

Windows Presentation Foundation和其他 Microsoft 技術

如同大部分新的 Microsoft 技術，WPF 會影響 Windows 世界的其他部分。 不過，在查看這些效果之前，請務必瞭解在系統上安裝 WPF 不會中斷任何使用 Windows Forms、MFC 或任何其他現有技術的軟體。 雖然針對支援 .NET Framework 3.0 的系統撰寫的新應用程式很可能使用 WPF 建置其介面，但使用這些舊版技術的應用程式仍會繼續保持不變執行。

Windows Presentation Foundation和Windows Forms

自初始發行.NET Framework之後，許多應用程式都是使用 Windows Forms 建立的。 即使 WPF 抵達，某些應用程式仍會繼續使用Windows Forms。 例如，必須在無法使用 WPF 的系統上執行的任何專案，例如較舊的 Windows 版本，最有可能為其使用者介面選擇Windows Forms。 新的應用程式也可能因為其他原因而選擇Windows Forms WPF，例如可供Windows Forms使用的廣泛控制項集。

即使是使用 WPF 建置的應用程式，也可能受益于使用Windows Forms的某些層面。 例如，Windows Forms目前有一組比 WPF 更多的可用控制項。 .NET Framework 2.0 版引進的DataGridView控制項在 WPF 中沒有類比，而協力廠商已為許多其他用途建立Windows Forms控制項。 在某些情況下，讓 WPF 應用程式使用這些現有的控制項可能很合理。 相反地，WPF 提供許多Windows Forms未提供的專案，例如 3D 圖形和動畫。 允許現有的Windows Forms應用程式納入 WPF 功能的各個部分也有意義。

這兩件事都是可行的。 WPF 應用程式可以裝載Windows Forms控制項，而Windows Forms應用程式可以裝載 WPF 控制項。 使用者可以與 WPF 對話方塊互動，並在相同的應用程式中Windows Forms對話，通常不會察覺到有任何差異。

若要裝載Windows Forms控制項，WPF 應用程式依賴 WPF 的WindowsFormsHost控制項。 如其名所示，此控制項能夠裝載Windows Forms控制項，使其可在 WPF 應用程式中使用。 它也可以裝載 ActiveX 控制項，讓 WPF 應用程式能夠存取使用此舊版技術所建立的大型現有程式庫。 同樣地，Windows Forms應用程式會使用ElementHost，這是可裝載 WPF 控制項、面板和其他專案的Windows Forms控制項。 每個技術的工具也可以搭配為另一種技術撰寫的軟體使用。 WPF 的 Visual Designer可用來定位Windows Forms控制項，而Windows Forms設計工具可用來放置 WPF 控制項。

一起使用 WPF 和Windows Forms確實有一些限制。 例如，將 WPF 控制項分層在Windows Forms控制項上方將無法運作;Windows Forms控制項一律會位於頂端。 WPF 的透明度效果也不適用於Windows Forms控制項，也不會讓 WPF 轉換正常運作。 而且因為 WindowsFormsHost 和 ElementHost 控制項需要完全信任，所以使用它們的 WPF 應用程式無法以 XBAP 的形式執行。 不過，大部分的 Windows 應用程式都可以使用 WPF 和Windows Forms來建立其使用者介面。

Windows Presentation Foundation 和 Win32/MFC

在 2002 年發行.NET Framework之前，Windows 開發人員通常會使用直接呼叫 WIN32 API 或 MFC 來建置使用者介面，提供這些 API 周圍的 C++ 包裝函式。 因此，現在有許多程式碼存在，且介面是以這個樣式建立。 WPF 世界中此程式碼會發生什麼事？

答案類似于Windows Forms的情況。 同樣地，WPF 控制項可以裝載在現有的 Win32/MFC 程式碼內，而現有的 Win32/MFC 控制項可以裝載于 WPF 內。 (事實上，WPF 與Windows Forms之間的互通功能實際上建置於 Win32/MFC 互通性服務之上。) WPF 提供HwndHost類別，以允許在 WPF 中使用 Win32/MFC 控制項，以及HwndSource類別，讓 WPF 控制項用於 Win32/MFC 應用程式中。 每個類別會視需要對應這兩種技術。 例如，HwndHost會讓用來參考 Win32/MFC 控制項的hWnd看起來像 WPF 控制項。 HwndSource 會執行相反動作，讓 WPF 控制項看起來像 hWnd。

如同Windows Forms，混用這兩個世界有一些限制。 事實上，由於Windows Forms互通性依賴HwndHost和HwndSource，因此先前針對Windows Forms控制項所述的所有限制，例如分層和透明度的限制，也適用于此處。 此外，不同于Windows Forms，混合 WPF 與 Win32/MFC 程式碼的應用程式面臨在 WPF Managed 程式碼環境與 Win32 非受控世界之間互通的新增挑戰。 基於這個和其他原因，使用 Win32/MFC 程式碼的 WPF 應用程式無法以 XBAP 的形式執行。 不過，如同之前一樣，Windows 應用程式可以同時使用 WPF 和 Win32/MFC。 使用 WPF 不需要捨棄所有應用程式現有的使用者介面程式碼。

Windows Presentation Foundation 和 Direct3D

Direct3D 是 Microsoft DirectX 系列 API 的一部分，是建立三維圖形的 Windows 開發人員的主要支援。 WPF 的問世無法淘汰 Direct3D。 事實上，如先前所述，WPF 完全依賴 Direct3D 進行轉譯。 不過，由於 WPF 也允許開發人員建立 3D 圖形，因此在 3D 中工作的開發人員必須決定兩者之間。

不過，決策並不特別困難。 Direct3D 仍然是大量 3D 開發的最佳選擇，例如遊戲和以 3D 為中心的技術應用程式，例如高階科學視覺效果。 至少在第一個版本中，WPF 並非設計為這類軟體的平臺。

不過，WPF 讓 3D 圖形可供更廣且較不特殊的物件使用。 它也允許在 XBAP 中使用 Web 上的 3D 圖形，並自然地與應用程式使用者介面的二維圖形、檔和其他層面整合。 WPF 應用程式也可以透過稍早所述的 HwndHost 類別來裝載 Direct3D 程式碼。 WPF 和 Direct3D 都有不同的角色，而且兩者在 Windows 平臺中都有良好的未來。

Windows Presentation Foundation和 AJAX/「Atlas」

開發人員可以使用 AJAX 來建立更回應使用者的瀏覽器用戶端。 AJAX 可讓使用者與應用程式互動，而不需要頁面重新整理 (，因此會針對每個要求來回前往 Web 服務器) 。 為了達成此目的，AJAX 依賴瀏覽器對 XMLHttpRequest 物件的支援，這是在 1990 年代之後第一次出現在 Internet Explorer 5.0 的概念。 在接下來的十年中， XMLHttpRequest 的支援在瀏覽器中已廣泛出現，而 AJAX 現象已產生。

不過，建立 AJAX 用戶端並不特別簡單。 為了協助進行程式，Microsoft 已建立一組名為 「Atlas」 的技術程式碼。Atlas 是一組程式庫、控制項等等，可用於建立 AJAX 應用程式。 它包含可在各種瀏覽器中運作的用戶端腳本程式庫，而不只是 Internet Explorer，以及用於 ASP.NET 的伺服器端擴充功能。 目標是使用 AJAX 用戶端簡化建置 Web 應用程式。

AJAX 的廣泛瀏覽器支援讓開發人員非常吸引人。 不過，即使 AJAX 允許為 Web 使用者建立更多互動式介面，它也不會為更廣泛的內容類型新增支援。 AJAX 不支援圖形、視訊、動畫和其他更現代化的互動樣式。 對於支援 WPF 的用戶端，需要這些的應用程式可能會改為撰寫為 XBAP。

Windows Presentation Foundation和 「WPF/E」

使用 XBAP，Web 應用程式可以提供其大部分 WPF 功能的使用者。 不過，XBAP 需要在用戶端電腦上安裝 WPF，以限制其適用性。 需要呈現新式介面但也必須從 Macintoshes 和其他不支援 WPF 的系統存取 Web 應用程式呢？

即將推出的名為 「WPF/E」 的技術旨在解決此問題。 WPF/E— 「E」代表「隨處」—會在各種用戶端平臺上提供 WPF 功能的子集，包括 Macintosh、較小的裝置和其他裝置，以及各種網頁瀏覽器，包括 Internet Explorer、Firefox 和 Netscape。 此子集包含二維圖形、影像、影片、動畫和文字。 不過，XBAP 可以從 WPF/E 省略某些功能，包括三維圖形、檔和硬體加速的支援。

若要建立 WPF/E 應用程式，開發人員可以使用 JavaScript。 WPF/E 也會包含.NET Framework的跨平臺子集，以 C# 和 Visual Basic 進行開發。 WPF/E 不是 .NET Framework 3.0 的一部分，因此不會排程在 2007 年一段時間之前發行。 一旦可供使用，Web 應用程式的建立者將會有另一個選項，其中一個選項會在各種平臺上提供一系列功能，以建置用戶端。

結論

使用者介面是大部分應用程式的基本重要部分。 讓這些介面生效可能會對依賴這些介面的人員和組織帶來可測量的優點。 WPF 的主要目標是協助開發人員提供這些優點，因此對於建立或使用 Windows 應用程式的任何人員而言，WPF 都是大新聞。

藉由為新式使用者介面提供統一的平臺，協助設計工具主動參與建立這些介面，並允許獨立和瀏覽器應用程式的通用程式設計模型，WPF 的目標是大幅改善 Windows 使用者體驗。 其計劃性的某些技術執行了二十年，做為 Windows 使用者介面的基礎。 WPF 的目的是要為下二十年配置基礎。

 

關於作者

David Chappell 是 San Californiao (www.davidchappell.com) 的 Chappell & Associates 主體。 透過他的演講、撰寫和諮詢，他可協助世界各地的技術專業人員瞭解、使用及制定企業軟體的更佳決策。