WPF入门教程 - 图文

C#代码：

StackPanel mainStackPanel = new StackPanel(); TextBox mainTextBox= new TextBox(); Menu stackPanelMenu = new Menu(); MenuItem pasteMenuItem = new MenuItem(); stackPanelMenu.Items.Add(pasteMenuItem); mainStackPanel.Children.Add(stackPanelMenu); mainStackPanel.Children.Add(mainTextBox); pasteMenuItem.Command = ApplicationCommands.Paste;

以上例子全是单条命令绑定的情形，事实上，你也可以多个按钮多条命令绑定到同一控件上，比如：

WPF中的控件模板(ControlTemplate)

【IT168技术文档】WPF包含数据模板和控件模板，其中控件模板又包括ControlTemplate和ItemsPanelTemplate，这里讨论一下ControlTemplate。

其实WPF的每一个控件都有一个默认的模板，该模板描述了控件的外观以及外观对外界刺激所做出的反应。我们可以自定义一个模板来替换掉控件的默认模板以便打造个性化的控件。

与Style不同，Style只能改变控件的已有属性值（比如颜色字体）来定制控件，但控件模板可以改变控件的内部结构（VisualTree，视觉树） 来完成更为复杂的定制，比如我们可以定制这样的按钮：在它的左办部分显示一个小图标而它的右半部分显示文本。

要替换控件的模板，我们只需要声明一个ControlTemplate对象，并对该ControlTemplate对象做相应的配置，然后将该ControlTemplate对象赋值给控件的Template属性就可以了。

ControlTemplate包含两个重要的属性：

1，VisualTree，该模板的视觉树，其实我们就是使用这个属性来描述控件的外观的

2，Triggers，触发器列表，里面包含一些触发器Trigger，我们可以定制这个触发器列表来使控件对外界的刺激发生反应，比如鼠标经过时文本变成粗体等。

参考以下代码 在上面的代码中，我们修改了Button的Template属性，我们定义了一个ControlTemplate，在 ... 之间包含的是模板的视觉树，也就是如何显示控件的外观，我们这里使用了一个Ellipse（椭圆）和一 个TextBlock（文本块）来定义控件的外观。

很容易联想到一个问题：控件（Button）的一些属性，比如高度、宽度、文本等如何在新定义的外观中表现出来呢？

我 们使用TemplateBinding 将控件的属性与新外观中的元素的属性关联起来Width=\Button.Width}\，这样我们就使得椭圆的宽度与按钮的宽度绑定在一起而保持一致，同理我们使用Text=\将TextBlock的文本与按钮的Content属性绑定在一起。 除了定义控件的默认外观外，也许我们想还定义当外界刺激我们的控件时，控件外观做出相应的变化，这是我们需要触发器。参考以下代码：

在上面的代码中注意到... 之间的部分，我们定义了触发器

你可以粘贴以下代码到XamlPad查看效果： 接下来的一个问题是：如果我要重用我的模板，应该怎么办呢？ 你需要将模板定义为资源，其实大多数情况下，我们也是这样做的 参考以下代码： 上面的代码将我们原来的模板定义为窗体范围内的资源，其中TargetType=\指示我们的模板作用对象为Button，这样在整个窗体范围内的按钮都可以使用这个模板了，模板的使用方法也很简单：

你可以粘贴以下代码到XamlPad查看效果：

额外提一下的是，我们也可以在触发器中，调用一个故事板来达到对事件响应时的动画效果 参考以下代码 我们为模板定义了一个动画资源，此后在模板的触发器中我们就可以调用该资源来实现一个动画效果了：

你可以粘贴以下代码到XamlPad查看效果：

最好的模板示例：我们知道每个控件都有自己默认的模板，这是MS编写的，如果我们能够得到这些模板的XAML代码，那么它将是学习模板的最好的示例， 要想获得某个控件ctrl的默认模板，请调用以下方法： string GetTemplateXamlCode(Control ctrl) { FrameworkTemplate template = ctrl.Template; string xaml = \if (template != null) { XmlWriterSettings settings = new XmlWriterSettings(); settings.Indent = true; settings.IndentChars = new string(' ', 4); settings.NewLineOnAttributes = true; StringBuilder strbuild = new StringBuilder(); XmlWriter xmlwrite = XmlWriter.Create(strbuild, settings); try { XamlWriter.Save(template, xmlwrite); xaml = strbuild.ToString(); } catch (Exception exc) { xaml = exc.Message; } } else { xaml = \} return xaml; }

