Category Archives: WPF

Intro: Heroius.Extension.WPF

under editing

简介

Heroius.Extension.WPF 是 Heroius Packs 基础工具包中的一员,面向 WPF 平台提供附加支持,包括多种复杂转换器、枚举和颜色拓展、绑定工具等。可以通过 nuget.org 获取其最新的发布版本,该库包含对底层 Heroius Packs 库的引用,因此可以同时获得相应的功能接口。此文按照相对独立的功能介绍库的内容,在每节内容的开始都会标明支持的版本号。
当前内容基于版本:1.1.8.2
Continue reading

在WPF中使用变通方法实现枚举类型的XAML绑定

问题缘起

WPF的分层结构为编程带来了极大便利,XAML绑定是其最主要的特征。在使用绑定的过程中,大家都普遍的发现枚举成员的绑定是个问题。一般来说,枚举绑定多出现于与ComboBox配合的情况,此时我们希望实现的目标有:

  1. 建立选择项与ItemsSource的对应关系;
  2. 自动获取用于ItemsSource的枚举源;
  3. 自定义下拉框中显示的内容。

对于目标1,考虑最简单的模式,即枚举的定义采用从0开始的连续整数,可以使用IValueConverter接口来实现从枚举到整型的双向转换,以使得枚举成员绑定到SelectedIndex上。

有些朋友提出使用静态ObjectDataProvider资源作为ItemsSource的来源,这种方式可实现枚举成员的直接绑定,不需要值转换,其缺点是对于每一个枚举类型都要添加一个提供者,当项目较大、枚举类型多时使用起来很不方便。

考虑到枚举的比较是值类型比较,Broculos想到了比较聪明的方法同时实现了目标1和目标2:定义一个返回枚举兄弟成员的标记拓展(MarkupExtension)。使用时向标记拓展中提供枚举类型即可。相比于上一种方法,该方法更加简单明了,只是当在XAML中提供枚举类型时,需要引用其命名空间,而XAML中的命名空间引用缺少自动完成机制,有时需要搜索一番。

当然,上面所有解答都没有实现目标3。网友ding.li使用代码方式对下拉框内容进行设置,虽然实现了目标3,但违背了目标2。

Mgen通过定义一个提供附加属性的类实现了所有3个目标。在Selector要素中,设置EnumSelector.EnumType和EnumSelector.BindingPath附加属性来指定ItemsSource和SelectedItem,而非直接设置要素的相应属性。该方法实际上发展了标记拓展的思路,为实现目标3而进行了较复杂的设计。这是非常好的实现方案,缺点是违反直观感受。

变通方案

本文介绍使用封装枚举类型的方法同时实现3个愿望。主要思路是,在XAML中尽可能少的写入代码,通过上下文绑定直接设置下拉框的ItemsSource,SelectedItem,以及显示内容。

注意到DisplayMemberPath和Binding拓展的Path属性,要同时由上下文提供多个属性用来绑定,分别是:作为ItemsSource源的集合、作为SelectedItem的实例、及作为“DisplayMember”的字符串。显然直接使用枚举实例无法提供所需属性成员,因此设计封装类型并在其中定义成员如下:

这样在XAML中的下拉框代码绑定可写为:

可以通过EnumShell实例上下文获取所有必要信息。

下面简述该类型的实现。

泛型类EnumShell<T>的构造函数接受类型T的参数,该参数是特定枚举类型的实例,因此T即为某个枚举类型。该参数由Instance属性保存,并从枚举类型获取到所有可用的枚举值,均封装为EnumShell<T>实例,并作为数组由Brothers属性公开。Description属性获取枚举值定义的DescriptionAttribute特定指定的文本,作为显示的内容。

考虑到ComboBox的项比较实际是EnumShell<T>实例的比较,因此不能单纯的使用其构造函数来得到Brothers集合,解决方法是定义一个静态的字典用于保存EnumShell<T>实例,使得通过一个枚举值永远得到唯一的一个EnumShell<T>实例。

完整的代码如下所示:

定义抽象的EnumShell类型作为基类型,可以在定义实体类型时不指明泛型类型参数,由此支持任意枚举类型的取值;定义静态的GetShell泛型函数,将新的EnumShell实例注册添加到全局字典;将EnumShell<T>构造函数的可见性进行限制,避免了自行实例化导致字典中没有注册的情况;EnumShell类公开了其他属性成员,以方便各种XAML绑定的情况。

使用时,将实体类型中的原枚举属性替换为EnumShell或EnumShell<T>属性,并使用EnumShell.GetShell进行实例化赋值。如,有枚举定义:

定义某实体类型,用EnumShell表示该枚举:

这样定义后即可使用,当需要执行switch分支时,可用Instance属性获取被封装的真正的枚举值。

结语

本文介绍的封装方法实现枚举绑定,适用于自定义实体类型的情况,对于直接使用第三方实体类型的情况,则无法直接使用,必须对实体类型本身进行再次封装,而这大大降低了便利性。

其实在早些时候有传言说C# 5.0会支持拓展属性,试想这要是真的,对枚举进行绑定将是轻而易举的事情,真的希望C#能够实现这一功能。

本文中的EnumShell类型在Heroius.Extension.WPF库中包含。更多可免费使用的程序集引用,请使用Heroius的Nuget服务源:http://heroius.com:8686/app/nuget。详细信息请访问http://heroius.com:8686/app

XAML UserControl的继承

前言

