且看WPF应用程序与window Form、MFC、Direct 3D、AJAX/"Atlas"、"WPF/E"、大比较

 

简单的windows form

//App.xaml
<Application x:Class="wpftest.App"
     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
     StartupUri="Window1.xaml"
     >
     <Application.Resources>

     </Application.Resources>
</Application>

 

StartupUri 属性來指示在启动应用程式时应载入和显示的 XAML 页面其名称。最后的属性是 Class

//Window1.xaml
<Window x:Class="wpftest.Window1" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" Title="wpftest" Height="300" Width="300">
<Grid>
   <Button Background="red" Name="btntest" Click="btn_click" Margin="100,100,100,100">No</Button>

   <Button   Height="30" Width="30"   Content="按此">
      <Button.RenderTransform>
        <RotateTransform Angle="45" />
      </Button.RenderTransform>
   </Button>

</Grid>
</Window>

其中一个按钮在点击时执行btn_click函数
这个函数应写在
Window1.xaml.cs中

public partial class Window1 : Window
{

public Window1()
{
   InitializeComponent();
}

public void btn_click(object sender,System.EventArgs e)
{
   MessageBox.Show("I was clicked,and i will change color");
   Button btn=sender as Button;

   if(null!=btn)
   {
    btn.Background=Brushes.Blue;
   }
}

}

 

由於使用者介面上有許多地方都會用到文字。文件顯示方式的改進可以提升屏幕文字的可讀性，WPF 支援兩種文件：固定 (Fixed) 文件和流動 (Flow) 文件。

固定文件在螢幕上和書面上看起來一模一樣。對某些表單、法律文件等它種出版而言，瞭解到文件外觀保持一致是很重要的一點，所以固定文件在某些領域的重要性不容忽視。WPF 支援的固定文件是由 XPS 所定義的，固定文件的內容可用 XAML 的 FixedDocument 項目來指明，這個簡單的項目只包含一個 PageContent 項目清單，每個項目裡含有固定文件中的某個頁面名稱。為了顯示固定文件，WPF 提供 DocumentViewer 控制項，它以唯讀方式顯示 XPS 文件，讓讀者能在文件中前後移動、搜尋文字或進行其他工作。

固定文件適用於螢幕與書面，而流動文件只適用於在螢幕上顯示。為了盡可能提高流動文件的內容可讀性，這些文件可以調整文件的文字，而圖形是按視窗大小與其他要素來顯示的。流動文件是利用一個叫做 FlowDocument 的 XAML 項目進行定義的，範例如下：
//FlowDocument1.xaml

<FlowDocument xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" ColumnWidth="400" FontSize="14" FontFamily="宋体" IsColumnWidthFlexible="True" IsHyphenationEnabled="True">
<Paragraph FontSize="12">
   <Bold>描述 WPF</Bold>
</Paragraph>
<Paragraph FontSize="10">

 

    WPF 是用於 .NET Framework 3.0 的使用者介面技術。
    它為現代化使用者介面提供統一的基礎，包括支援
    文件、平面圖形、立體圖形、媒體等等。它也
    允許適用同樣的方式 (以及同樣的程式碼) 來
    建立獨立 Windows 應用程式以及在瀏覽器內
    執行的應用程式。

<Image   Width="200"   Source="C:\testeg\0042.jpg" />

<Ellipse Width="50" Height="50" Fill="Red" />


   </Paragraph>
</FlowDocument>

在文件中可以放入音乐,
<MediaElement Source="C:\testeg\yzhxy.mp3"/>
但是这样PresentationFontCache.exe会占用大量的内存

IsColumnWidthFlexible 为 True，指明寬度是可以調整的，如此一來，WPF 就能變更將用來顯示這份文件的欄位寬度和欄位數目。
IsHyphenationEnabled 为 True，以啟用斷字功能，

Windows Presentation Foundation 與其他的 Microsoft 技術

WPF 和多半的 Microsoft 新技術一樣，也會影響到 Windows 技術。在詳述前，我想先說明一點:：在系統上安裝 WPF 並不會損壞任何使用 Windows Form、MFC 或其他現有技術的軟體。為 .NET Framework 3.0 的支援系統所撰寫的新應用程式會採用 WPF 來建置它們的介面，而使用舊有技術的應用程式仍繼續執行，不受到任何影響。
Windows Presentation Foundation 和 Windows Form