揭露WPF SDK“不能说的秘密”

【IT168 专稿】 如果经历过.NET的1.0,1.1以及2.0版本，你就很可能发现.NET 3.0中的WPF区域中的一些文档有点不同。具体来说，WPF负责介绍几个CLR和托管代码封装方面的新概念。WPF SDK团队为在参考资料中展示这些新概念而做的努力是很大的进步，主要致力于改变，因为其它的技术也在它们的API中采用了相同或者类似的范例。

System.Reflection和.NET 3.0 SDK

微软用于创建托管SDK框架的“魔法”其实就是映射进程（典型的就是采用托管映射，但有时也有非托管的映射，这取决于API）。编译工具映射所有.NET 3.0的API，SDK作者就在纲要中填充映射告诉我们的关于API的消息（至少这是一个目标）。但是对于比System.Reflection本身更新 的编程概念的映射，System.Reflection做得不是特别好。你可以通过查看定制特性来得到一些更具体的信息。但对于那些像XAML一样的语 言，或者独立属性，由于System.Reflectio从1.1开始就没有本质的改变，所以不能为3.0提供好的API。如果你要编写自己的映射，你不 得不做些额外的创造工作（我不会在这里描述这个问题，因为太复杂了，而且超出了本主题的范围）。对我们的SDK开发团队来说，他们也不得不非常熟悉映射代 码。然后，其他的各种各样的人，包括一些像我们这样的程序员不得不跟上表示策略——怎么在更好，更标准的托管代码段文档中表示额外的信息，比如异常和返回 值等。

正在讨论的隐藏的秘密是参考主题部分，这部分是大量的设计会议和开发工作的结果。每一个隐藏秘密都代表着编程的一个具体方面，和WPF非常相关并且对 WPF来说是新内容。所有的信息都在SDK页面，等待你的发掘。但是，我们还没搞清楚这些突然在WPF参考文档中出现的额外段落是什么，以及他们意味着什 么。

抛开这些吧。让我们来照亮这些WPF文档中隐藏的秘密。一切都会得到解释！

独立属性

很多时候会被问道一个问题“独立属性到底是什么？”或者一个相关的更尖锐的问题“我为什么要去关心一个东西是不是独立属性呢？”我们的答案是：独立属性总览。

跨过这个概念上的障碍之后，下一个逻辑上的问题可能是“好吧，独立属性就是一种支持CLR属性的方式，那我该怎么分别那些属性是通过这种方式被支持的呢？”我们遇到的第一个隐藏秘密是：独立属性，和独立属性信息段。

在文档中提到两种方法来判断某个给定的属性是否是独立属性：

1）当你在浏览任何类型的成员表，并且看到公共属性，读描述的时候。如果这个属性是独立属性，那么描述的最后一句就是“这是一个独立特性。”

2）假设你在说明CLR属性的SDK的主题页面。同样，在成员表的相同的描述中，你可以找到这句话“这是一个独立属性”。除了描述外，每一个独立属性的属性页面内还有一段可以被合适地成为独立属性信息段。这一段在表格中包含两点：

一个到含有独立属性标志符的域的链接。很多属性系统API函数都需要这个标志符以执行一个属性或者获得关于它的信息。有人说，对那些只是获取或设置某个已 经存在的具体属性的应用程序编程来说，使用属性系统API并不总是必须的，因为你可以调用更简单的独立属性CLR“封装”。这样，标志符主要是和包含独立 属性的高级编程任务相关，比如处理属性元数据，或者追踪属性值。

