CH01_WPF概述

来源:https://www.cnblogs.com/kaige-chen/p/18361011
-Advertisement-
Play Games

第1章:WPF概述 本章目標 瞭解Windows圖形演化 瞭解WPF高級API 瞭解解析度無關性概念 瞭解WPF體繫結構 瞭解WPF 4.5 WPF概述 ​ 歡迎使用 Windows Presentation Foundation (WPF) 桌面指南,這是一個與解析度無關的 UI 框架,使用基於矢 ...


第1章:WPF概述

本章目標

  • 瞭解Windows圖形演化
  • 瞭解WPF高級API
  • 瞭解解析度無關性概念
  • 瞭解WPF體繫結構
  • 瞭解WPF 4.5

WPF概述

​ 歡迎使用 Windows Presentation Foundation (WPF) 桌面指南,這是一個與解析度無關的 UI 框架,使用基於矢量的呈現引擎,構建用於利用現代圖形硬體。 WPF 提供一套完善的應用程式開發功能,這些功能包括 Extensible Application Markup Language (XAML)、控制項、數據綁定、佈局、二維和三維圖形、動畫、樣式、模板、文檔、媒體、文本和版式。 WPF 屬於 .NET,因此可以生成整合 .NET API 其他元素的應用程式。

Windows 圖形演化

​ 在WPF問世之前的近15個年頭,Windows開發人員一直在使用本質上相同的顯示技術。究其原因,是由於此前的每個系統 Windows應用程式都依靠 Windows操作系統的如下兩個由來已久的部分創建用戶界面:

  • User32: 該部分為許多元素(如視窗、按鈕和文本框等)提供了熟悉的Windows 外觀。
  • GDI/GDI+: 該部分為渲染簡單形狀、文本以及圖像提供了繪圖支持,但增加了複雜程度(而且通常性能較差)。

DirectX:新的圖形引擎

​ Microsoft 曾針對 User32 和 GDVGDi+庫的限制提供了一個解決方案:DireaXk。Direstk起初是一個易於出錯的組合性質的工具包,用於在Windows 平臺上開發游戲。DirectX 在設計上關註的重點是速度,為此,Microsof 和顯卡供應商密切合作,以便為 DirectX 提供複雜的紋理映射、特殊效果(如半透明)以及三維圖形所需的硬體加速功能。

​ 在首次發佈 Direct X(在Windows 95 發佈後不久發佈)後歷經數年的發展,DirectX 已趨成熟。現在的 DirectX 已成為 Windows 的基本組成部分,可支持所有現代顯卡。然而,DirectX 編程API一直未背離其設計初衷,仍主要作為游戲開發人員的工具包。因為 DirectX 固有的複雜性,它幾乎從未用於開發傳統類型的 Windows 應用程式(如商業軟體)。

​ WPF 徹底扭轉了這種局面。在 WPF 中,底層的圖形技術不再是 GDIGDI+,而是 Diresdk,事實上,不管創建哪種用戶界面,WPF 應用程式在底層都是使用DirectX。這意味著,無論設計複雜的三維圖形(這是 DirectX的特長),還是僅繪製幾個按鈕和純文本,所有繪圖工作都是通過 DirectX 管線完成的。因此,即使是最普通的商業應用程式也能使用豐富的效果,如半透明和反鋸齒。在硬體加速方面也帶來了好處,DirectX 在渲染圖形時會將儘可能多的工作遞交給圖形處理單元(GPU)去處理,GPU 是顯卡專用的處理器。

註意:

​ 因為Direcex 能理解可由顯卡直接渲染的高層元素,如紋理和漸變,所以Dircaix 效率更高.
而 GDIGDI+不理解這些高層元素,因此必須將它們轉換成逐像素指令,而通過現代顯卡渲染這些指令更慢。

​ 不過,仍有一個 User32組件得以保留,該組件只用於有限的範圍。因為對於特定服務,WPF仍依賴於 User32,如處理和路由輸入信息以及區分哪個應用程式實際擁有屏幕的哪一部分。但所有繪圖操作都是由 DirectX 完成的。

硬體加速與 WPF