相信不少学习WPF和Silverlight的同学们都出于Winform的习惯,希望能够在新展示层框架中实现控件的继承。本文就是说明如何实现这一点。

但是在正文开始之前,必须要指明,一般情况下,在WPF/SL中并不推荐使用自定义控件或控件继承(当然,使用模板生成的Window, UserControl, Page不在此限),因为基于XAML的前台设计语言本身具有丰富的表现能力,且框架支持样式(Style)、模板(Template)等控制外观和行为的方式—-这些特性足以构建出任何形式的界面UI。反过来说,创建自定义控件或实现控件继承在WPF/SL中不仅不受推崇,其实现难度也要比Winform中大。

那么当什么时候才不得不使用自定义控件呢?就是这个控件需要在多处实例化使用,而本身内容较为复杂时。相比较而言,控件的继承使用的情况就更少了,它使用的必要性一般要满足如下几条:

  1. 只在原控件不满足新需求,但同时又有可资利用的价值;
  2. 新控件需要直接访问原控件成员(否则在新控件中包含原控件即可,不必继承);
  3. 新控件同样需要在多处使用。

如果你面临的情况满足这几个条件,阅读本文可能会提供帮助。

问题分析

在WPF/SL中实现控件继承之所以会比Winform困难,是因为在底层框架设计上WPF/SL将表示层彻底从逻辑中分离了出去,控件外观几乎均有XAML标记定义,而在对控件进行继承时,XAML部分对应的类型成员是无法被继承的。

以WPF为例,使用UserControl模板新建用户控件,得到一个.cs文件和一个.xaml文件。注意在.cs文件中类定义有partial修饰,说明是分部类,代码中的InitializeComponent函数即是在另外一部分代码(设计器生成代码)中定义的。这部分由设计器生成的代码和Winform中设计器的代码相差很大。

在生成文件夹中可以看到设计器生成的.g.i.cs文件,其中包含对应于XAML内命名成员的相应变量的定义,以及InitializeComponent方法实现。

可见于Winform设计器代码相比,其中不包含C#代码形式的控件初始化逻辑,所有界面表达均在xaml文件中,代码通过System.Windows.Application.LoadComponent方法从xaml文件实例化。

在.xaml文件中,可见<UserControl>标签及其属性x:class,此两者指明了XAML文档对应的类型信息,其中根元素是当前类型的基类(UserControl),x:class属性指定当前类型(UserControl1)。

注意到Application.LoadComponent方法包含两个重载:

  1. object (Uri) – 接受xaml资源的定位符,返回其根元素决定的实例;
  2. void (object, Uri) – 接受根元素类型实例和资源定位符。

自动生成代码采用了第2个重载,并传递当前类实例作为第一个参数,也就是说,XAML加载得到了拓展的UserControl1类型。

这种在xaml中指定类型信息的类(UserControl1)被称为是“由XAML定义的”。而XAML渲染器无法识别由XAML定义的根类型,也就是说当控件继承时,若在子类型控件(如UserControl2)设计器中指定其为根元素时,编译过程将失败。

但假如子类型不包含XAML代码,如新建Class1继承自UserControl1,则没有问题。

现在的问题是,在设计控件,尤其是结构较复杂时,我们往往需要借助设计器,这就要求必须使用XAML代码,这种情况应该如何应对呢?

XAML UserControl的继承

命题:两个带有设计界面的类型UserControl1和UserControl2,其中后者继承于前者。

思路:

  1. 对于xaml代码,利用Application.LoadComponent方法可获取根元素决定的实例;
  2. UserControl属于Content Control,其显示内容由Content决定;
  3. 基于以上两点,分离控件xaml部分,并修改为以某FrameworkElement为根,如此可得到用于设置Content属性的可视化内容。

UserControl2继承代码修改

修改UserControl2的代码,使其继承自UserControl1

修改xaml代码,将根元素设置为基类,注意引用本地程序集命名空间

 UserControl1 xaml和代码分离

UserControl1控件包含的.xaml和.xaml.cs文件由VS管理,为了使两者分开,需要重命名。先将项从项目中移除,分别重命名:

  1. UserControl1.xaml -> UserControl1_skin.xaml
  2. UserControl1.xaml.cs -> UserControl1.cs

重新加载到项目中,修改xaml文件根元素,使用Grid代替UserControl

移除UserControl.cs中类定义前的partial修饰符,并手动添加InitializeComponent函数,在其中利用Application.LoadComponent的第一个重载获取如上修改之后xaml编译得到的Grid实例,将其设置给Content:

 UserControl2的代码调整

为避免UserControl2自动生成代码覆盖基类的Content内容,在调用UserControl2的InitializeComponent函数之前需要获取基类Content,即上文中的Grid实例,并将其插入到当前UserControl2的最下层。

此时在主窗体中拖放UserControl2,程序运行效果如下:

其他注意事项

关于Silverlight

Silverlight中不包含 Application.LoadComponent的第一个重载,可事先创建Grid实例,之后将其作为参数调用 Application.LoadComponent第二重载,效果和WPF一样。

关于界面设计

若UserControl1界面中有交互内容,设计UserControl2时需要注意避让。

实际上,完全可以通过代码控制界面元素的布局,例如可以尝试将UserControl2构造函数的代码改成如下内容:

 示例代码

请移步百度网盘获取示例代码(基于VS2013)

  • 链接: http://pan.baidu.com/s/1ntG7AC5
  • 提取密码: k3k1