如果一个属性是框架层的属性，那么独立属性信息段会把元数据中“标记”为true的列出来。当独立属性被WPF框架层解释时，标记报告独立属性的某些共同 特征，尤其是子特征，比如，整体系统，数据绑定，或属性值继承。SDK报告这些标记，因为这有助于实例了解改变属性是否会强迫修改整体设计，或是否你可以 省略指定绑定的两个状态，因为这是独立属性的默认设置。 默认值

横跨独立属性和“常规”属性的一个概念是默认值。一般来说，.NET文档会在属性值段告诉你属性的默认值，并且为保持一致性，这也是默认属性被报告给独立 属性的地方。但是，独立属性默认值实际上来自属性元数据，尽管在一个平面上CLR属性可能来自一个类或者是拓展执行。这样，通过重写属性元数据，独立属性 就可以被子类或新的属性拥有者轻易改变。在已有的WPF独立属性中偶尔会发生这种情况。当发生时，每一个类的重写都会被记录在Remark段。 Routed事件

在你不可避免地问“什么是routed事件？”之前，可以去这里看看Routed Events Overview。现在我们解决这个问题了。

不 像独立属性，routed事件没有像“这是一个routed事件”之类的习惯性描述。基本元素（UIElement, FrameworkElement, ContentElement, FrameworkContentElement）有很多的routed事件：可能它们的事件有75%都是routed的。其它的类，像控件也会有少数的 routed事件，也许和着一些不route的标准CLR事件。为了区分一个事件是否route，你需要在事件主题看看是否有Routed事件信息段。 Routed事件信息段是一个有如下三项的表：

*一个指向包含有routed 事件标志符的域的链接。和属性系统API以及独立属性标志符一样，事件系统API也需要这个标志符以接入事件。像增加或移除句柄一类的简单操作并不是必须 标志符，这也是因为routed事件会有一个“包装”，这样就可以支持CLR语言中增加/移除事件句柄的CLR语法。但，如果直接使用 AddHandler或调用RaiseEvent，就需要知道routed事件的标志符。

*Routing策略。有三种可能：Bubbling，Tunneling，和Direct。这儿有个小秘密：如果之前查看过事件名字，那么 routing策略就总是Tunneling，这是一个惯例。但区分Bubbling和Direct就有点困难了，因为没有不同的命名习惯。所以，我们提 供了参照页的信息。Direct事件实际上没有在它的元素之外route，但他们仍然服务于WPF-specific目的，在这里有描述Routed Events Overview。

* Delegate类型。你可以在声明事件的语法中找到列出的delegate。我们在这里重复是为了方便，所以你可以直接跳到“写恰当的句柄”的地方。

附带属性

严格地说，附带属性是XAML的概念，而不是WPF的。但WPF 是第一个发行的采用了XAML语言的工具。所以WPF是用文档来描述XAML语法和XAML语言的先锋。如果你是代码编写员，并看了某个附带属性的叫做 DockPanel.Dock的文档，就会注意到一些特别的东西：没有XAML语法，没有代码语法。如果浏览DockPanel类，去看映射或对象就可以 证实：对CLR没有类似于“Dock”属性的东西。甚至为了在其它的产生映射的参照中使这个页面存在，SDK开发团队不得不注入这个页面。然而，对我们这 些在标记和代码间可以随意转换的人来说，附带属性的语法段确实提供了一个到附带属性的“真实”代码API的链接，这可以成为一系列获取和设置的接入方法。 对DockPanel 类来说有 GetDock和SetDock。（不幸

的是，在MSDN版本的这些页面中似乎没有这些链接；在Visual Studio和offline Windows SDKs中有…相信我...）

附属事件

类似地，这是一个XAML的概念，但在WPF得到具体的应用。XAML语法，但对同等代码接入来说是一个“秘密”接入方法。在附属事件情况下，这些方法的 类型是Add*Handler和Remove*Handler。例如，Mouse.MouseDown调用AddMouseDownHandler就可以 有附带到给定的UIElement实例的句柄，并可以通过RemoveMouseDownHandler移除。对实际应用来说，附属事件不一定那么重要， 因为大多数都是被UIElement以更方便的方式重新使用而已。但如果你在写一套相关的控件，或者在实现一个服务，那么附属事件就很可能进入你的视野。 XAML 语法