​ 顯卡在支持特定誼染特性和優化方面是有區別的。令人感到慶幸的是,這並不是什麼問題,原因有兩點。首先,當今大多數電腦配備的顯卡硬體都足以支持 3D繪圖和動畫等WPF 功能。
即使是使用集成圖形處理器(圖形處理器集成到主板中,而非獨立的卡)的攜帶型電腦和桌面電腦也同樣如此。其次,WPF為要完成的所有工作都預備了軟體處理方式。這意味著,WPB的智能程度足夠高,會儘量採用硬體優化方式,但如有必要,它也可採用軟體計算方式來完成同樣的工作。因此,如果在配備舊式顯卡的電腦上運行WPF應用程式,界面仍將按其設計方式顯示。當然,採用軟體計算方式時,速度自然會慢很多,而且配備舊式顯卡的電腦不能十分順暢地運行富WPF 應用程式。如果富 WPF 應用程式包含複雜動畫或其他密集圖形效果,這表現得尤為明顯。

什麼是WPF

WPF(Windows Presentation Foundation)是由微軟開發的桌面應用程式框架,用於創建現代化、高度交互和具有視覺吸引力的用戶界面。它是 .NET Framework 的一部分,提供了一種基於 XAML(Extensible Application Markup Language)語言的聲明性編程模型,可以很容易地創建動態、靈活的用戶界面,並且可以與其他 .NET 技術無縫集成。WPF 還具有強大的數據綁定和可重用性,使開發人員可以更快地構建和維護應用程式。WPF 也支持硬體加速和高解析度顯示,為用戶帶來更好的體驗。

WPF和Winform的區別

WPF(Windows Presentation Foundation)和 WinForms(Windows Forms)都是用於創建 Windows 桌面應用程式的框架,但它們有一些重要的區別:

  1. 編程模型:WPF 是基於 XAML 的聲明性編程模型,它可以很容易地創建動態、靈活的用戶界面,支持動畫和高級視覺效果。而 WinForms 則是基於傳統的命令式編程模型,需要在代碼中手動設置每個控制項的屬性和事件處理程式。
  2. 數據綁定:WPF 有一個強大的數據綁定系統,可以將 UI 元素和數據源相互綁定,使應用程式更容易管理和更新數據。WinForms 也支持數據綁定,但不如 WPF 靈活。
  3. 可重用性:WPF 支持樣式和模板,使 UI 元素可以輕鬆地重用和自定義,這大大簡化了應用程式的開發和維護。WinForms 則需要手動創建每個 UI 元素,不太容易重用。
  4. 矢量圖形和解析度:WPF 使用矢量圖形,可在高解析度屏幕上呈現清晰的圖像,而 WinForms 使用像素圖形,可能在高解析度屏幕上顯示模糊或失真。

WPF : 高級API

​ 如果 WPF 僅通過DireclX 提供硬體加速功能,那麼它只能算是一項重要改進,而不是革命性的變化。實際上,WPF 包含了一整套面嚮應用程式編程人員的高級服務。

​ 下麵列出 WPF 引入到Windows編程領域中的一些最重要變化。

類似 Web的佈局模型

與通過特定的坐標將控制項固定在具體位置不同,WPF 十分註重靈活的流式佈局,根據控制項的內容靈活地排列控制項,從而使用戶界面能適應變化幅度大的內容以及不同的語言。

豐富的繪圖模型

與逐像素進行繪製不同,在WPF 中可直接處理圖元—基本形狀、文本塊以及其他圖形元素。也可使用其他新特性,如真正的透明控制項、放置多層並具有不同透明度內容的功能以及本地3D 支持。

豐富的文本模型

WPF 為Windows 應用程式提供了在用戶界面的任何位置顯示豐富的樣式化文本的功能。甚至可將文本和列表、浮動的圖形以及其他用戶界面元素結合起來。並且如果需要顯示大量文本,還可使用高級的文檔顯示特性,例如換行、分列和對齊,以提高可讀性

作為首要編程概念的動畫