自從 .NET Framework 問世以來，許多應用程式就是採 Windows Form 建立而成的，現在就算有了 WPF，一些應用程式還是會繼續使用 Windows Form。舉例來說，只要執行應用程式的系統上沒有可用的 WPF，例如舊版的 Windows，這種情況下就很可能必須使用 Windows Form 來建立使用者介面。新的應用程式其實也可能因為其他因素 (例如，Windows Form 有豐富的控制項) 而採用 Windows Form，而不使用 WPF。

就算是使用 WPF 建立的應用程式，也可以因為使用某些 Windows Form 功能而受益。舉例來說，目前 Windows Form 的控制項比 WPF 豐富，以 .NET Framework 2.0 所引進的 DataGridView 控制項而言，WPF 裡面就還沒有對等的控制項，而且第三方廠商也已經建立了許多 Windows Form 供大家使用，在某些情況下，讓 WPF 應用程式使用這些現有的控制項能帶來許多好處。相反的，WPF 提供不少 Windows Form 所沒有的東西，例如立體繪圖與動畫，允許現有的 Windows Form 應用程式與 WPF 的功能整合為一，也是明智之舉。

上述兩種方法都是可行的，WPF 應用程式能夠裝載 Windows Form 控制項，而 Windows Form 應用程式也能裝載 WPF 控制項。使用者可以在同一個應用程式裡與 WPF 對話方塊及 Windows Form 對話方塊進行互動，而且一點都不會意識到兩種間的差異。

WPF 應用程式如果要裝載 Windows Form 控制項，就必須使用 WPF 的 WindowsFormsHost 控制項。這個控制項正如其名，能夠裝載 Windows Form 控制項，並且還允許它們從 WPF 應用程式裡被使用；此外，它還能裝載 ActiveX 控制項，讓 WPF 應用程式存取採用此舊有技術所建立而成的大型程式庫。同樣地，Windows Form 應用程式需要使用 ElementHost，這是一個能裝載 WPF 控制項、面板以及它種元素的 Windows Form 控制項。這兩者間，一個技術的特有工具能與針對另一個技術所撰寫的軟體搭配使用；WPF 的 Visual Designer 能夠用來放置 Windows Form 控制項，Windows Form 的設計工具能用來放置 WPF 控制項。

將 WPF 和 Windows Form 技術合併使用時有一些限制，舉例來說，將 WPF 控制項置於 Windows Form 控制項之上是不可行的，Windows Form 控制項一定要在最上層；如果將 WPF 的透明度效果與 Windows Form 控制項搭配使用，效果不彰，WPF 的轉換也一樣 。而且，因為 WindowsFormsHost 和 ElementHost 兩個控制項要求完全信任，所以使用它們的 WPF 應用程式無法執行成 XBAP。不過，大部分的 Windows 應用程式都能使用 WPF 和 Windows Form 來建立它們的介面。
Windows Presentation Foundation 和 Win32/MFC

在 2002 年的 .NET Framework 問世之前，Windows 開發人員最常用的使用者介面建置方法就是直接呼叫Win32 API 或是直接呼叫 MFC，因此為 API 提供了 C++ 包裝函式。因此，當今有許程式碼都具有這種介面，現在碰上了 WPF，我們要如何處理這些程式碼呢？

答案其實跟 Windows Form 的情況很類似，您可以在現有 Win32/MFC 程式碼內裝載 WPF 控制項，也可在 WPF 裡面裝載 Win32/MFC 控制項 (事實上，用於 WPF 與 Windows Form 之間交互操作的設備就是以 Win32/MFC 交互操作服務為基礎建置的)。WPF 提供 HwndHost 類別，允許在 WPF 裡使用 Win32/MFC 控制項，並也提供 HwndSource 類別，允許在 Win32/MFC 應用程式中使用 WPF 控制項。每個類別都會依需要來對應這兩種技術，舉例來說，HwndHost 就讓用來參照 Win32/MFC 控制項的 hWnd 看似 WPF 控制項，相反的，HwndSource 使 WPF 控制項看起來像是 hWnd。