SDK文档提供了XAML各种用途下的XAML语法，比如用来实例化一个XAML类的对象元素标签，用来设置属性或附带事件句柄的属性，还有XAML的具 体概念，如content property或property element语法。另一个隐藏的秘密来了...好的，也不是那么的隐秘了，因为我以前已经在博客上写过了。XAML不一定非要被绑定到计划中。最终决定 XAML是否有效的是XAML loader，最终成功还是失败取决于一些加载动作，比如试图在组件中找到一个命名匹配的类型，调用它的默认ctor，以及返回一个实例。或者，一旦对象 存在，就是试图找到一个匹配属性名字的property，然后试图用属性值的string-to-X变换，或者甚至是更复杂的在property元素中以 子关系存在的XAML的什么东西的封装来填充它。对于保持XAML的扩展性来说是有必要的，但是这会让编写文档和静态的XAML词典更困难一点儿。其一， parser会允许你实例化一个在对象模块中没有“家”的元素。比如，大多数EventArgs子类可以在XAML中建立，因为它们可以方便的拥有一个默 认ctor（加入XAML俱乐部是如此容易....）但是，然后呢？从狭义来说，XAML是UI定义上的。广义上讲，XAML是相关的对象和你希望建立的 他们的属性的任何结构的定义。你不能把EventArgs作为任何具有可疑资源收集异常的东西的子元素。这让XAML文档进退两难：这是XAML吗，或者 不是？这个困惑经常出现。一般来说，我们用具体情况来说明XAML。有什么原因让你希望用XAML来实例化这个类吗？如果有，我们会给你看一个语法。如果 没有，就像3.0的EventArgs子类一样，我们会告诉你这并不是一个典型的应用，虽然XAML loader会在和其它面向应用的对象模型完全隔离的情况下用XAML来建立一个。

另一个秘密：虽然没有写出语法（会说这是不适用的东西），但是在frameworks中有很多支持XAML的类。一般来说，这是因为这些类来自更早的版 本，可以在整个3.0 framework中使用，因为可能合法的XAML使用率会很大。所以，为了填补空白，用户需要知道一些XAML的技巧。对初学者，读XAML and Custom Classes就可以了。当以默认的ctor和一些其它的限定来符合XAML加载器的要求时，定制的类和已有的类没什么不同的。也去看看x:Array Markup Extension中的例子吧。这个例子讲了系统名字空间和mscorlib组件，这样你就可以吧String类作为一个直接对象进行实例化。你可以外推 这些简单的概念，并做些更有用的事情。甚至设想这个场景都有点困难，但是你们是一个充满创造性的集体：让我们看看你们能做什么！描绘一些 System.Data的结构？谁知道在pre-3.0 .NET的核心部分用了多少XAML？

没有XAML属性列表？

SDK并不是真的有一个“所有权页面”，这是XAML特有的。你可以把property列表看作是普通的成员表的一部分，但要选出XAML属性有点困难， 因为有些是只读的，有些又不使用支持XAML的类型，等等。这里，我想我们不得不承认工具和设计者可以比只利用SDK的成员表做得更好。因为工具和设计者 有

语义的优势；他们知道你刚刚实例化了什么面板子类，在元素树里面它处于什么位置等。好好地综合基于工具的只列出基本的可能性的智能，然后学会按F1来获 取SDK页面的更多的帮助信息。这是我们追赶即将来临的工具/SDK的发行的下一步。限于篇幅，不能细细讲解。

没有XAML XSD的计划？

我以前在博客上写过这个。对一个像WPF这样有很多维的产品来说，XAML的计划很困难。但你也许已经注意到接下来的XAML综合技术（Workflow Foundation, Silverlight）确实包括了XSD类型的计划。说到WPF XAML的计划，我们仍然保持观望。 WPF图形系统 【IT168 技术文档】

在Windows NT中，图形多媒体系统基于层次结构。应用程序与顶层的API（实际上是多个用户模式的系统DLL，比如GDI32.DLL）交互，这些系统DLL最终会 通过系统服务调用处于内核模式的系统服务。NT系统的详细信息可参考《Windows 图形编程》的第一、二章。在Windows Vista中，图形系统已经移出了内核模式，并有自己的空间－－WPF。 WPF移出内核除了全面提高稳定性（内核模式中通常需要共享资源），也使得实现内核模式高级控制成为可能。