在WPF 中,不必再用計時器來強制窗體重繪自身。與此相反,動畫成為 WPF框架的固有部分。在WPF 中可使用聲明式標簽定義動畫,WPF 會自動讓它們運動起來。

支持音頻和視頻媒體

以前的用戶界面開發工具包(如 Windows 窗體)對多媒體的處理有很大的限制。但WPF 支持播放任何Windows 媒體播放器所支持的音頻和視頻文件,並允許同時播放多個媒體文件。更引人註目的是,WPF 提供了允許在用戶界面的其他部分集成視頻內容的工具,還允許添加特效技巧,比如在一個旋轉的3D 立方體上放置視頻視窗。

樣式和模板

通過樣式可實現顯示格式的標準化,並可在整個應用程式中反覆使用。
通過模板可改變元素的渲染方式,甚至改變核心控制項(如按鈕)的渲染方式。在創建現代的具有皮膚的用戶界面時,從來都不像現在這樣方便。

命令

大多數用戶已認識到,通過菜單或工具欄觸發 Open 命令並沒什麼區別,最終結果是相同的。現在通過代碼抽象,可在特定位置定義應用程式命令並將其鏈接到多個控制項上。

聲明式用戶界面

儘管可編寫代碼來創建 WPF 視窗,但Visual Studio 提供了另一種方式。它將每個視窗的內容串列化到XAML 文檔中的一組 XML. 標簽中。其優點是用戶界面和代碼完全分離,並且圖形設計人員可使用專業工具編輯 XANL 文件,並最終潤色應用程式的前端界面。XAML 是 Extensible Application Markup Language(可擴展應用程式標記語言)的縮寫,第2章將詳細介紹 XAMIL的相關內容。

基於頁面的應用程式

可使用WPF創建類似於瀏覽器的應用程式,此類應用程式可通過“前進”和“後退”導航技鈕在一組頁面中移動。由WPF 來處理那些紛繁的細節,如頁面歷史。甚至可將項目部署為運行於 正 中的基於瀏覽器的應用程式。

解析度無關性

​ 傳統的 Windows 應用程式都會受特定的假定屏幕解析度的限制。在設計視窗時,開發人員通常假定標準的顯示器解析度(如1366×768 像素),並針對更小或更大的解析度儘量保證視窗能夠合理地改變尺寸。

​ 問題是傳統 Windows 應用程式的用戶界面是不可伸縮的。因此,如果使用更高的顯示器解析度,將會更緊密地排列像素,應用程式視窗將變得更小並更難以閱讀。特別是對於使用像素排列更加緊密的新式顯示器,當以較高解析度運行時,問題更趨嚴重。例如,通常可發現用戶使用的束些顯示器(特別是攜帶型電腦的顯示器)的像素排列密度是 120 dpi(dot per inch,每英寸像素點數)或144 dpi,超過更帶見的96 dpi. 當這些顯示器使用它們預設的解析度時,像素會以更緊密的方式顯示,使控制項和文本變得更小。

​ 理權情況下,應用程式應使用更高的像素密度顯示更多細節。例如,高解析度顯示器可顯示相同大小的工具欄圖標,但使用更多像素顯示更清晰的圖形。這樣可保持相同的基本佈局,但增加了清晰度和細節。出於多種原因,這種解決方法在過去是無法實現的。儘管可改變用CDIGDi+繪製的圖形內容的大小,User32(負責為通用控制項生成可視化外觀)不支持真正的縮放。

​ 這個問題在 WPF 中不復存在,因為 WPF 自行渲染所有用戶界面元素,從簡單的形狀到通用控制項(如技鈕)。所以,如果在電腦顯示器上創建一個1英寸寬的技鈕,在更高解析度的顯示器上它仍能保持1英寸的寬度—WPF 只是使用更多像素更詳細地渲染這個按鈕罷了。

