《Programming WPF》翻译 第9章 2.选择一个基类

原文:《Programming WPF》翻译 第9章 2.选择一个基类

WPF提供了很多类,当创建一个自定义元素时,你可以从这些类中派生。图9-1显示了一组可能作为类——可能是合适的基类,并且说明了他们之间的继承关系。注意到,这决不是完整的继承关系图,只是简单的显示了一些你应该考虑的可能的基类。

无论你选择了哪一个基类,你的元素都会直接或间接地从FrameworkElement派生。这将提供routing事件,高级属性处理,动画,数据绑定,外观上的支持,样式,以及逻辑树的集成。

派生于FrameworkElement并不是绝对的需要。第7章讨论了底层可视化图形API,虽然该章的示例派生自FrameworkElement,你也可以直接派生于Visual,当使用底层绘图API的时候。然而,如果你这么做了,你将会损失由FrameworkElement提供的全部服务。对派生于底层的元素,你只能在特别专业的环境使用到。

图9-1

直接派生自FrameworkElement,对于一个被设计为组合到其他元素的元素而言,是恰当的。例如,考虑一个绑定到数据源而且生成数据图表的元素。你可能使之派生自Control。尽管如此,未经加工的图形绘制的元素,通常协力于其他元素如TextBlock,从而为这个图形和其轴提供标签。因此,将graph分成图形绘制可能是有意义的,这将合并到一个外观中,包含着任意数量的不同控件。

将一个控件放在另一个控件的模板内部是可行的。但是一旦你发现纯粹是在写一个自定义控件,并放在另一个控件的模板内,你可能需要回顾一下你选择的基类了。

如果你写一个表现自定义外观逻辑的元素,你应该派生于Panel,从而与内嵌外观元素保持一致。

如果你写一个包着另一个元素的元素——在某些方面的增强,要考虑派生于Decorator。很多内嵌元素都是派生于Decorator。例如,Border,在元素的外面添加了一个边框;还有Viewbox,可以自动伸缩被其包着的元素,填充有效的空间。如果你希望提供一种包装器,在内容外添加功能,要考虑派生于Decorator。

如果你的元素提供了行为,或支持用户交互动作——不能使用内嵌组件,这时派生于Control就是恰当的了,以直接或间接的方式。例如,如果你想制作一个交互式的图表组件,用户可以在上面点击图表中的数据项来检查它们,或者放大,这可以被典型地写为一个控件(同时可能要使用你先前写的表现底层图像的元素)。

Control提供了很多派生类,增强了基础控件的功能性。如果你写了一个控件,提供了空白区域,用户可以在上面防止一些内容(如一个标题),你应该派生于ContentControl,这个基类提供了支持内容模型的控件。如果你的控件支持在头标题以及主区域(如分页TabPage)的中的内容,要考虑派生于HeaderedContentControl。

如果你需要表现多个子元素,首先要考虑ListBox和数据绑定以及数据样式的联合是否满足你的需求。数据绑定和样式支持WPF的ListBox处理宽范围的场景,这些都是Win32和Windows Forms的ListBox所不适合的。一旦你需要额外的功能——内嵌的列表控件并不支持,你应该考虑派生于你的自定义元素类型,如Selector或其基类,如ItemControl。ItemControl对包含了列表项的控件提供了基本支持,包括可选的数据绑定功能。Selector增强了跟踪当前一个或一组选项的功能。

时间: 2024-10-12 23:11:11

《Programming WPF》翻译 第9章 2.选择一个基类的相关文章

《Programming WPF》翻译 第9章 5.默认可视化

原文:<Programming WPF>翻译 第9章 5.默认可视化 虽然为控件提供一个自定义外观的能力是有用的,开发者应该能够使用一个控件而不用必须提供自定义可视化.这个控件应该正好工作,当以它最直接的方式使用时.这意味着控件应该提供一组默认的值. 这些默认的可视化存储在组件的二进制资源中,使用的源文件为theme"generic.xaml.如果你在Visual Studio 2005中创建了一个WPF 控件库的工程,这将自动添加这个文件到你的工程中,并且设置它的Build Act

《Programming WPF》翻译 第9章 3.自定义功能