首先，WPF不再唯一依靠GDI图形API，Vista更多的依靠Direct3D处理图形操作，这样允许更多的D3D特征，实现更酷的外观和效果。当 然，为了实现这样的效果，Vista的设计上也有所改变。Windows Vista尽量不用CPU进行显示，而是用显示卡的图形处理单元（Graphics Processing Unit, GPU），用矢量图代替位图。 Windows Vista还采用了另外一种驱动模型－－Windows显示驱动模型（WDDM）。实现操作系统和图形卡GPU之间更复杂的通信。为了处理操作系统更高的3D处理请求，新的WDDM驱动类型需要更多的显示卡内存。Vista能尽可能的利用显示卡以达到最好的性能。

现在基本了解了Windows Vista图形系统，再看看其可测量性。Windows Vista可提供非常高的终端图形，据此很多人都错误的认为：为了运行Windows Vista操作系统，必须要非常高端的图形硬件。事实上并不完全如此。Windows Vista图形系统一个关键好处就是可以检测显示卡的性能。Vista根据不同的性能和驱动模型（WDDM，XPDM）提供给用户不同的用户体验。

在Windows NT中，图形多媒体系统基于层次结构。应用程序与顶层的API（实际上是多个用户模式的系统DLL，比如GDI32.DLL）交互，这些系统DLL最终会 通过系统服务调用处于内核模式的系统服务。NT系统的详细信息可参考《Windows 图形编程》的第一、二章。在Windows Vista中，图形系统已经移出了内核模式，并有自己的空间－－WPF。

WPF移出内核除了全面提高稳定性（内核模式中通常需要共享资源），也使得实现内核模式高级控制成为可能。首先，WPF不再唯一依靠GDI图形API， Vista更多的依靠Direct3D处理图形操作，这样允许更多的D3D特征，实现更酷的外观和效果。当然，为了实现这样的效果，Vista的设计上也 有所改变。Windows Vista尽量不用CPU进行显示，而是用显示卡的图形处理单元（Graphics Processing Unit, GPU），用矢量图代替位图。

Windows Vista还采用了另外一种驱动模型－－Windows显示驱动模型（WDDM）。实现操作系统和图形卡GPU之间更复杂的通信。为了处理操作系统更高的 3D处理请求，新的WDDM驱动类型需要更多的显示卡内存。Vista能尽可能的利用显示卡以达到最好的性能。 WPF性能优化点 【IT168 技术文档】

在建立漂亮UI的同时，我们还需要关注应用程序的性能，WPF尤其如此。下面从MS的文档中总结出了一些有用的性能优化点。在实际编写的过程中，可以参考。这个Post非完全原创，是根据一些文档总结出来的。

1、建立逻辑树的时候，尽量考虑从父结点到子结点的顺序构建。因为当逻辑树的一个结点发生变化时（比如添加或删除），它的父结点和所有的子结点都会激发Invalidation。我们应该避免不必要的Invalidation。

2、当我们在列表（比如ListBox）显示了一个CLR对象列表（比如List）时，如果想在修改List对象后，ListBox也动态的反映这种变 化。此时，我们应该使用动态的ObservableCollection对象绑定。而不是直接的更新ItemSource。两者的区别在于直接更新 ItemSource会使WPF抛弃ListBox已有的所有数据，然后全部重新从List加载。而使用ObservableCollection可以避 免这种先全部删除再重载的过程，效率更高。

3、在使用数据绑定的过程中，如果绑定的数据源是一个CLR对象，属性也是一个CLR属性，那么在绑定的时候对象CLR对象所实现的机制不同，绑定的效率也不同。

A、数据源是一个CLR对象，属性也是一个CLR属性。对象通过TypeDescriptor/PropertyChanged模式实现通知功能。此时绑定引擎用TypeDescriptor来反射源对象。效率最低。