​ 這裡做了總體性描述,並通過幾個細節進行瞭解釋。最重要的是要認識到 WPE根據系統DPI 設置進行縮放,並不根據物理顯示設備的DPI 進行縮放。這是十分合理的——畢竟在100英寸的投影儀上顯示應用程式,您可能會站在投影儀後面幾步遠的地方,並希望看到特大版本的視窗。不希望 WPF驟然間將應用程式縮至“正常”大小。同樣,如果使用具有更高解析度顯示器的攜帶型電腦,您可能希望視窗稍小些—這是在更小屏幕上顯示信息必須付出的代價。更進一步講,不同用戶有不同的偏好。有些用戶可能希望顯示更豐富的細節,而另一些用戶可能希望顯示更多內容。

​ 那麼 WPF 如何確定應用程式視窗的大小呢?簡單來講,就是當WPF 計算視窗尺寸時使用系統DPI 設置。但要想理解底層工作原理,進一步探討 WPF度量系統是很有幫助的。

WPF 單位

​ WPF視窗以及其中的所有元素都使用與設備無關的單位進行度量。一個與設備無關的單位被定義為1/96英寸。為了理解其實際含義,下麵將分析一個例子。

​ 設想用WPF創建一個尺寸為96X96單位的小按鈕。如果使用標準的 Windows DPT 設置(96 dp),每個設備無關單位實際上對應一個物理像素。因為對於這種情況,WPF用以下公式進行計算:

​ 物理單位尺寸]=[設備無關單位尺寸]×[系統DP]

​ =1/96英寸X96 dpi
=1像素

​ 本質上,WPF假定使用96個像素構成1英寸,因為這是 Windows 操作系統通過系統 DPI設置告訴 WPF的。但實際上依賴於顯示設備。

系統DPI

​ 到目前為止,WPF 按鈕示例和其他類型 Windows 應用程式中的其他任意用戶界面元素完全相同。如果改變系統 DPI 設置,結果就不同了。在上一代 Windows 中,該特性有時稱為大字體。因為那時系統 DPI 會影響系統字體的大小,但其他細節通常不變。

註意:

許多 Windows 應用程式不完全支持更高的 DPI設置。在最糟糕的情形下,增加系統 DPI可能會使視窗中的一些內容被縮放,但其他內容則未被縮放,這可能導致有些內容被隱藏起來,甚至視窗無法使用。

​ 這正是 WPF的不同之處。WPF 本身就可以十分輕鬆地支持系統 DPI 設置。例如,將系統
DPI 設置改為120dpi(高解析度顯示器的用戶常選擇這麼做),WPF假定需要120個像素來填滿
1英寸的空間。WPF使用以下公式計算如何將邏輯單位變換為物理設備像素:

[物理單位尺寸]=[設備無關單位尺寸]×[系統DPI]

​ =1/96英寸X120dpi
=1.25像素

​ 換句話說,將系統 DPI設為120dpi 時,WPF渲染引擎假定設備無關單位等於1.25個像素。
如果顯示96×96像素大小的按鈕,那麼物理尺寸實際為120×120像素(因為96×1.25=120)。
這正是你所期望的結果—在標準顯示器上大小為1英寸的按鈕,在像素密度更高的顯示器上仍保持1英寸的大小。

​ 如果只用於按鈕,這種自動縮放的意義不大。但 WPF 對它所顯示的任何內容都使用設備無關單位,包括形狀、控制項、文本以及其他放在視窗中的內容。所以可將系統 DPI 改為任何所希望的數值,WPF將無縫地調整應用程式的尺寸。

註意:

根據系統 DPI 計算出的像素尺寸可能是小教。可假定 WPF 簡單地將度量尺寸會入為最接近的像素。然而,預設情況下,WPF的處理方式與此不同。如果元素的一條邊落在兩個像素之間,WPF 將使用反鋸齒特性將這條邊混合到相鄰的像素。這看起來可能是多餘的選擇,但的確可改進視覺效果。如果給控制項增加皮膚效果而使用自定義繪製圖形,那麼就未必會整齊、清晰地定義邊緣,從而需要進行一定程度的反鋸齒處理。

點陣圖和矢量圖形

