《Programming WPF》翻译 第3章 2.处理输入
在Windows應用程序中，又3種基本的用戶輸入形式：鼠標、鍵盤和手寫板。同時，還有一種更高級輸入方式，其可能來自快捷鍵、工具欄的按鈕、菜單項。
盡管控件擔當著主要的輸入對象，用戶界面的所有元素都可以接受輸入。不必吃驚，這是因為，為了提供外觀，控件完全依賴于底層元素的服務，如Rectangle和TextBlock。因此，在用戶界面內的元素類型中，所有的輸入機制都是有用的，我們將要在接下來的章節介紹這些機制。
3.2.1 Routed事件
.Net框架定義了一個標準的機制來暴露事件。一個類可能暴露了一些事件，每個事件可能有任意數量的訂閱者。雖然WPF也使用了這一標準機制，聲稱其克服了一個局限：如果一個正常.NET事件沒有注冊句柄，該事件將被視為無效并忽略。
考慮一下這對于一個典型的WPF控件意味著什么。大多數控件是由多個可視化組件組成的。例如，即使你為一個按鈕添加了一個非常簡單的可視化樹，這棵樹包括一個單獨的矩形框，以及一條簡單的文本，目前有兩個元素：文本和矩形框。不管光標是否在文本或矩形框上，這個按鈕都要響應鼠標點擊事件。在標準.NET事件處理模型中，這意味著要為所有元素注冊MouseLeftButtonUp事件。
更嚴重的是使用WPF內容模型。一個按鈕并不局限于只有簡單文本作為標題，它可以包含任意標簽。示例3-2是一個相當普通的情況，但即使如此，其中仍然有6個元素：黃色的邊框，代表眼睛的兩個點，代表嘴的曲線，文本，以及作為背景的按鈕本身。為每一個單獨元素關聯事件句柄關聯，是煩冗而且效率低下的。幸運的是，這些并不是必需的。
圖3-2
WPF使用routed事件，該事件比其他普通事件更為直接。原先的機制是，將委托句柄關聯到激發該事件的元素，調用該句柄。如今，一個rounted事件會調用所有的關聯到已知代碼的句柄，從初始元素向上直到用戶界面書的根元素。
??????示例3-1顯示了圖3-2中按鈕的標記。如果Canvas中的一個Elliipse元素接收到輸入，事件路由可以支持Button、Grid、Canvas和Ellispse接收事件，如圖3-3所示。
示例3-1
<Button?MouseLeftButtonDown="MouseButtonDownButton"
????????PreviewMouseLeftButtonDown="PreviewMouseButtonDownButton">
????<Grid?MouseLeftButtonDown="MouseButtonDownGrid"
????????????PreviewMouseLeftButtonDown="PreviewMouseButtonDownGrid">
????????<Grid.ColumnDefinitions>
????????????<ColumnDefinition?/>
????????????<ColumnDefinition?/>
????????</Grid.ColumnDefinitions>
????????<Canvas?MouseLeftButtonDown="MouseButtonDownCanvas"
????????????????PreviewMouseLeftButtonDown="PreviewMouseButtonDownCanvas"
????????????????Width="20"?Height="18"?VerticalAlignment="Center">
????????????<Ellipse?MouseLeftButtonDown="MouseButtonDownEllipse"
????????????????????????PreviewMouseLeftButtonDown="PreviewMouseButtonDownEllipse"
????????????????????????Canvas.Left="1"?Canvas.Top="1"?Width="16"?Height="16"
????????????????????????Fill="Yellow"?Stroke="Black"?/>
????????????<Ellipse?Canvas.Left="4.5"?Canvas.Top="5"?Width="2.5"?Height="3"
????????????????????????Fill="Black"?/>
????????????<Ellipse?Canvas.Left="11"?Canvas.Top="5"?Width="2.5"?Height="3"
????????????????????????Fill="Black"?/>
????????????<Path?Data="M?5,10?A?3,3?0?0?0?13,10"?Stroke="Black"?/>
????????</Canvas>
????????<TextBlock?Grid.Column="1">Foo</TextBlock>
????</Grid>
</Button>
一個路由事件可以是bubbling，tunneling或Direct的。Bubbling事件以尋找附屬到激發事件的事件句柄開始，接著尋找它的父級別，再接著是它的父級別的父級別，依次類推，直到達到這棵樹的根，這個順序是由圖3-3的數字表明的。Tunneling事件以相反的方式工作。它先在樹根尋找句柄，接著向下開始工作，以原始的元素作為結束。
??????Direct事件的路由方式與傳統的.NET事件處理相同，只有直接附屬到原始元素的句柄會被通知到。這典型地用于僅在它們的原始元素的上下文中有意義的那些事件。例如，如果鼠標的進入和移開是bubbled或tunneled的，這將是無用的。父級元素未必會關心何時鼠標從一個元素移動到另一個元素。在父一級元素，你可能希望“鼠標移開”意味著“鼠標已經離開了父一級元素”，因為使用了Direct事件路由，這才是它正確地意味著什么。一旦使用bubbiling，事件將有效的意味著“鼠標已經離開了這個元素，可能在或不在其父一級內的另一個元素中”。
??? 除direct事件之外，WPF還定義了很多成對（bubbling和tunneling）的路由事件。Tunneling事件的名稱通常以Preview開始，而且會首先被激發。這將給原始元素的父級一個看一下事件的機會，在到達其子級別之前（因此以“Preview”為前綴。）tunneling的Preview事件直接遵循bubbling事件。在大多數情形中，你將要處理bubbling事件，preview事件只用于你想要阻塞一個事件時，或者你想要父一級在正常處理事件時預先做一些事情。
??? 在示例3-1中，大多數元素擁有事件句柄，由MouseLeftButtonDown和PreviewMouseLeftButtonDown事件指定相應的bubbling和tunneling事件。示例3-2顯示了相應的后臺代碼文件。
示例3-2
using?System;
using?System.Windows;
using?System.Diagnostics;
namespace?EventRouting?{
????public?partial?class?Window1?:?Window?{
????????public?Window1(??)?{
????????????InitializeComponent(??);
????????}
????????private?void?MouseButtonDownButton(object?sender,?RoutedEventArgs?e)
????????{?Debug.WriteLine("MouseButtonDownButton");?}
????????private?void?PreviewMouseButtonDownButton(object?sender,?RoutedEventArgs?e)
????????{?Debug.WriteLine("PreviewMouseButtonDownButton");?}
????????private?void?MouseButtonDownGrid(object?sender,?RoutedEventArgs?e)
????????{?Debug.WriteLine("MouseButtonDownGrid");?}
????????private?void?PreviewMouseButtonDownGrid(object?sender,?RoutedEventArgs?e)
????????{?Debug.WriteLine("PreviewMouseButtonDownGrid");?}
????????private?void?MouseButtonDownCanvas(object?sender,?RoutedEventArgs?e)
????????{?Debug.WriteLine("MouseButtonDownCanvas");?}
????????private?void?PreviewMouseButtonDownCanvas(object?sender,?RoutedEventArgs?e)
????????{?Debug.WriteLine("PreviewMouseButtonDownCanvas");?}
????????private?void?MouseButtonDownEllipse(object?sender,?RoutedEventArgs?e)
????????{?Debug.WriteLine("MouseButtonDownEllipse");?}
????????private?void?PreviewMouseButtonDownTextBlock(object?sender,
?????????????????????????????????????????????????????RoutedEventArgs?e)
????????{?Debug.WriteLine("PreviewMouseButtonDownEllipse");?}
????}
}
?
?????每一個句柄輸出了一條debug信息。這里時我們獲得的debug輸出，當點擊Canvas中的TextBlock時。
PreviewButtonDownButton
PreviewButtonDownGrid
PreviewButtonDownCanvas
PreviewButtonDownEllipse
ButtonDownEllipse
ButtonDownCanvas
ButtonDownGrid
ButtonDownButton
輸出結果證實了Preview事件是最先被激發的。還顯示了它是從Button元素開始向下工作，正如我們對tunneling事件希望的那樣。bubbling事件則從Ellispse開始向上工作。
Bubbling路由事件提供了很多事件，意味著你可以注冊一個單獨的事件處理在一個控件上，而且它將為內嵌在控件中的任何元素接收事件。你不需要任何特殊的處理以解決內嵌內容或自定義可視化內容，事件簡單的向上冒泡，并且在那里可以全部被處理。
3.2.1.1中止事件處理
有很多情形你可能不想讓事件冒泡。例如，你可能希望轉換事件為別的什么東西，Button元素有效的轉換了MouseLeftButtonDown和MouseLeftButtonUp事件為Click事件。它抑止了底層事件，從而只有Click事件冒泡到控件之外。
任何句柄都能防止進一步的處理路由事件——通過設置RoutedEvebtArgs的Handled屬性，如示例3-4所示。
示例3-3
private?void?ButtonDownCanvas(object?sender,?RoutedEventArgs?e)?{
????Debug.WriteLine("ButtonDownCanvas");
????e.Handled?=?true;
}
另一個設置Handled標志的原因是，如果你想要防止正常的事件處理。一旦你在Preview句柄中這么做，不僅tunneling的Preview事件會停止，本應正常執行的bubbling事件也不會被激活，因此看起來似乎事件沒有發生。
3.2.1.2確定目標
雖然在一個單獨的地方，能夠處理來自一組元素的事件，這是非常便利的，你的句柄可能需要知道是哪個元素引起激活一個事件，你可能想這正是句柄中sender參數的意圖。事實上，sender一直將對象歸諸于你附加到的事件句柄上。在使用bubbling和tunneling事件的情形中，這并不總是引起事件被激活的元素。在示例3-1中，ButtonDownWindow句柄的sneder是Window本身。
幸運的是，找到潛在的導致事件發生的元素，這是容易的。RouteEventArgs對象作為第二個參數傳遞，提供了一個OriginalSource屬性。
3.2.1.3路由事件和正常的事件
正常的.NET事件（或者說，他們曾經稱為CLR事件），提供了一個優勢——相對于路由事件語法：很多.NET語言對處理CLR事件提供內嵌的支持。這就提供了最好的兩種世界：你可以使用你喜歡的語言的事件處理語法，而不是利用額外的由路由事件提供的功能。
多虧了CLR事件機制的彈性設計。雖然這里有一種標準的聯合了CLR事件的簡單行為，CLR的設計者有遠見的意識到，一些應用程序需要更多的高級行為。這些類因此可以自由的實現它們喜歡的事件。WPF獲益于這種有CLR事件定義的設計——這些事件內在的作為路由事件來實現。
示例3-1和示例3-2安排了事件句柄的連接，通過使用標記中的屬性。但是我們可能已經替代地使用了正常的C#事件句柄語法來關聯構造函數中的句柄。例如，我們要在示例3-1中移除MouseLeftButtonDown和PreviewMouseLeftButtonDown屬性，接著修改示例3-2的構造函數，如下面的示例3-4。
示例3-4
public?Window1(??)?{
????InitializeComponent(??);
????this.MouseLeftButtonDown?+=?MouseButtonDownWindow;
????this.PreviewMouseLeftButtonDown?+=?PreviewMouseButtonDownWindow;
}
我們還能對來自內嵌元素的事件進行同樣的處理。我們不得不應用x:Name屬性為了能夠訪問C#的元素。
后臺代碼經常是最好的地方來附屬事件句柄。一旦你的用戶界面有不尋常和有創意的可視化外觀，這是一個好的時機讓xaml文件有效地被圖形設計器擁有。一個設計者不應該知道開發者需要處理哪些事件，或者調用那些句柄函數。因此，你將通常要設計者在xaml中給元素命名，同時開發者將要在后臺代碼附屬句柄。
3.2.2鼠標輸入
鼠標輸入關注于哪個元素直接位于鼠標下。所有的用戶界面元素派生于UIElement基類，這個基類定義了大量的鼠標輸入事件。這些事件列于表3-1中。
表3-1
| GotMouseCapture | Bubble | Element captured the mouse. |
| LostMouseCapture | Bubble | Element lost mouse capture. |
| MouseEnter | Direct | Mouse pointer moved into element. |
| MouseLeave | Direct | Mouse pointer moved out of element. |
| PreviewMouseLeftButtonDown, MouseLeftButtonDown | Tunnel, Bubble | Left mouse button pressed while cursor inside element. |
| PreviewMouseLeftButtonUp, MouseLeftButtonUp | Tunnel, Bubble | Left mouse button released while cursor inside element. |
| PreviewMouseRightButtonDown, MouseRightButtonDown | Tunnel, Bubble | Right mouse button pressed while cursor inside element. |
| PreviewMouseRightButtonUp, MouseRightButtonUp | Tunnel, Bubble | Right mouse button released while cursor inside element. |
| PreviewMouseMove, MouseMove | Tunnel, Bubble | Mouse cursor moved while cursor inside element. |
| PreviewMouseWheel, MouseWheel | Tunnel, Bubble | Mouse wheel moved while cursor inside element. |
| QueryCursor | Bubble | Mouse cursor shape to be determined while cursor inside element. |
UIElement還定義了一對屬性，表示鼠標當前是否在元素上：ISMouseOver和ISDirectMouseOver。這兩個屬性的區別在于，當鼠標在正被討論的元素上或任何它的子元素上時，前者為true；而后者僅當鼠標在正被討論的元素上的時候才為true，不包括它的子元素這種情況。
注意到，上表中基本的鼠標事件設置不包括Click事件。這是因為Click一個高級別的概念——相對于基本的輸入。一個按鈕可以被點擊——通過鼠標或鍵盤。此外，Click并不是必要的直接符合一個單獨的鼠標事件。通常的，用戶不得不點擊或按下或釋放鼠標，當鼠標在鼠標之上以注冊一個Click事件時。相應地，這些高級別的事件由更明確的元素類型提供。Control類添加了一對事件：MouseDoubleClick和PreviewMouseDoubleClick。ButtonBase——Button的基類，CheckBox，RadioButton，都有添加這個Click事件。
如果你使用了一個Fill屬性為透明的Shape，這個Shape將擔當輸入的目標，一旦鼠標在Shape之上。這回有一點令人驚訝，如果你使用了一個完全透明的筆刷。這個Shape將是不可見的，但是仍然作為輸入的目標，不管鼠標在其上看來可能是什么樣的。如果你想要一個填充為透明的Shape，而且不捕獲鼠標輸入，簡單的根本不提供Fill屬性，如果Fill屬性為null值（而不是一個完全的透明筆刷），，這個Shape將不會擔當輸入的模板。
記住，如果你考慮處理一個鼠標事件的原因是，簡單的為用戶提供某些可見的反饋，寫一個事件句柄可能過度了。這通常是可能的，通過聲明性的屬性觸發器和事件觸發器，可以在樣式的標簽中，完全達到你需要的可視化效果。
3.2.3鍵盤輸入
鍵盤輸入引入了focus的概念。不同于鼠標，沒法為用戶移動鍵盤在一個元素上，從而指出輸入的目標。在Windows中，一個特定的元素被指定為擁有focus，意味著它會擔當鍵盤輸入的目標。用戶通過點擊鼠標或Alt+Tap 在正在討論的控件上設置focus，或者通過使用導航鍵如Tab和指針。
原則上，任何用戶元素可以獲得焦點。IsFocused屬性定義在UIElement——FrameworkElement的基類。盡管如此，Focusable屬性決定了是否支持這個特征在任意特定的元素上。默認的，這個值對于控件是true；對其他元素是false。
表3-2顯示了有用戶界面元素提供的盤輸入事件。所有的這些項使用tunnel和bubble路由，分別為Preview和主要事件。
表3-2
?
Event
Routing
Meaning
PreviewGotFocus, GotFocus
Tunnel, Bubble
Element received the focus.
PreviewLostFocus, LostFocus
Tunnel, Bubble
Element lost the focus.
PreviewKeyDown, KeyDown
Tunnel, Bubble
Key pressed.
PreviewKeyUp, KeyUp
Tunnel, Bubble
Key released.
PreviewTextInput, TextInput
Tunnel, Bubble
Element received text input.
注意到，TextInput并不是必要的鍵盤的輸入。它代表了文本的輸入在一個獨立于設備的方式，因此這個事件也能被手動輸入的結果所激活。
3.2.4手動輸入
手寫板上的鐵筆以及其他支持手動輸入的系統，有一套自己的事件。表3-3顯示了手動輸入事件——由用戶界面元素提供。
表3-3
| GotStylusCapture | Bubble | Element captured stylus. |
| LostStylusCapture | Bubble | Element lost stylus capture. |
| PreviewStylusDown, StylusDown | Tunnel, Bubble | Stylus touched screen over element. |
| PreviewStylusUp, StylusUp | Tunnel, Bubble | Stylus left screen while over element. |
| PreviewStylusEnter, StylusEnter | Tunnel, Bubble | Stylus moved into element. |
| PreviewStylusLeave, StylusLeave | Tunnel, Bubble | Stylus left element. |
| PreviewStylusInRange, StylusInRange | Tunnel, Bubble | Stylus moved close enough to screen to be detected. |
| PreviewStylusOutOfRange, StylusOutOfRange | Tunnel, Bubble | Stylus moved out of detection range. |
| PreviewStylusMove, StylusMove | Tunnel, Bubble | Stylus moved while over element. |
| PreviewStylusInAirMove, StylusInAirMove | Tunnel, Bubble | Stylus moved while over element but not in contact with screen. |
| PreviewStylusSystemGesture, StylusSystemGesture | Tunnel, Bubble | Stylus performed a gesture. |
| PreviewTextInput, TextInput | Tunnel, Bubble | Element received text input. |
3.2.5命令
很多應用程序提供了多于一種的方式來執行確定動作。例如，考慮創建一個新文件的動作。你可以選擇Fiel——New menu item，或者你可以點擊相應的工具欄按鈕。可選擇的，你可以使用快捷鍵如Ctrl+N。如果應用程序提供了一個腳本系統，這個腳本還可以提供另一種執行這個動作的方式。結果是，無論你使用什么機制，都是一樣的，因為這里有不同的方式調用同樣的底層命令。
WPF對這個想法提供了內嵌的支持。RoutedCommand類代表了一個可以在多種方式調用的邏輯動作。在典型的WPF應用程序中，每個菜單項和工具欄按鈕都聯合到一個底層的RoutedCommand對象。
RoutedCommand以一種與底層輸入表單非常相似的方式工作。當調用一個命令的時候，它激活了兩個事件：PreviewExecuteEvent和ExecuteEvent。這些事件在這棵元素樹中使用tunnel和bubble機制，和輸入事件的方式相同。命令的目標是由命令的調用方式來決定。典型地，這個目標將會是當前有焦點的任何一個元素，但是RoutedCommand還提供了一個Execute的重載方法，這會傳遞一個明確的目標元素。
你可以從很多地方獲取一個RoutedCommand。一些控件提供了命令。例如，ScrollBar控件為它的每個動作定義了命令，使之在靜態字段有效，如LineUpCommand和PageDownCommand。然而，大多數命令并不是唯一對應到特定的控件。一些符合應用程序級別的動作如”新文件”或“打開”。其他動作會在控件上被調用，但是可以被一些不同的控件實現。例如，TextBox和RichTextBox都能處理剪切操作。
這里有一組提供了標準命令的類。這些類顯示在表3-4中。這意味著你不需要創建自己的RoutedCommand對象來代表最普遍的操作。此外，很多命令被內嵌控件了解。例如TextBox和RichTextBox都支持很多標準的操作，包括clipboard，undo和redo命令。
表3-4
?
Class
Command types
ApplicationCommands
Commands common to almost all applications. Includes clipboard commands, undo and redo, and document-level operations (open, close, print, etc.).
ComponentCommands
Operations for moving through information such as scroll up and down, move to end, and text selection.
EditCommands
Text-editing commands such as bold, italic, and alignment.
MediaCommands
Media-playing operations such as transport (play, pause, etc.), volume control, and track selection.
3.2.5.1命令句柄
作為一個有用的命令，必須有事物對其進行響應。這個工作些微不同于處理正常的輸入事件，因為大多數不是由控件定義的命令將會處理它們。表3-4中的類定義了95個命令，因此如果Control為每個截然不同的命令定義了CLR事件，那將需要190個事件——一旦還要包括preview的話。這不僅會極度不廣泛，甚至還不是一個完全的解決方案。大多數應用程序在使用標準命令的同時，還定義了他們自身的自定義命令。明顯的可選擇性是為了RoutedCommand自身激活事件。然而，每個命令都是一個單件。例如，只有一個ApplicationCommand.New對象。如果你能直接添加一個句柄到命令對象，這個句柄會在任何時間運行。這個命令在你的應用程序任何地方被調用。如果你正想處理一個命令，當此命令在一個特定的窗口中執行的時候，會怎么樣呢？
CommandBinding類解決了這些問題。一個CommandBinding對象映射了一個明確的RoutedCommand到一個句柄函數上——在一個特定的用戶界面元素級別。正是這個CommandBinding會激活PreviewExecute和Execute事件，而不是UI元素。這些綁定保存在UI元素定義的CommandBinding屬性。示例3-5顯示了如何為一個窗體在后臺代碼文件中，處理ApplicationCommand.New命令。
示例3-5
public?partial?class?Window1?:?Window?{
????public?Window1(??)?{
????????InitializeComponent(??);
????????CommandBinding?cmdBindingNew?=?new?CommandBinding(ApplicationCommands.New);
????????cmdBindingNew.Execute?+=??NewCommandHandler;
????????CommandBindings.Add(cmdBindingNew);
????}
????private?void?NewCommandHandler(object?sender,?ExecuteEventArgs?e)?{
????????if?(unsavedChanges)?{
????????????MessageBoxResult?result?=?MessageBox.Show(this,
????????????????"Save?changes?to?existing?document?",?"New",
????????????????MessageBoxButton.YesNoCancel);
????????????if?(result?==?MessageBoxResult.Cancel)?{
????????????????return;
????????????}
????????????if?(result?==?MessageBoxResult.Yes)?{
????????????????SaveChanges(??);
????????????}
????????}
????????//?Reset?text?box?contents
????????inputBox.Clear(??);
????}
}
這段代碼依賴于命令路由的冒泡本質。頂級Window元素不同于成為命令目標的元素，當焦點通常屬于某個窗體中的子元素時。然而，命令會向上冒泡到頂級。這個路由對命令的處理只放在一個地方，從而變得容易。
示例3-5處理的命令是ApplicationCommand.New。如果這組標準命令并沒有滿足你的應用程序的需要，你可以為明確的操作定義自定義命令。
3.2.5.2定義命令
示例3-6顯示了如何定義一個命令。WPF使用對象實例來確定命令的唯一性。如果你要創建同名的第二個命令，這不會被當作同樣的命令。由于這個原因，命令通常放置在靜態字段或屬性。
示例3-6
Example?3-6.?Creating?a?custom?command
public?partial?class?Window1?:?Window?{
????public?static?RoutedCommand?FooCommand;
????static?Window1(??)?{
????????InputGestureCollection?fooInputs?=?new?InputGestureCollection(??);
????????fooInputs.Add(new?KeyGesture?
(Key.F,
?????????????????????????????????????ModifierKeys.Control|ModifierKeys.Shift));
????????FooCommand?=?new?RoutedCommand("Foo",?typeof(Window1),?fooInputs);
????}
????
}
在示例
3.2.5.3調用命令
不僅定義了一個自定義命令，示例3-6還顯示了一個將命令聯合到用戶輸入的方法。配置這個特別的命令用來被一個特殊的輸入表示所調用。當前支持兩種輸入表示類型：MouseGesture，是一個特別的由鼠標和觸筆選中的形狀；KeyGesture，正如在示例3-6中使用的，是一個特別的鍵盤快捷鍵。很多內嵌控件聯合了標準的表示。例如，ApplicationCommand.Copy聯合了標準的鍵盤快捷鍵，用來復制（大多數地方為Ctrl+C）。
雖然一個命令在創建的時候可以聯合一組表示, 在一個特別的窗體的上下文中，你可能希望為這個命令分配另外的快捷鍵。為了允許這樣做，用戶界面元素有一個InputBindings屬性。這個集合包含了InputBinding對象——聯合了輸入表示和命令。這些增加了聯合了命令的默認表示。
輸入表示如快捷鍵，不是唯一調用命令的方式。你可以在命令上調用Execute方法從而在代碼上調用它。正如示例3-7所示，Execute被重載了。如果你沒有傳遞參數，這個命令目標將會是任何得到焦點的元素，正如通過一個輸入表示調用一個命令。但是你可以傳遞任何你想要的目標元素。
示例3-7
ApplicationCommands.New.Execute(??);
or
ApplicationCommands.New.Execute(targetElement);
你可能想，要在菜單項和工具欄按鈕的
Click句柄中，編寫這樣的代碼。盡管如此，由于命令經常聯合于菜單項和工具欄按鈕，Button和MenuItem都支持Command屬性。這就唯一標志了要調用的命令，當元素被點擊的時候。這里，為命令本身，提供了一種聲明式的方式，而不是為每一個綁定到命令的UI元素提供一個句柄。示例3-8顯示了一個聯合了標準Copy命令的Button。示例3-8
<Button?Command="Copy">Copy</Button>
因為這個示例使用了來自ApplicationCommands類的標準命令，我們可以使用這個語法的簡寫形式，只需要指出命令名稱。因為命令不是定義表3-4中的類定義的，這就需要一些更詳細的信息。完整的命令屬性xaml語法是：
[[xmlNamePrefix:]ClassName.]EventName
如果當前只有事件名，這個事件假定為標準命令中的一個。例如，Undo是ApplicationCommands. Undo的簡寫。否則，你必須提供一個類的名稱，以及可能一個命名空間前綴。如果你正在使用自定義命令或者某個第三方組件定義的命令，這個命名空間前綴就是需要的。與Mapping這個XML處理指令（使外部類型在xaml文件中有效）協力工作。（參見附錄A獲取更多Mapping處理指令的信息。）
示例3-9顯示了命令名稱語法的使用——所有部分都在。M:MyCommand.Foo的值意味著當前正在討論的命令是在mylib組件的MyLib.Commands.MyCommands類中定義的，并且存儲在名為Foo的字段或屬性中。
示例3-9
<?Mapping?ClrNamespace="MyLib.Commands"?Assembly="mylib"??????????XmlNamespace="urn:mylib"??>
<Window?xmlns:m="urn:mylib"?>
????
????<Button?Command="m:MyCommands.Foo">Custom?Command</Button>
????
3.2.5.4支持命令
不僅可以被執行，命令還提供了一個QueryEnabled方法，返回了一個Boolean值表明命令是否能被立刻調用；某些命令僅在特定的上下文中有效。這個特征可以用來決定菜單或工具欄中的項是否應該變為灰色。調用QueryEnabled方法，會被以Execute同樣的方式處理；CommandBinding對象用于處理這次查詢。這個綁定激活一對PreviewQueryEnabled和QueryEnabled事件，這將以與PreviewExecute和Execute同樣的方式進行tunnel和bubble。示例3-10顯示了如何處理這個事件，為了系統定義的Redo命令。
示例3-10
public?Window1(??)?{
????InitializeComponent(??);
????CommandBinding?redoCommandBinding?=
????????????new?CommandBinding(ApplicationCommands.Redo);
????redoCommandBinding.QueryEnabled?+=?RedoCommandQueryEnabled;
????CommandBindings.Add(redoCommandBinding);
}
void?RedoCommandQueryEnabled(object?sender,?QueryEnabledEventArgs?e)?{
????if?(!CanRedo(??))?{
????????e.IsEnabled?=?false;
????}
}
不幸的是，截止到寫作時間，當前
WPF的版本并不會使菜單或工具欄中的項變灰。它會激活QueryEnabled事件當一個菜單項被調用時，以及防止命令的執行，如果被disabled了，但是當前不提供任何可視化的指示，來表明一個項被disabled。我們希望這個問題會被解決在將來的版本中。我們已經看到在WPF中控件是如何處理輸入的所有可能方式。現在讓我們開一下一組內嵌在WPF中的控件。
總結
以上是生活随笔為你收集整理的《Programming WPF》翻译 第3章 2.处理输入的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 二少爷错题集锦
- 下一篇： WPF中Auto与*的区别