B、数据源是一个CLR对象，属性也是一个CLR属性。对象通过INotifyPropertyChanged实现通知功能。此时绑定引擎直接反射源对象。效率稍微提高。

C、数据源是一个DependencyObject，而且属性是一个DependencyProperty。此时不需要反射，直接绑定。效率最高。

4、访问CLR对象和CLR属性的效率会比访问DependencyObject/DependencyProperty高。注意这里指的是访问，不要和 前面的绑定混淆了。但是，把属性注册为DependencyProperty会有很多的优点：比如继承、数据绑定和Style。所以有时候我们可以在实现 DependencyProperty的时候，利用缓存机制来加速访问速度：看下面的缓存例子：

public static readonly DependencyProperty MagicStringProperty = DependencyProperty.Register(\typeof(string), typeof(MyButton), new PropertyMetadata(new PropertyInvalidatedCallback(OnMagicStringPropertyInvalidated),new GetValueOverride(MagicStringGetValueCallback))); private static void OnMagicStringPropertyInvalidated(DependencyObject d) { // 将缓存的数据标识为无效 ((MyButton)d)._magicStringValid = false; } private static object MagicStringGetValueCallback(DependencyObject d) { // 调用缓存的访问器来获取值 return ((MyButton)d).MagicString; } // 私有的CLR访问器和本地缓存 public string MagicString { get { // 在当前值无效时，获取最新的值保存起来 if (!_magicStringValid) { _magicString = (string)GetValueBase(MagicStringProperty); _magicStringValid = true; } return _magicString; } set { SetValue(MagicStringProperty, value); } } private string _magicString; private bool _magicStringValid; 另外，因为注册的DependencyProperty在默认是不可继承的，如果需要继承特性，也会降低DependencyProperty值刷新的效 率。注册DependencyProperty属性时，应该把DefaultValue传递给Register方法的参数来实现默认值的设置，而不是在构 造函数中设置。

5、使用元素TextFlow和TextBlock时，如果不需要TextFlow的某些特性，就应该考虑使用TextBlock，因为它的效率更高。

6、在TextBlock中显式的使用Run命令比不使用Run命名的代码要高。

7、在TextFlow中使用UIElement（比如TextBlock）所需的代价要比使用TextElement（比如Run）的代价高。

8、把Label（标签）元素的ContentProperty和一个字符串（String）绑定的效率要比把字符串和TextBlock的Text属性 绑定的效率低。因为Label在更新字符串是会丢弃原来的字符串，全部重新显示内容。

9、在TextBlock块使用HyperLinks时，把多个HyperLinks组合在一起效率会更高。看下面的两种写法，后一种效率高。

A、

B、

10、任与上面TextDecorations有关，显示超链接的时候，尽量只在IsMouseOver为True的时候显示下划线，一直显示下划线的代码高很多。

11、在自定义控件，尽量不要在控件的ResourceDictionary定义资源，而应该放在Window或者Application级。因为放在控件中会使每个实例都保留一份资源的拷贝。

12、如果多个元素使用相同的Brush时，应该考虑在资源定义Brush，让他们共享一个Brush实例。

13、如果需要修改元素的Opacity属性，最后修改一个Brush的属性，然后用这个Brush来填充元素。因为直接修改元素的Opacity会迫使系统创建一个临时的Surface。

14、在系统中使用大型的3D Surface时，如果不需要Surface的HitTest功能，请关闭它。因为默认的HitTest会占用大量的CPU时间进行计算。 UIElement有应该IsHitTestVisible属性可以用来关闭HitTest功能。 WPF中的Style 【IT168 技术文档】

Style是一种修改属性值是方法。我们可以将其理解为对属性值的批处理。对批处理大家应该不会感到默认。对，通过Style我们可以批量修改属性的值。先从一个简单的Style例子开始：

WPT通过BasedOn对这种特殊的Style提供了支持。很明显，BasedOn的意思是我们当前的Style基于在资源的CheckBox。这里又 看到了x;Key扩展标记。因为我们需要的是一个特例，一个特殊的Style对象。为了以后引用这个Style，我们需要x:Key的标识作用。其它的代 码与前面类似。

定义后，引用这个特殊Style的CheckBox的代码是这样的：

你已经看到，我们在CheckBox中指定了Style属性，并引用前面的StaticResource标记。 WPF与Win32 【IT168 技术文档】

GDI是当今应用程序的主流图形库，GDI图形系统已经形成 了很多年。它提供了2D图形和文本功能，以及受限的图像处理功能。虽然在一些图形卡上支持部分GDI的加速，但是与当今主流的Direct3D加速相比还 是很弱小。GDI+开始出现是在2001年，它引入了2D图形的反走样，浮点数坐标，渐变以及单个象素的Alpha支持，还支持多种图像格式。但是， GDI+没有任何的加速功能（全部是用软件实现）。

当前版本的WPF中，对一些Win32功能还没有很好的支持，比如WMF/EMF文件，单个象素宽度的线条等等。对于这些需求还需要使用GDI/GDI+来实现。

在Windows Vista中，GDI和GDI+仍然支持，它们与WPF并行存在，但是基本上没有任何功能性的改进。对GDI和GDI+的改进主要集中在安全性和客户相关 问题上。WPF的所有提交都不依赖于GDI和GDI+，而是Direct3D。并且所有的Primitive都是通过Direct3D的本地接口实现的。 还记得我前面随笔中提到过的Milcore吗？它就是和Direct3D交互的非托管代码组件。由于WPF的大部分代码都是以托管代码的形式存在的，所以 WPF中有很多托管、非托管的交互。当然，在一些图形卡不支持WPF所需要的功能时，WPF也提供了稍微低效的软件实现，以此来支持在某些PC上运行 WPF应用程序。

在Windows Vista中，Direct3D的关键改进就是引入了新的显示驱动模型。VDDM驱动模型虚拟化了显卡上的资源（主要是显示内存），提供了一个调度程序， 因此多个基于Direct3D的应用程序可以共享显卡（比如WPF应用程序和基于WPF的Windows Vista桌面窗口管理）。VDDM的健壮性、稳定性也得到了提高，大量的驱动操作从内核（Kernel）模式移动到了用户（User）模式，这样提高了 安全性，也简化了显示驱动的开发过程。

在Windows Vista中存在两个版本的Direct3D：Direct3D 9和Direct3D 10。WPF依赖于Direct3D 9，这样能更广泛的解决兼容性问题。另外一个非常重要的原因就是为Vista的服务器版本提高方便，因为服务器版本的Vista对显卡和Direct3D 基本上没有任何的要求。同时WPF也支持Direct3D 10。Direct3D 10依赖与VDDM，只能在Windows Vista上使用。由于Windows XP没有VDDM，虽然Microsoft做了很大的努力来改善XP中Direct3D 9相关驱动，提高内容的显示质量，但是由于XP中没有对显卡资源的虚拟化，强制所有的应用程序都用软件提交。

WPF对某些多媒体的功能支持还需要依赖老的技术，比如DirectShow。当我们进行音频视频的捕捉或者其它任务时，只能直接用DirectShow实现，然后再用HwndHost嵌入到WPF内容当中。

利用类似的技术，我们可以在WPF应用程序中显示自定义格式的内容。通过提供自定义的DirectShow CODEC，然后用Media元素实现和WPF内容毫无限制的集成。

另外，WPF对XPS等文档的打印输出也得到了极大的改善。XPS文档本身的规范也极大的提高了其打印的质量，XPS文档的规范可以参考MSDN的资料。 除了打印，Vista操作系统中对远程的改进也部分依赖于WPF，比如有远程协助、远程桌面和终端服务等等。它们的实现过程是通过发送一系列的“远程”命 名到客户端，客户根据自己PC的性能和命名进行显示，这样显示的质量能得到极大的提高。

在WPF中，对Direct3D进行各种封装。当然，如果你本身对Direct3D/OpenGL很熟悉，也可以直接在WPF中使用。封装后的 Direct3D更容易使用。并且在Web应用程序（XBAP）也可以使用Direct3D。在WPF中使用的Direct3D，没有直接用非托管代码控 制所拥有的灵活性，也不能直接对硬件进行底层控制。

WPF中所有的提交都是矢量形式的，我们可以对图像或窗口进行任意级的放缩，而图像的质量不会有任何的损耗。

WPF的逻辑树和视觉树 【IT168 技术文档】

这部分的内容来自于即将出版的新书《WPF Unleashed》的第三章样章。关于什么是逻辑树，我们先看下面的一个伪XAML代码的例子：

LabelText 在这样一个简单UI中，Window是一个根结点，它有一个子结点StackPanel。而StackPanel有一个子结点Label。注意Label 下还有一个子结点string（LabelText），它同时也是一个叶子结点。这就构成了窗口的一个逻辑树。逻辑树始终存在于WPF的UI中，不管UI 是用XAML编写还是用代码编写。WPF的每个方面（属性、事件、资源等等）都是依赖于逻辑树的。

视觉树基本上是逻辑树的一种扩展。逻辑树的每个结点都被分解为它们的核心视觉组件。逻辑树的结点对我们而言基本是一个黑盒。而视觉树不同，它暴露了视觉的 实现细节。下面是Visual Tree结构就表示了上面四行XAML代码的视觉树结构：

并不是所有的逻辑树结点都可以扩展为视觉树结点。只有从System.Windows.Media.Visual和 System.Windows.Media.Visual3D继承的元素才能被视觉树包含。其他的元素不能包含是因为它们本身没有自己的提交 （Rendering）行为。

在Windows Vista SDK Tools当中的XamlPad提供查看Visual Tree的功能。需要注意的是XamlPad目前只能查看以Page为根元素，并且去掉了SizeToContent属性的XAML文档。如下图所示：

注意图中工具栏特别标记的地方。我们可以看到Visual Tree确实比较复杂，其中还包含有很多的不可见元素，比如ContentPresenter。Visual Tree虽然复杂，但是在一般情况下，我们不需要过多地关注它。我们在从根本上改变控件的风格、外观时，需要注意Visual Tree的使用，因为在这种情况下我们通常会改变控件的视觉逻辑。

WPF中还提供了遍历逻辑树和视觉树的辅助类：System.Windows.LogicalTreeHelper和

System.Windows.Media.VisualTreeHelper。注意遍历的位置，逻辑树可以在类的构造函数中遍历。但是，视觉树必须在经 过至少一次的布局后才能形成。所以它不能在构造函数遍历。通常是在OnContentRendered进行，这个函数为在布局发生后被调用。

其实每个Tree结点元素本身也包含了遍历的方法。比如，Visual类包含了三个保护成员方法

VisualParent、 VisualChildrenCount、GetVisualChild。通过它们可以访问Visual的父元素和子元素。而对于 FrameworkElement，它通常定义了一个公共的Parent属性表示其逻辑父元素。特定的

FrameworkElement子类用不同的方式 暴露了它的逻辑子元素。比如部分子元素是Children Collection，有是有时Content属性，Content属性强制元素只能有一个逻辑子元素。 WPF中的命令与命令绑定 【IT168 技术文档】

说到用户输入，可能我们 更多地会联想到键盘、鼠标、手写笔，其实还用一种高级别的输入——命令（Commands），从WPF类库角度讲他们分别对于Keyboard， Mouse，Ink与ICommand。命令是一种语义级别的输入而不是设备级别的，比如“复制”与“粘贴”，但实现一个命令可以有很多中方式，比如“粘 贴”，我们可以使用CTRL-V，也可以使用主菜单或右键菜单（上下文菜单）等等。在以往的.net版本中，要在软件界面上添加一个“粘贴”按钮，是非常 麻烦的事情，你得监视剪切板中是否有可用的文本以及对应的文本框是否获得了焦点以便启用或禁用该按钮，当粘贴时你还得从剪切板中取得相应的文本并插入到文 本框的合理位置，等等。

在WPF中提供的命令机制能非常简单地实现这些任务，下面的Demo演示了如何简单到不用手动编写一行后台逻辑代码便解决上面的难题的，你可以粘贴下面的代码到XamlPad:

本文来源：https://www.bwwdw.com/article/ed53.html