​ 當使用普通控制項時,自然可利用 WTPF的解析度無關性。WPF 會負責確保任何顯示內容都能自動地具有正確的尺寸。但是,如果準備在應用程式中包含圖像,偶爾可能出現問題。例如,在傳統 Windows 應用程式中,開發人員為工具欄命令按鈕使用非常小的點陣圖,但在WPF 應用程式中這並非一種理想方法,因為當根據系統 DPI 進行放大或縮小時,點陣圖可能出現偽影(變得模糊)。反而,當設計 WPF用戶界面時,即使是最小的圖標,通常也使用矢量圖形來實現。矢量圖形被定義為一系列的形狀,並且它們能夠很容易地縮放為任何尺寸。

註意:

當然,相對於繪製一幅基本的點陣圖,繪製矢量圖形需要耗費更長的時間,但 WPF 包含可減少開銷的優化措施,以確保性能始終處於合理範圍之內。

​ 解析度無關性的重要性無論如何強調都不過分。因為乍一看,對於這個由來已久的問題(該問題確實如此),它看起來像是簡單的、優美的解決方法。但為了設計完全可縮放的用戶界面,開發人員需要接受一種新的思想。

WPF 體繫結構

​ WPF使用多層體繫結構。在頂層,應用程式與完全由托管 C*代碼編寫的一組高層限務進行交互。至於將.NET 對象轉換為 Direct3D 紋理和三角形的實際工作,是在後臺由一個名為milcore.dll的低級非托管組件完成的。milcore.dill 是使用非托管代碼實現的,因為它寓要和Direct3D緊密集成,並且它對性能極其敏感。

​ 下圖顯示了WPF 應用程式中的各層工作情況:

以下列出上圖中包含的一些重要組件:

PresentationFramework.dll

包含 WPF頂層的類型,包括那些表示視窗、面板以及其他類型控制項的類型。它還實現了高層編程抽象,如樣式。開發人員直接使用的大部分類都來自這個程式集。
PresentationCore.dll

包含了基礎類型,如UIElement類和Visual類,所有形狀類和控制項類都繼承自這兩個類。如果不需要視窗和控制項抽象層的全部特征,可使用這一層,而且仍能利用 WPF 的渲染引擎。
WindowsBase.dll

包含了更多基本要素,這些要素具有在 WPF之外重用的潛能,如DispatcherObject 類和 DependencyObject類,這兩個類引入了依賴項屬性(詳見第4 章)。
milcore.dll

是 WPF這染系統的核心,也是媒體集成層(Media Integration Layer,MIL)的基礎。其合成引擎將可視化元素轉換為 Direct3D 所期望的三角形和紋理。儘管將milcore.dll 視為WPF 的一部分,但它也是 Windows Vista 和 Windows 7的核心系統組件之一。實際上,桌面視窗管理器(Desktop Window Manager,DWM)使用 milcore.dll渲染桌面。
WindowsCodecs.dll

是一套提供圖像支持的低級 API(例如處理、顯示以及縮放點陣圖和JPEG 圖像)。
• Direct3D

是一套低級 API, WPF 應用程式中的所有圖形都由它進行渲染。
• User32

用於決定哪些程式實際占有桌面的哪一部分。所以它仍被包含在 WPF 中,但不再負責渲染通用控制項。

類層次結構

下圖簡要顯示了類層次結構中的幾個重要分支。

下麵將簡要介紹上圖中呈現的核心類,這些類中的許多類構成了完整的元素分支(如形狀、面板及控制項)。

註意:

WPF核心名稱空間以 System.Windows 開頭(如 System.Windows、System.Windows.Controls以及 System.Windows.Media). 唯一例外是由 System.Windows.Forms 開頭的名稱空間,它們是Windows 窗體工具包的一部分。

1.System,Thieading.DispatcherObjeat類
WPF 應用程式使用為人熱知的單線程親和(Single-ThreadAmipity,STA)模理,這意味著整個用戶界面由單個線程擁有。從另一個線程與用戶界面元素進行交互是不安全的。為方便使用此模型,每個WPF應用程式由協調消息(鍵盤輸入、滑鼠移動乃至框架處理,如佈局)的調度程式管理。通過繼承自 DispatcherOljoot 類,用戶界面中的每個元素部可以檢查代碼是否在正確的線程上運行,並能通過訪間調度程式為用戶界麵線程封送代碼。