原文:<Programming WPF>翻译 第9章 3.自定义功能 一旦你挑选好一个基类,你将要为你的控件设计一个API.大部分WPF元素提供属性暴露了多数功能,事件,命令,因为他们从框架中获取广泛的支持,以及易于使用XAML.WPF框架对routed event和命令提供了自动支持,它的依赖属性系统提供了数据半岛和动画支持.当然,你也可以写方法--对于某一种功能,方法是最好的途径.(例如,ListBox有一个ScrollIntoView方法,保证了一个特定的项目是可见的.这时从代码中能够做

《python解释器源码剖析》第13章--python虚拟机中的类机制

13.0 序 这一章我们就来看看python中类是怎么实现的,我们知道C不是一个面向对象语言,而python却是一个面向对象的语言,那么在python的底层,是如何使用C来支持python实现面向对象的功能呢?带着这些疑问,我们下面开始剖析python中类的实现机制.另外,在python2中存在着经典类(classic class)和新式类(new style class),但是到Python3中,经典类已经消失了.并且python2官网都快不维护了,因此我们这一章只会介绍新式类. 13.1 p

《Programming WPF》翻译 第8章 2.Timeline

原文:<Programming WPF>翻译 第8章 2.Timeline Timeline代表了时间的延伸.它通常还描述了一个或多个在这段时间所发生的事情.例如,在前面章节描述的动画类型,都是Timeline.可哦率这样的DoubleAnimation: <DoubleAnimation From=”10” To=”300” Duration=”0:0:5” /> 正如Duration属性指出的,这代表了一个5秒的时间长度.所有类型的Timeline总是有一个开始时间和一个持续时

《Programming WPF》翻译 第8章 1.动画基础

原文:<Programming WPF>翻译 第8章 1.动画基础 动画包括在一段时间内改变用户界面的某些可见的特征,如它的大小.位置或颜色.你可以做到这一点,非常困难的通过创建一个timer并在每一个timer_tick句柄中修改用户界面的外观.当然,这是动画在Win32或Windows Forms中典型的做法.幸运的是,WPF照顾到这些低级别的细节.动画,就像WPF中的其他特征,简单的要求我们声明想要做的.系统会为我们照顾它的实现. 所有的WPF动画支持归结为,在一段时间内改变一个或多个属

《Programming WPF》翻译 第6章 4.应用程序全球化

原文:<Programming WPF>翻译 第6章 4.应用程序全球化 如果你打算发布你的应用程序到全球各地,你可能需要为不同地区的用户界面准备不同的版本.至少,这需要解决将文本翻译成适当的语言:同样需要解决UI改变的问题.你可能需要特定的外观适应为本地化的文化习俗.或者,你可能会发现原始的外观在翻译后并不能正常工作,因为词的长度是不一样的.(虽然WPF的外观体系避免了这一问题,更易于创建更弹性的外观.) 为你的软件在不同的市场创建不同的版本是可能的.尽管如此,更加普遍的办法是创建一个单独的

《Programming WPF》翻译 第6章 1.创建和使用资源

原文:<Programming WPF>翻译 第6章 1.创建和使用资源 资源这个词具有非常广泛的意义.任何对象都可以是一个资源.一个在用户界面中经常使用的Brush或者Color可以是一个资源.一段文本或者一个图形也可以是一个资源.没有什么特殊的对象不可以成为一个资源.资源的底层处理机制确保了获取你所需要的资源成为可能,而不闭关心这个资源是什么:同时,这套机制可以简单的识别和定位对象. 资源管理的核心是ResourceDictionary这个类.这是一个相当简单的集合类,就像一个普通的Has

《Programming WPF》翻译 第6章 3.二进制资源

原文:<Programming WPF>翻译 第6章 3.二进制资源 尽管ResourceDictionary和系统级别的资源适合于作为数据存在于对象中,然而,并不是所有的资源都能很好的满足这个模型.能够处理二进制流通常是很有用的.例如,图像,声频和视频,都是有效地二进制的代表,但是这些资源在xaml内都没有相应的标签,而且毕竟这些对象通常表现为底层数据的包装.标记语言本身代表了一种挑战:xaml页面必须编译到我们的应用程序中.因此,需要一种处理二进制流的方法. WPF并未引进任何新技术处理二

《Programming WPF》翻译 第5章 4.元素类型样式

原文:<Programming WPF>翻译 第5章 4.元素类型样式 命名样式非常有用,当你得到一组属性并应用到特点的元素上.然而,如果你想要应用一个统一的样式到所有确定元素类型的实例,设置TargetType而不用一个Key,如示例5-16所示. 示例5-16 <!-- no Key --> <Style TargetType="{x:Type Button}">   <Setter Property="FontSize"