在混用這兩種程式碼時仍有一些限制，這和 Windows Form 的情況一樣。其實，由於 Windows Form 的交互操作性是依靠 HwndHost 和 HwndSource，前一節提到的所有有關 Windows Form 控制項的限制，像是 Windows Form 控制項一定要在最上層和透明度方面的限制等，在此都適用。此外，與 Windows Form 不同的一點是，併用 WPF 和 Win32/MFC 的程式碼在 WPF Managed 程式碼環境與 Win32 的 Unmanaged 程式碼之間的交互操作方面，面臨比較大的挑戰。因此，使用 Win32/MFC 程式碼的 WPF 應用程式不可以當成 XBAP 執行。不過，正如我前面提到的，Windows 應用程式能兼用 WPF 以及 Win32/MFC，使用 WPF 並不代表必須拋棄現有應用程式的所有使用者介面程式碼。
Windows Presentation Foundation 和 Direct3D

Direct3D 是 Microsoft 的API DirectX 系列之一，它也是建立立體圖形的 Windows 開發人員的主要支柱。WPF 的問世並不代表 Direct3D 就該受到淘汰，事實上，我前面已解釋過，WPF 完全依賴 Direct3D 進行轉譯工作。不過，因為 WPF 也提供開發人員建立立體圖形的功能，開發人員在繪製立體圖形時必須二選一。

然後，這個抉擇並不困難，Direct3D 仍是開發高難度立體圖案的最佳選擇，像是遊戲和以立體圖形為主的技術應用程式 (例如高端的精密視覺化應用程式)，而 WPF 的第一個發行版本並非針對此類軟體而設計。

不過，WPF 的確將立體圖形繪製推廣至不具有專精技能的使用者。它還允許利用 XBAP 來使用 Web 的立體圖形，將它們與平面圖形、文件及應用程式使用者介面的其他組件等緊密整合。此外，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"

Web 應用程式若使用 XBAP，就能提供使用者絕大部分的 WPF 功能，但是 XBAP 要求要在用戶端電腦上安裝 WPF，而這對它的適用性大打折扣，像是那些必須呈現現代化介面而且必須從 Macintosh 或其他不支援 WPF 的系統上存取的 Web 應用程式，它們要怎麼辦呢？

為了因應此問題，日後即將會推出一個代碼為「WPF/E」的技術。WPF/E 裡的 E 代表的是 Everywhere (任何地方)，它能在多種用戶端平台上提供一個WPF 功能子集，這些平台包括 Macintosh、小型裝置等平台，而網頁瀏覽器則包括 Internet Explorer、Firefox 和 Netscape。這個子集包括平面圖形、影像、視訊、動畫和文字等。不過，WPF/E 裡面省略了一些 XBAP 的功能，像是對立體圖形、文件和硬體加速等功能。

開發人員可以利用 JavaScript 來建立 WPF/E 應用程式。WPF/E 還會包含 .NET Framework 的跨平台子集，允許利用 C# 和 Visual Basic 進行開發工作。WPF/E 並非 .NET Framework 3.0 的一部分，因此會等到 2007 年時才發行，屆時 Web 應用程式的建立者在用戶端的建置方面就多了一項選擇。此一選擇讓他們能使用更多種平台，並且擁有更廣的平台功能。
結論

在許多應用程式裡面，最重要的部分莫非於使用者介面。盡可能地提升介面效率，能為依賴它的使用者和組織帶來龐大的利益。而 WPF 的主要目標就是協助開發人員提供這些利益，因此，對建立或使用 Windows 應用程式的人士而言，WPF 是一大福音。

WPF 能為現代化使用者介面提供統一的平台，有助設計人員積極參與這些介面的建立，並允許為獨立應用程式與瀏覽器應用程式使用共同的程式撰寫模型，它的目標在於大幅改善 Windows 的使用經驗。一些它將取代的技術，在過去 20 多年來一直是 Windows 使用者介面的基礎。而 WPF 的目的是要替未來 20 年奠定良好的根基。