2.System.Windows.DependencyObject 類
在 WPF 中,主要通過屬性與原幕上的元素進行交互。在早期設計階段,WPF的設計者決定創建一個更加強大的屬性模型,該模型文持許多特性,例如更改通知、歌認值繼承以及被少翼桂存餚空間。最終結果就是依驗項屬性(dependency properp)特性,第4章將分析該種性。
通過繼承自 DependencyObject類,WPF類可獲得對依賴項屬性的支持。

3.System.Windows.Media.Visual 類
在 WPF 視窗中顯示的每個元素本質上都是 Visual 對象。可將 Visual 炎視為繪圖對象,其中封裝了繪圖指令、如何執行繪圖的附加細節(如剪裁、透明度以及變換設置)以及基本功能(如命中測試)。Visual類還在托管的 WPF 庫和誼染桌面的 milcore.dll程式集之間提供了鏈接。任何繼承自 Visual 的類都能在視窗上顯示出來。如果更願意使用輕量級的 API 創建用戶界面,而不想使用WPF 的高級框架特征。

  1. System.Windows.UlElement 類
    UIElement 類增加了對WPF 本質特征的支持,如佈局、輸入、焦點和事件(WPF 團隊使用首字母縮寫詞 LIFE 來表示)。例如,這裡定義兩個步驟的測量和排列佈局過程,這些內容將在第18章中介紹。在該類中,原始的滑鼠單擊和按鍵操作被轉換為更有用的事件,如MouseEnter事件。與屬性類似,WPF 實現了增強的稱為路由事件(routed event)的事件路由系統。

5.System. Windows.FrameworkElement 類
FrameworkElement類是 WPF核心繼承樹中的最後一站。該類實現了一些全部由 UIElement類定義的成員。例如,UIElement 類為 WPF 佈局系統設置了基礎,但 FrameworkElement類提供了支持它的重要屬性(如 HorizontalAlignment 和 Margin 屬性)。UIElement類還添加了對數量綁定、動畫以及樣式等核心特性的支持。

6.System.Windows.Shapes.Shape 類
基本的形狀類(如Rectangle 類、Polygon 類、Ellipse 類、Line類以及 Path 類)都繼承自該類。
可將這些形狀類與更傳統的 Windows 小組件(如按鈕和文本櫃)結合使用。

  1. System.Windows.Controls.Control 類

控制項(control)是可與用戶進行交互的元案。控制項顯然包括 TextBox 類、Button 類和 ListBox類等。Contol 類為設置字體以及前景色與背景色提供了附加屬性。但最令人感興趣的細節是模板支持,通過模板支持,可使用自定義風格的繪圖替換控制項的標準外觀。第17 章將介紹控制項模板。

註意:

在 Windows 窗體編程中,窗體中的每個可視化項都稱為控制項,在 WPF中,情況不再如此。
可視化內容被稱為元素(clerent),只有部分元素是控制項(控制項是那些能夠接收焦點並能與用戶進行交互的元素)。更令人費解之處在於,許多元素是在 System.Windows.Controls 名稱空間中定義的,但它們不是繼承自 System.Windows.Controls.Contol 類,並且不被認為是控制項。Panel類便是其中一例

8.System.Windows.Controls.ContentControl 類
ContentControl 類是所有具有單一內容的控制項的基類,包括簡單的標簽乃至視窗的所有內容。該模型給人印象最深刻的部分是:控制項中的單一內容可以是普通字元串乃至具有其他形狀和控制項組合的佈局面板。

9.System.Windows.Controls.ItemsControl 類
ItemsControl 類是所有顯示選項集合的控制項的基類,如 ListBox 和 TreeView 控制項。列表控制項十分靈活—例如,使用ItemsControl類的內置特征,可將簡單的 ListBox 控制項變換成單選按鈕列表、覆選框控制項列表、平鋪的圖像或是您所選擇的完全不同的元素的組合。實際上,WPF中的菜單、工具欄以及狀態欄都是特定的列表,並且實現它們的類都繼承自 ItemsContorl 類。
10.System.Windows.Controls.Panel 類
Panel 類是所有佈局容器的基類,佈局容器是可包含一個或多個子元素、並按特定規則對子元素進行排列的元素。這些容器是 WPF 佈局系統的基礎,要以最富有吸引力、最靈活的方式安排內容,使用這些容器是關鍵所在。

WPF 4.5

WPF是一種成熟的技術。它是幾個已經發佈的.NET 平臺的一部分,並通過以下兩個版本不斷的進行完善:

•WPF 3.0。這是 WPF 的第一個版本,它與另兩種新技術一併發佈:WCF(WindowsCommunication Foundation)和Windows WF(Workflow Foundation)。這三種新技術合稱為 .NET Framewordk 3.0 。

• WPF 3.5.一年後,一個新的 WPF 版本作為.NET Framework 3.5 的一部分發佈。新版本WPF 的新特性主要是一些小的改進,包括錯誤修複和性能改進。
• WPF 3.5 SP1. 當發佈.NET Framework Service Pack 1(SP1)時,WPF 設計人員抓住這個機會增添了一些新功能,例如平滑圖形效果(通過像素著色器實現)以及高級的 DataGrid控制項。
•WPF4。該WPF版本做了大量改進,包括更好地渲染文本、動畫更自然流暢以及支持多點觸控。
• WPF4.5.相對於上述版本更新,迄今為止,這一最新 WPF版本對 WPE 4所做的更新是最少的,這也表明WPF技術已經走向成熟。除糾正一些一般性錯誤並對性能做了調整外,WPF 4.5 還對數據綁定系統做了大量完善工作,比如完善了數據綁定表達式、可視化,並可以支持 INotifyDataBror 介面以及數據視圖同步。

第一個WPF程式

1.新建項目

2.編寫代碼

3.運行程式

本章小結

本章簡要介紹了WPF及其作用,分析了 WPF 的底層體繫結構,並簡要介紹了核心類。
顯然,WPF 引入了許多重要變化。然而,有5條重要的準則更加突出,因為它們和以前的Windows 用戶界面工具包(如Windows 窗體)的區別很大。這些準則如下:

硬體加速:

​ 通過 DirectX 執行所有WPF 繪圖操作,以便充分利用現代顯卡的最新功能。

解析度無關性:

​ WPF能夠根據系統 DPI 設置,非常靈活地放大和縮小顯示的內容,以使其適合所用的顯示器和顯示選擇。

控制項無固定外觀:

​ 在傳統的Windows 開發中,在定製的符合需求的控制項(此類控制項是指自繪製的控制項)和由操作系統渲染的本質上外觀固定的控制項之間存在很大的差別。在WPF 中,從基本的Rectangle 形狀到標準的 Button控制項或更複雜的 Toolbar控制項,都是使用相同的渲染引擎繪製的,並且都是完全可定製的。因此,WPF 控制項經常被稱為無外觀控制項——它們為控制項定義了功能,但沒有固定“外觀”。

聲明式用戶界面:

​ 第2章將介紹 XAML,XAML 是用於定義 WPF 用戶界面的標記標準。通過 XANL,不必編寫代碼即可創建視窗。特別是 XAML 的能力不局限於創建一成不變的用戶界面。可以使用許多工具,如數據綁定和觸發器等自動運行基本的用戶界面行為(例如,當頁面通過記錄源時文本框更新自身,當滑鼠移動到標簽上時標簽變亮),所有這些都不需要編寫 C#代碼。

基於對象的繪圖:

​ 即使準備在更低級的可視化層(而非高級元素層)上工作,也不需要使用繪圖和像素進行工作,而是創建圖形對象並讓WPF 儘可能最優化地顯示出來。

課後作業


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 編程編的久了,總會遇到多線程的情況,有些時候我們要幾個線程合作完成某些功能,這時候可以定義一個全局對象,各個線程根據這個對象的狀態來協同工作,這就是基本的線程同步。 支持多線程編程的語言一般都內置了一些類型和方法用於創建上述所說的全局對象也就是鎖對象,它們的作用類似,使用場景有所不同。.Net中這玩 ...
  • 我們.NET開發會引用很多外部Nuget包,多項目、多個解決方案、甚至多個倉庫。 簡單的Nuget包管理,通過VS就能比較簡單處理好。但複雜的場景呢,比如: 1.一個倉庫里,有多個解決方案的Nuget包管理 -- 我現在項目就是這樣的,針對會議大屏的全家桶軟體集代碼倉庫。這個倉庫里,接近30個工具/ ...
  • 在編寫上位機軟體時,需要經常處理命令拼接與其他設備進行通信,通常對不同的命令封裝成不同的方法,擴展稍許麻煩。 本次擬以特性方式實現,以兼顧維護性與擴展性。 思想: 一種命令對應一個類,其類中的各個屬性對應各個命令段,通過特性的方式,實現其在這包數據命令中的位置、大端或小端及其轉換為對應的目標類型; ...
  • 先看一下效果吧: isChecked = false 的時候的效果 isChecked = true 的時候的效果 然後我們來實現一下這個效果吧 第一步:創建一個空的wpf項目; 第二步:在項目裡面添加一個checkbox <Grid> <CheckBox HorizontalAlignment=" ...
  • 目錄Blazor 組件基礎路由導航參數組件參數路由參數生命周期事件狀態更改組件事件 Blazor 組件 基礎 新建一個項目命名為 MyComponents ,項目模板的交互類型選 Auto ,其它保持預設選項: 客戶端組件 (Auto/WebAssembly): 最終解決方案裡面會有兩個項目:伺服器 ...
  • 前言 在平時項目開發中,定時任務調度是一項重要的功能,廣泛應用於後臺作業、計劃任務和自動化腳本等模塊。 FreeScheduler 是一款輕量級且功能強大的定時任務調度庫,它支持臨時的延時任務和重覆迴圈任務(可持久化),能夠按秒、每天/每周/每月固定時間或自定義間隔執行(CRON 表達式)。 此外 ...
  • 第3章:佈局 本章目標 理解佈局的原則 理解佈局的過程 理解佈局的容器 掌握各類佈局容器的運用 理解 WPF 中的佈局 WPF 佈局原則 ​ WPF 視窗只能包含單個元素。為在WPF 視窗中放置多個元素並創建更貼近實用的用戶男面,需要在視窗上放置一個容器,然後在這個容器中添加其他元素。造成這一限制的 ...
  • 在日常開發中,並不是所有的功能都是用戶可見的,還在一些背後默默支持的程式,這些程式通常以服務的形式出現,統稱為輔助角色服務。今天以一個簡單的小例子,簡述基於.NET開發輔助角色服務的相關內容,僅供學習分享使用,如有不足之處,還請指正。 ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發(一):使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說,近來想嘗試開發一款安卓APP,考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP,畢竟是使用Visual Studio開發工具,使用起來也比較的順手,結合微軟官方的教程進行了安卓 ...
  • 前言 QuestPDF 是一個開源 .NET 庫,用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫,它徹底改變了我們生成 PDF 文檔的方 ...
  • 項目地址 項目後端地址: https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址: ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址: http://tree ...
  • 話不多說,直接開乾 一.下載 1.官方鏈接下載: https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe,運行開始下載SQL server; 二. ...
  • 前言 隨著物聯網(IoT)技術的迅猛發展,MQTT(消息隊列遙測傳輸)協議憑藉其輕量級和高效性,已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫,為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog支持多種接收器用於日誌存儲,增強器用於添加屬性,LogContext管理動態屬性,支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項,適用於不同需求。 ...
  • 目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據,爬取信息時需要模擬瀏覽器行為,否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下: 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • 1.前言 什麼是熱更新 游戲或者軟體更新時,無需重新下載客戶端進行安裝,而是在應用程式啟動的情況下,在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR,Xlua,ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles,Addressable, ...
  • 本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺,其實像阿裡雲,騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後,它會送 ...
  • 通過以下方式可以高效,並保證數據同步的可靠性 1.API設計 使用RESTful設計,確保API端點明確,並使用適當的HTTP方法(如POST用於創建,PUT用於更新)。 設計清晰的請求和響應模型,以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證,確保接收到的數據符合預期格 ...