以上就是给各位分享MySilverlight系列，其中也会对10——Silverlight中的InkCanvas进行解释，同时本文还将给你拓展Silverlight5beta新特性探索系列:1.安装S
以上就是给各位分享My Silverlight系列，其中也会对10—— Silverlight中的InkCanvas进行解释，同时本文还将给你拓展Silverlight 5 beta新特性探索系列:1.安装Silverlight 5 beta环境以及OOB模式下Silverlight 5 多窗口支持、Silverlight for Windows Phone 7开发系列（2）：第一个Silverlight程序、silverlight 学习笔记 （三）： silverlight中的数据绑定、Silverlight 确保您的 Silverlight 应用程序能与 Silverlight 4 一起工作等相关知识，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
本文目录一览：- My Silverlight系列（10）—— Silverlight中的InkCanvas（silver of light）
- Silverlight 5 beta新特性探索系列:1.安装Silverlight 5 beta环境以及OOB模式下Silverlight 5 多窗口支持
- Silverlight for Windows Phone 7开发系列（2）：第一个Silverlight程序
- silverlight 学习笔记 （三）： silverlight中的数据绑定
- Silverlight 确保您的 Silverlight 应用程序能与 Silverlight 4 一起工作
My Silverlight系列（10）—— Silverlight中的InkCanvas（silver of light）
有许多人喜欢手写板或者涂鸦板之类的东西，而并不怎么喜欢输入法，因此Microsoft专门有Ink这个东西用于处理鼠标画图。不得不说这个东西功能十分的强大，也让许多用户使用起来非常方便，用微软开发出来的很多Ink与Bitmap结合的API，即使不会用Photoshop的人也能轻松打开一张图片，然后在自己喜欢的地方写上一段话或者签个名什么的。这个功能，Winform上面有，WPF上面也有，当然Silverlight上也有，只不过作为起步不久的Silverlight版Ink，功能尚不够强大，目前能够开放给我们使用的，只有InkPresenter这一个控件。
也许开发WPF的人都没怎么听说过这个控件而只听说过InkCanvas——那是一个在WPF上对Ink功能封装得非常完善的控件，我们可以使用它进行画图和橡皮擦等一系列的事情。当然，如果你去研究过这个控件，你就可以发现其实它其实是通过DataBinding在InkPresenter上进行了进一步的封装。由于WPF与Silverlight不同的继承结构，恐怕在Silverlight上很难照搬WPF上那一套，即我们不能对其进行一对一的Port，所以如果要在Silverlight上实现一个InkCanvas，就要另辟蹊径。
如果你使用过WPF的InkCanvas控件，你将会发现它支持EraseByPoint,EraseBystroke,Ink三种模式，而且支持复制、粘贴，而且可以轻松地扩展出撤销与重做两个功能。但是后面的一系列功能，不是InkCanvas的核心功能，只要前三者得以实现，那么这个InkCanvas就可以正常的运作了。那么，我们首先从这三种模式中用于画图的Ink模式说起。
InkCanvas的核心，其实在于它内部的InkPresenter，在Silverlight中InkPresenter仅仅是Canvas的子类，只不过它多了strokes这么一个属性用于存储和展示画上去的所有stroke。因此，它把如何生成一个stroke的问题完全留给了我们。先来看一下stroke的定义：
其中DrawingAttributes这个属性是用于描述画笔的颜色的，而StylusPoints描述了stroke内点的集合。学过数学的人都知道，线是由点组成的，因此只要我们找到了应该插入到这个stroke中所有的点，那么生成一个新的stroke不在话下。所幸MouseEventArgs中，有一个StylusDevice只读属性，而它的一个公共方法public StylusPointCollection GetStylusPoints(UIElement relativeto)可以在鼠标事件触发的时候，得到这些“点”的集合。我们只需要为InkPresenter加上MouseLeftButtonDown,MouseMove,MouseLeftButtonUp三个handler，那么我们就可以在鼠标进行轨迹上把那些点加到线上，并将这条线加入到InkPresenter这个“面”里。代码比较多，最后我会把工程放在下面，就不一段一段的贴了。
其实这个Ink模式，不算什么难点，而后面这个EraseBystroke也相对简单，最笨的方法就是遍历InkPresenter内所有的stroke，然后一一检验它是否与我们的"Eraser"有交叉，如果有，则将它Remove。但是，最后这个EraseByPoint可没那么容易了，因为当橡皮将一条线拦腰截断的时候，不但要把擦掉的部分去掉，还要把余下的两段保留在strokes这个strokeCollection中，这才能达到一分为二的效果。我最初在实现这个功能的时候，由于设计的算法时间复杂度居高不下，造成如果相交的线过多，或者橡皮拖动太快，就会出现卡死的现象。在与微软silverlight开发小组的stefan swick交流之后，他决定实现这一功能，并且将其做成一个Custom Control。昨天他告诉我他把这个东西做好了，要我去他的Blog上下载。今天我仔细研究了他的算法，发现这个算法与我的算法有一个最大的不同之处就是：我在将一条线一分为二的过程中，完全是按照从前向后的顺序，将每个点一一挎贝并缓存，从前向后判断这个点是否被橡皮擦中，如果被擦中的话，马上生成一个新的stroke，把旧的加入strokes内，并对新的stroke进行上述相同的操作。而stefan的算法则分为了两个部分，首先从前向后把前面没有被擦中的点取出来存到一个新的stroke中，然后停止，再从后往前寻找后面的点，将没有被擦中的点加入到一个新的stroke中，直到遇到被擦中的点停止。这样的话，可以保证一个stroke可以被一分为二。
经过我的测试，执行并没有什么问题。但是由于我们向stroke中插入点，完全依赖于MouseMove事件，如果我们的鼠标移动速度过快，那么被插入的这些本就离散的点，它们之前的间隔会变得更大。这在Ink模式下不会有什么问题，但是在EraseByPoint模式下，就会因被去掉的点附近没有其他的点，而一次性擦掉很大的一段，这是由于我们在插入点和擦除的时候没有做任何的优化造成的，希望这个问题能得到解决。
大家可以到http://blogs.msdn.com/swick/archive/2008/11/30/erasing-ink-in-silverlight-2.aspx去看stefan的原文，那里提供工程原件的下载，我就不再多此一举把它上传到博客园来浪费空间了。至于上面提到的问题，如果大家有什么优化的方式和算法，希望可以告诉我们，谢谢！
Silverlight 5 beta新特性探索系列:1.安装Silverlight 5 beta环境以及OOB模式下Silverlight 5 多窗口支持
Silverlight 5 beta版本总算于昨日放出，怀着激动的心情今天将开发环境更新为Silverlight 5 beta版本，并且接触Silverlight 5 beta的第一个新特性：OOB模式下的多窗口的弹出显示。
现在我们开始Silverlight 5 Beta版本的安装，首先需要为VS2010打一个VS2010 SP1补丁，然后我们再下载Silverlight 5 Beta Tools for Visual Studio SP1，一步一步安装完毕，最后我们下载Silverlight 5 Features Document 新特性的文档。至此我们即可踏上Silverlight 5开发的征程。
对于Silverlight 5 beta版本下面的新窗口的支持是基于OOB模式下的，所以我们首先新建一个Silverlight 5的应用程序，然后右键项目属性-->"允许浏览器外运行应用程序"勾中-->点击"浏览器外设置"-->"在浏览器外运行时需要提升 的信任"勾上。如下图所示：
然后我们在后台代码中键入以下代码即可弹出一个窗口，点击窗口中的按钮我们可以继续弹出窗口，实现了无限制的弹出窗口。当然所有弹出的子窗口都是依赖于父 窗口而存在的。(Tip:在Silverlight 4.0中的Window类修改的大小都是自身窗口的大小，并不能弹出窗口)
- public partial class MainPage : UserControl
- {
- public MainPage()
- {
- InitializeComponent();
- PopWindow(400.0, 20.0, "第"+Flag+"个实例窗口");
- }
- public static int Flag = 0;
- private void PopWindow(double left,double top,string title )
- {
- //设置Window的通用属性
- Window testwindow = new Window();
- testwindow.Height = 400;
- testwindow.Width = 500;
- testwindow.Top = top;
- testwindow.Left = left;
- testwindow.Title = title;
- testwindow.Visibility = Visibility.Visible;
- //添加一个内部有按钮的Canvas，设置Canvas的背景色为白色
- Button btn=new Button();
- btn.Width=80.0;
- btn.Height=30.0;
- btn.Content="点 击";
- btn.Margin = new Thickness(5, top + Flag * 10, 0, 0);
- btn.Click += new RoutedEventHandler(btn_Click);
- Canvas canvas = new Canvas();
- canvas.Children.Add(btn);
- canvas.Background = new SolidColorBrush(Colors.White);
- testwindow.Content = canvas;
- //窗口默认值是WindowState.normal正常情况
- testwindow.WindowState = WindowState.normal;
- //WindowState.Maximized; 窗口最大化
- //WindowState.Minimized; 窗口最小化
- //WindowState.normal; 普通窗口
- void btn_Click(object sender, RoutedEventArgs e)
- {
- PopWindow(400.0, "第"+Flag+"个实例窗口");
- }
- }
本实例采用VS2010 +Silverlight 5 beta制作，如需源码请点击 SL5First.zip 下载。
Silverlight for Windows Phone 7开发系列（2）：第一个Silverlight程序
前言
上一篇讲述了Windows Phone 7开发环境的搭建，这篇文章讲述如何创建，部署，调试以及运行Silverlight for Windows Phone应用程序，同时介绍如何Microsoft Visual Studio 2010 Express for Windows Phone和Windows Phone Emulator（模拟器）的使用。在文章中会建立一个叫做SilverRadio的Silverlight for Windows Phone应用程序，我把这个程序取名为银光收音机，这个程序用于收听网络电台节目。
新 建Silverlight for Windows Phone项目
点 击 Start -> All Programs -> Microsoft Visual Studio 2010 Express -> Microsoft Visual Studio 2010 Express for Windows Phone 。启动Microsoft Visual Studio 2010 Express for Windows Phone
在File菜单下点击New Project。
@H_301_21@ 在New Project对话框下选择Silverlight for Windows Phone模板目录，然后选择Windows Phone Application模板，项目名字取名为SilverRadio，然后点击OK按钮。 @H_301_21@
一个Silverlight for Windows Phone的项目就创建成功了，下面看看Windows Phone Application模板为我们创建了那些文件。
模板生成的文件结构
在Solution Explorer(解决方案浏览器)可以看到Windows Phone Application 模板为SilverRadio项目所创建以下的目录结构和文件。
App.xaml和 App.xaml.cs 定义程序的入口点，初始化应用程序级别的全局静态资源(StaticResource)和启动程序的页面。 Beta版本把一些全局资源的定义从App.xaml移走了，原先可以看到定义的源代码，现在需要参考各个全局静态资源的定义，请参考这篇文章Theme Resources for Windows Phone 。 @H_301_21@MainPage.xaml 和MainPage.xaml.cs 定 义一个UI的页面，通常Silverlight程序的模板会生成一个叫做MainPage.xaml和MainPage.xaml.cs的UI页面作为默 认的启动UI，但是UI启动页面不是必须取MainPage作为名字，使用MainPage只是一个惯例。如果需要修改第一个启动页面可以在 WMAppManifest.xml 修改下面的代码。
< Tasks > < DefaultTask Name = "_default " NavigationPage = "MainPage.xaml "/> </ Tasks >
ApplicationIcon.png 是在 Phone application List显示的图标，例如在下面模拟器显示SilverRadio的图标。
Background.png 用于start screen（启动屏幕）显示的图标 @H_301_21@SplashScreenImage.jpg 当程序启动之后，在第一个页面启动之前显示的图片。
Properties/AppManifest.xml 用于定义程序打包文件(manifest)。 Silverlight程序最终会打成XAP包，这个XAP包是zip格式的文件，里面包含了程序需要用到的所有资源（例如图片，声音文件等等），和依赖 的第三方DLL等等。AppManifest.xml文件用于定义打包的结构， 下图为生成的xap的。
如果把SilverRadio.xap文件改 名为SilverRadio.zip，然后解压，能看到程序发布时候所有的文件，这些文件的结构由AppManifest.xml来进行定义。
Properties/AssemblyInfo.cs 包含版本信息等源数据(Metadata)，这个文件与ASP.NET,Winform程序中的AssemblyInfo.cs文件功能一致。
Properties/WMAppManifest.xml 与AppManifest.xml一样也是用来定义程序的打包文件，但是WMAppManifest.xml专门指定Windows Phone Silverlight应用程序相关的源数据(Metadata)，例如上述的启动页面MainPage.xaml的定义包含在 WMAppManifest.xml里面。
一般来说不要手工修改WMAppManifest.xml和AppManifest.xml 文件，可以通过项目属性文件来修改。如下图：
右键选择项目的属性。
修改的属性会保持到 WMAppManifest.xml和AppManifest.xml文件里面。
References 文件夹 显 示一些依赖的DLL等相关资源，由于Windows Phone Beta版把多个DLL合并到Microsoft.Phone.dll一个里面，所以项目包含了Microsoft.Phone.dll和 Microsoft.Phone.Interop.dll两个Windows Phone相关的DLL（CTP版本包含更多其它DLL），如果需要使用到其他DLL，例如在我们系列教材中会使用到LINQ for XML，那么会把System.Xml.Linq.DLL增加到References文件夹里面。
silverlight 学习笔记 （三）： silverlight中的数据绑定
在前面的笔记中讲过了在silverlight中作为UI层只负责界面的展示，而与viewmodel的联系是通过绑定方式，其绑定可以是数据的绑定也可以是事件的绑定。那么我们需要了解下究竟在UI中绑定的实现。
一、绑定语法
绑定可以在设计时绑定也可以在后台绑定，通常我们在设计时进行绑定，数据绑定语法是： 属性=“{Binding 类属性,Mode=绑定方式}”，如下：
当然在silverlight中除了与实体类的属性绑定外还支持元素间属性的绑定，即一个控件的属性绑定另一个控件的属性如：<TextBlock Text="{Binding Text.Length,ElementName=txUserid}" />
二、绑定方式
在Silverlight ，支持OneTime、OneWay、TwoWay三种形式的数据绑定。
简单的说：OneTime模式下：控件与数据绑定后，能自动显示数据，一旦显示完成后，这二者就没有任何关联了。(即自动解除绑定)
OneWay模式下：控件与数据绑定后，除自动显示数据外，显示完成后，控件与数据源仍有单向关联，即如果数据源以后发生了变化，控件上的值也会自动变化.
TwoWay模式下：控件与数据源的关联是双向的，即数据源的变化会影响控件上的值，反过来控件上的任何值变化也会影响数据源本身发生变化。
实际开发中，我们的数据源通常不会是某一个现成控件的属性，多半是xml/数据库等对应的实体类，这里要注意的是，如果控件与自定义类绑定， 自定义类必须实现INotifyPropertyChanged接口
在MVVM模式中由于View从viewmodel中提取数据所以viewmodel类必须从INotifyPropertyChanged接口继承而来，通常viewmodel中会定义一个或多个Model类的实体公布给View，所以Model类也将从INotifyPropertyChanged接口继承。这样才能保障数据源的变化与UI控件上值的变化进行及时更新。
需要提醒的是在silverlight中的UI的更新是在控件失去焦点后发生的。
三、事件绑定
在silverlight中除了能将UI控件中的属性进行数据绑定外，还可以将UI控件中的事件进行绑定。在MVVM模式中，viewmodel将会向View暴露所有Vew要用到的事件属性，而这些事件属性都将继承ICommand接口。其实现方式如下：
1、在viewmodel中公布事件属性
3、定义事件处理函数
4、在UI中定义事件绑定
Silverlight 确保您的 Silverlight 应用程序能与 Silverlight 4 一起工作
Silverlight 确保您的 Silverlight 应用程序能与 Silverlight 4 一起工作 在 Silverlight 3 和 Silverlight 4 之间，针对 Silverlight 运行时和 Silverlight 工具做出了一些更改。对于这些更改，以下原则适用： * 无需任何更改，多数 Silverlight 3 应用程序都可与 Silverlight 4 一起使用。 * 要求重大更改时，Silverlight 将通过使用“突发模式”尽量同时保持对旧行为和新行为的支持。 即便如此，对 Silverlight 组件所做的某些更改仍可能导致旧的基于 Silverlight 的应用程序失败（在编译时、XAML 加载时或可能在设计时）或操作异常。 本主题介绍在 Silverlight 3 和 Silverlight 4 之间所做的更改。本主题不介绍 Silverlight 4 的新功能或增强功能。有关 Silverlight 4 中的新增功能的信息，请参见 Silverlight 4 中的新增功能。 注意说明： 有关对本主题的更正和增补，请参见 Silverlight SDK blog（Silverlight SDK 博客）。 本主题包含以下各节： * XAML 分析器更改 本节介绍 Silverlight 4 中的 XAML 分析器更改。 * 自 Silverlight 3 以来的重大更改 本节中介绍的更改可能会破坏用户在 Silverlight 4 运行时上运行的为 Silverlight 3 编写的应用程序，即便应用程序清单的目标为 Silverlight 3 也是如此。 * 突发模式行为 本节介绍运行时或其 API 中的哪些部分包括特定于版本的行为差异。这些行为差异基于应用程序的目标运行时版本。这些更改往往代表针对 Silverlight 4 的错误修复，但 Silverlight 3 行为作为特定的突发模式仍然可以访问，仅在应用程序的目标是 Silverlight 3 运行时的情况下才可以使用突发模式。在应用程序的逻辑依赖于 Silverlight 3 行为时才这样做。 * 升级重大更改 本节介绍在您重新编译 Silverlight 3 应用程序并准备面向 Silverlight 4 时涉及的相关更改。 * 自 Silverlight 4 Beta 以来的重大更改 本节介绍专门为 Silverlight 4 Beta（Silverlight 运行时的最新公开发布版本）编译的应用程序才会涉及的相关更改。没有可用于 Silverlight 4 Beta 运行时行为的突发模式。 XAML 分析器更改 Silverlight 4 引入了更新的 XAML 分析器。同时为保持兼容性，Silverlight 4 运行时还保留了原始 Silverlight 3 XAML 分析器，并用它来分析面向 Silverlight 3 的任何应用程序的 XAML。这意味着如果您继续以 Silverlight 3 为目标，对 Silverlight 3 有效的任何原始 XAML 行为仍将有效，只要该 XAML 行为与“升级重大更改”一节中所列的特定重大更改没有冲突。其实际效果与用于 XAML 加载的突发模式相似。 如果将以前面向 Silverlight 3 的 Silverlight 项目升级为现在面向 Silverlight 4，则可能需要更改您的 XAML。如果要升级 Silverlight 4 Beta 项目，则可能需要更改您的 XAML。Silverlight 4 Beta XAML 分析器行为与 Silverlight 3 XAML 分析器行为大体相同。 影响您应用程序的 XAML 的 XAML 行为差异涉及面太广，无法在此一一列出，改为在其他主题中介绍。有关更多信息，请参见 Silverlight 3 和 Silverlight 4 之间的 XAML 处理差异或 Silverlight 版本和 WPF 之间的 XAML 处理差异。 自 Silverlight 3 以来的重大更改 本节介绍的更改可能会破坏 Silverlight 3 应用程序。其中许多更改实际上是错误修复。 不过，如果您的 Silverlight 3 应用程序已经针对这些错误添加了解决方法，您可能不得不取消这些解决方法，这样在 Silverlight 4 运行时上运行时，您的应用程序才能正常工作。 当应用程序属性与新的 Silverlight 4 属性冲突时，出现 XAML 分析 AmbiguousMatchException 如果您在 XAML 中设置属性且两个不同的属性具有相同的简单名称，Silverlight XAML 分析器（特别是处理兼容性的并行 XAML 分析器）将引发 AmbiguousMatchException。如果一个属性名称匹配候选者是基类的成员，另一个候选者是派生类的成员，就可能引发异常。在根据 Silverlight 3 内核生成应用程序时，可能只存在应用程序定义的属性。但是，如果高版本的 Silverlight（如 Silverlight 4）添加具有相同简单名称的属性且该属性在通过新基类定义继承的内核运行时成员定义中存在，则该属性名称现在对于 XAML 分析器有歧义。 例如，Silverlight 3 应用程序可能从 TextBox 派生并针对自定义类声明名为 Watermark 的 XAML 可访问的新属性。在 Silverlight 3 中，TextBox 不具有名为 Watermark 的属性，因此在 Silverlight 3 中应用程序进行 XAML 分析时不会出现名称歧义。但是，TextBox 的 Silverlight 4 内核库定义引入了名为 Watermark 的属性，因此在根据 Silverlight 4 内核运行时执行时，简单属性名称的 Silverlight 3 XAML 查找进程现在有歧义。 此问题只影响 XAML 使用；在这种情况下使用代码中的属性没有歧义。仅当两个属性定义类型之间存在子类/超类关系时，才存在此问题。例如，MyButton.Watermark 属性不会有问题，因为 MyButton 不是 TextBox 的子类。 此问题只影响基于 Silverlight 2 和 Silverlight 3 生成的应用程序。Silverlight 4 应用程序使用新的 XAML 分析器，该分析器可以解决此类名称歧义的问题。真正的 Silverlight 3 运行时中存在同样的 XAML 分析器问题。如果 Silverlight 2 应用程序定义并使用在 Silverlight 3 中添加的属性名称，将出现 AmbiguousMatchException。 以下章节列出在 Silverlight 4 中添加到通用基类（DependencyObject、UIElement、FrameworkElement、Control 和 System.Windows.dll 中的 Control 子类）的属性。每个属性表示是子类中名称歧义候选者的属性名称。 * FrameworkElement.FlowDirection * FrameworkElement.Unloaded * 拖放 API（AllowDrop、dragenter、DragLeave、DragOver、Drop） * 操作 API（ManipulationCompleted、ManipulationDelta、ManipulationStarted） * UIElement.MouseRightButtonDown,UIElement.MouseRightButtonUp * IME API（TextInput、TextInputStart、TextInputUpdate） * 其他文本控件 API（几个与文本相关的类型的 BaselineOffset、TextBox.InputScope、TextBox.Watermark、ButtonBase.Command、ButtonBase.CommandParameter） * Selector.SelectedValue,Selector.SelectedValuePath 遇到此问题的应用程序必须使用 Silverlight 4 重新编译和生成目标文件；重新编译后的应用程序使用新的 XAML 分析器，可以正确解析。 切换全屏模式现在将重新运行命中测试 切换全屏模式现在将重新运行命中测试。这样做是为了允许在切换之前处于鼠标之下的控件更新其 MouSEOver 状态。 在切换全屏模式时，鼠标指针很可能因 Silverlight 插件大小的更改“跳转”到其他位置。在退出全屏模式时，鼠标指针可能位于插件之外。在以往，不会发出鼠标消息以通知控件鼠标指针不再位于这些控件上方。现在，在切换全屏模式后完成布局时，将引发鼠标事件以重新运行命中测试，并允许控件按需更改状态。 有关更多信息，请参见全屏支持。 更改 ItemControl 的 displayMemberPath 和 ItemTemplate 属性现在将重新创建所有容器 在 Silverlight 3 中，设置项模板的 ItemTemplate 和 displayMemberPath 属性（如在下面的代码中）在完成 ListBox 测量后没有任何效果。 XAML 复制 <ListBox x:Name="lb" ItemTemplate="{StaticResource lbItem}"> VB C# C++ F# JScript 复制 lb.ItemTemplate = lbItemTemplate; lb.displayMemberPath = itemdisplayPath; 在 Silverlight 4 中，此代码将使所有已实现的容器无效，并重新创建它们，即便是在测量完容器后。 共享的 BitmapImage 源 当两个 BitmapImage 控件共享同一 BitmapImage 源，并且二者均未显式设置 Width/Height（均使用自然大小），第二个 Image 不在 Silverlight 3 中呈现其 BitmapImage。此行为在 Silverlight 4 中已纠正，现在两个 Image 控件均应正确呈现其内容。 IronPython 2.0.2 和更早版本 Silverlight 4 不能与 IronPython 的早期版本一同工作，请升级为 IronPython 2.0.3 或更高版本，这些版本可通过 http://ironpython.codeplex.com/ 来下载。 Microsoft.Jscript.Compiler.dll / Microsoft.Jscript.Runtime.dll Silverlight 4 不能与 Microsoft.Jscript.Compiler.dll / Microsoft.Jscript.Runtime.dll（亦称“DLR Jscript”，有时也称为“托管 Jscript”）一同工作。最近发布的试用 DLR Jscript 是作为 Dynamic Languages SDK 0.4.0 Alpha 的一部分发布的。此功能因不能完全发挥作用已被取消，不再使用。有关详细信息，请参见 http://dlr.codeplex.com/Thread/View.aspx?ThreadId=58121。（不应将 DLR Jscript 与更常用的基于浏览器的 Silverlight 的 JavaScript API 相混淆，后者一直有效） DRM 和操作系统位于 fat32 分区的客户端 在 Silverlight 3 中，DRM 可以在操作系统安装在 fat32 驱动器或分区的客户端系统上正常工作。（对于特意不使用安装或操作系统转换默认设置的少量 Windows XP 操作系统存在这种情况。） 在 Silverlight 4 中，DRM 功能在操作系统安装在 fat32 驱动器或分区的客户端系统上不能正常工作。 建议的用户解决方法是转换到 NTFS。请参见 http://support.microsoft.com/kb/314097/。 突发模式更改 Silverlight 团队曾想要在 Silverlight 4 中修复若干 Silverlight 3 错误。但在修复其中一些错误后，某些现有的 Silverlight 3 应用程序可能会被破坏。为了避免此问题，Silverlight 团队通过为运行时行为创建“突发模式”来解决这些可能产生问题的更改。突发模式更改是这样一种更改：如果 Silverlight 4 运行时检测到应用程序面向 Silverlight 3，该运行时将使其行为产生分支。这样，Silverlight 4 将成为“错误兼容的”运行时。但是，如果您面向 Silverlight 4 重新编译应用程序，则可能需要重新检查所指出的突发模式行为。 如果您的应用程序的 RuntimeVersion 指定 Silverlight 3，则运行时将在突发模式下运行。处于突发模式下时，运行时回退到与突发模式更改关联的 Silverlight 3 行为，并在这些情况下始终这样操作，就像该运行时实际上是未升级的 Silverlight 3 运行时一样。 Silverlight 4 运行时通过使用 RuntimeVersion 检测应用程序是否是为 Silverlight 3 设计的。RuntimeVersion 设置为 XAP 文件的 AppManifest.xaml 中的属性： 复制 <Deployment xmlns="http://schemas.microsoft.com/client/2007/deployment" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" EntryPointAssembly="ElevatorSilverlight" EntryPointType="ElevatorSilverlight.App" RuntimeVersion="3.0.31005.0"> <Deployment.Parts> <AssemblyPart x:Name="ElevatorSilverlight" Source="ElevatorSilverlight.dll" /> </Deployment.Parts> </Deployment> RuntimeVersion 反映在编译应用程序时位于开发人员计算机上的 Silverlight 的内部版本号。 如果使用 Silverlight 4 工具编译您的应用程序并且将目标专门设定为 Silverlight 3，您就潜在地调用了突发模式，就像是使用 Silverlight 3 工具编译了应用程序一样。 范围和容器中的正确空白处理 Silverlight 3 中的 TextBlock（以及 Silverlight 4 Beta 中的 RichTextArea）��� <Span> 或 <Run> 部分中存在错误，此时 XAML 中的空白（通常用于格式设置）实际上用作内容。这有时会要求限制在 XAML 源中使用换行符，导致 XAML 的可读性较差。此行为对于 Silverlight 3 是突发的，作为 Silverlight 3 和 Silverlight 4 之间的 XAML 处理差异中所述更大 XAML 分析器行为的一部分。 Silverlight 4 中的文本容器接受文本内容，并在对象模型中为任何“innertext”文本内容创建隐式文本运行。这样才能在由 CRLF 分隔的文本元素之间生成空白。例如： 复制 <Run>Some</Run> <Run>Text</Run> 转换为： 复制 <Run>Some</Run><Run> </Run><Run>Text</Run> Silverlight 4 中放宽了裁剪前导和尾随空白的条件。以往的行为会裁剪隐式 Run 元素的前导空白，除非 Run 的前面有一个显式 Run。Silverlight 4 行为会裁剪前导空白，除非隐式 Run 的前面有一个并非 Run 的显式文本元素（例如：Span、InlineUIContainer、Hyperlink）或有一个显式 Run。 面板的 Clear 方法现在调用 InvalidateMeasure 在 Silverlight 4 中，当调用 Panel 项集合的 Clear 方法时，现在会引发针对 InvalidateMeasure 的调用。这将在下一个计时周期开始时触发布局。在 Silverlight 3 中，调用 Clear 仍将对 Panel 布局没有任何影响。 VirtualizingStackPanel.MouseWheelUp 和 VirtualizingStackPanel.MouseWheelDown 现在滚动三行 在 Silverlight 3 已编译应用程序中，MouseWheelUp 和 MouseWheelDown 方法仍将滚动一行。但是在 Silverlight 4 应用程序中，这些方法将滚动三行。 ImageBrush.ImageSource 现在返回 ImageSource 对象而不是 UriSource 在 Silverlight 3 应用程序中，ImageBrush.ImageSource 返回其 ImageSource 的 UriSource（字符串）。这与 Silverlight 1.0 中的最初 JavaScript 行为是相同的。 在 Silverlight 4 中，将返回实际 ImageSource 对象，该对象可以是 WriteableBitmap 或 BitmapImage。 在动画期间更改基值现在可发挥预期作用 在 Silverlight 3 中，如果在某个活动的动画中间对某个属性调用了 SetValue，结果仅适用于该计时周期。SetValue 将正确地更改该值，但是在活动动画的下一计时周期，该动画将覆盖设置的值。这种情况看上去常常就像什么都没有发生（对新值的更改太快，使用户难以觉察）。SetValue 调用并不更改动画的基值（GetAnimationBaseValue 的结果）。停止动画时，基值将返回给在开始动画之前属性所具有的值，忽略 SetValue。 在 Silverlight 4 中，如果在活动动画的中间发生属性值更改，SetValue 调用将修改动画的基值。停止动画时，该动画将使用新的基值。这与 WPF 中的行为相同。（请注意，HoldEnd 动画不一定受此更改影响）。 当动画有效时 ReadLocalValue 返回本地值 在 Silverlight 3 中，对属性进行动画处理并且动画正在运行时，针对 ReadLocalValue 的调用将返回经过动画处理的值。 在 Silverlight 4 中，针对 ReadLocalValue 的调用将返回本地值。这与 WPF 中的行为相同。如果需要经过动画处理的值，请调用 GetValue。 在样式中的重复 setter 全部引用同一附加属性时，不会调用这些 setter 在 Silverlight 3 中，可以使用多个 Style Setter 对同一附加属性设置两次。特定的方案会用到此特性。 在 Silverlight 4 中，不再支持此行为。在 Setters 中两次设置同一附加属性并不属于语法错误。但是，只有最后一个引用附加属性的 Setter 才会被 Silverlight 样式子系统实际调用，任何其他 setter 的结果都是无操作 (no-op)。此行为与 WPF 行为相同。 浏览器缩放和 Content.Resized 在 Silverlight 4 中，如果应用程序与 Resized 事件挂钩，Silverlight 内容区域的视图将在浏览器缩放级别更改时自动缩放。如果 Silverlight 4 应用程序要禁用自动浏览器缩放，该应用程序必须将 EnableAutoZoom 属性显式设置为 false。 Silverlight 3 认定侦听 Resized 的应用程序自己会处理浏览器缩放，所以禁用自动浏览器缩放。因此，如果应用程序面向 Silverlight 3，则突发模式行为是：没有任何缩放行为与 Resized 关联。 MEF API 更改 以下是对 Silverlight MEF 组件（System.ComponentModel.Composition 程序集和相关组件）中存在的托管扩展框架 (MEF) API 的特定更改： * PartCreator<T> 已重命名为 ExportFactory<T>，移到 System.ComponentModel.Composition.Initialization.dll * Partinitializer 已重命名为CompositionInitializer * CompositionHost.InitializeContainer 已重命名为CompositionHost.Initialize * PackageCatalog 已替换为DeploymentCatalog 字符串比较和 CultureInfo String 和 Char 类的某些字符串比较 API 对于如何获取有效 CultureInfo 使用不同的逻辑，具体取决于应用程序在 Silverlight 3 还是 Silverlight 4 上运行。这仅适用于重载未传递特定 CultureInfo 的情况。该行为是突发的，因此 Silverlight 3 应用程序不必纠正它。下表列出了 API 差异： API Silverlight 3 Silverlight 4 EndsWith Ordinal CurrentCulture IndexOf Ordinal CurrentCulture LastIndexOf Ordinal CurrentCulture StartsWith Ordinal CurrentCulture ToLower InvariantCulture CurrentCulture toupper InvariantCulture CurrentCulture ToLower InvariantCulture CurrentCulture toupper InvariantCulture CurrentCulture 从 IList、IList<T> 填充 ItemsControl 在 Silverlight 3 中，如果使用 IList 或 IList<T> 填充 ItemsControl，系统使用枚举器执行填充。在 Silverlight 4 中，系统使用专用索引器（和 Count）执行填充。 升级重大更改 如果将项目升级为面向 Silverlight 4 运行时，则往往需要先解决此类别中所列的问题，然后才能重新编译您的应用程序。您可能还需要重新检查您的应用程序逻辑，该逻辑可能一直依赖突发模式行为。 有关更多信息，请参见上文中的“突发模式更改”一节。 项目更改 如果将以前面向 Silverlight 3 的 Silverlight 项目升级为专门面向 Silverlight 4，则可能需要对项目结构进行某些更改。还可能需要对该项目所用的文件和资源进行更改。在某些情况下，这是因为某些行为允许作为 Silverlight 3 突发行为，但在改为面向 Silverlight 4 后不再允许这样做。 一些类型已从 Silverlight SDK 移至核心运行时 以下类型已从 Silverlight SDK 移至核心运行时： * System.ComponentModel.IEditableCollectionView * System.ComponentModel.NewItemPlaceholderPosition * System.Windows.Data.CollectionViewGroup * System.Windows.Data.PropertyGroupDescription 旧程序集：System.Windows.Data.dll 新程序集：System.Windows.dll 现有的 Silverlight 3 应用程序应该能照常工作，因为 System.Windows.Data.dll 客户端程序集通常在 XAP 文件中分发。 如果使用 Silverlight 4 工具编译您的应用程序，使其面向 Silverlight 4，该应用程序将使用核心运行时库中的类。 而且，在 Silverlight 4 Beta 和 Silverlight 4 之间，System.Windows.Navigation 命名空间中的某些（不是全部）API 已从 System.Windows.Controls.Navigation.dll 移到内核 System.Windows.dll。现在位于 System.Windows 中的 API 有：NavigatedEventHandler、NavigatingCancelEventArgs、NavigatingCancelEventHandler、NavigationEventArgs、NavigationMode。 修复了 TabControl 键盘导航 Silverlight 3 在 TabControl 的键盘导航模式中，按上箭头键激活的是下一个 TabItem，按下箭头键激活的是上一个 TabItem。这在 TabStripPlacement 设置为 Left 或 Right 时将导致与直观行为相悖的行为。在这种情况下，按上箭头键激活的是当前活动的 TabItem 之下的 TabItem，按下箭头键激活的是当前活动的 TabItem 之上的 TabItem。此行为仍存在于 Silverlight 3 应用程序中；TabControl 位于 System.Windows.Controls.dll 程序集中，该程序集是一个客户端库，经常打包到 XAP 文件中。 Silverlight 4 在 Silverlight 4 中按上箭头键激活的是上一个 TabItem（即：当 TabStripPlacement 设置为 Left 或 Right 时，垂直布局模式中的当前活动 TabItem 之上的项）。按下箭头键激活的是下一个 TabItem（垂直布局模式中的当前活动 TabItem 之下的项）。如果引用或分发 Silverlight 4 System.Windows.Controls.dll 程序集，则这是更新的行为。 控件现在具有内置的鼠标滚轮支持 在 Silverlight 4 中，以下控件现在具有内置的 MouseWheel 事件支持： * ListBox * TextBox * ComboBox * ScrollViewer * Calendar * DatePicker * DataGrid 在 Silverlight 3 中，没有内置的 MouseWheel 支持。 如果将应用程序从 Silverlight 3 升级到 Silverlight 4，您可能要删除以前所有的应用程序级别的特定鼠标滚轮事件处理，有可能需要在 HTML DOM 中删除。这可能适用于以下任意控件：ListBox、TextBox、ComboBox 和 ScrollViewer。有关更多信息，请参见鼠标轮输入。 注意说明： 还有一些具有 MouseWheel 支持的控件未在此处列出，因为它们不存在于 Silverlight 3 中。一个示例是 RichTextBox。检查各个控件引用页，看是否存在有关 MouseWheel 处理的 OnMouseWheel 重写或其他备注。 DataGrid 中的货币更改时的 DataGridCell 对象和自动化焦点 当 DataGrid 中的货币更改时，Silverlight 4 中的 DataGridCell 对象接收自动化焦点，焦点不再保留在 DataGrid 本身上。 一些详细信息：UI 自动化客户端原先不获取有关当前具有焦点的单元格的信息，因为 DataGridCell 对象不是可获得焦点的控件（尝试的 Focus 返回 false）。这一点没有变化。DataGridCell 对象在 UI 中仍不可获得焦点。但是，对于 Silverlight 4，这些对象将在 DataGrid 货币更改时接收“自动化焦点”。现在当您按 Tab 键进入 DataGrid 并使用箭头键更改货币时，自动化焦点将移至各个单元格同级，以便 UI 自动化客户端能够接收这些单元格的特定自动化属性信息。以前，自动化焦点保留在 DataGrid 上；它基于 Silverlight 3 System.Windows.Controls.Data.dll 作为 Silverlight 3 行为保留。 System.ServiceModel.PollingDuplex.dll 程序集已重构 如果此前引用过 System.ServiceModel.PollingDuplex.dll 程序集，在将项目升级到 Silverlight 4 之后，您必须手动添加对 System.ServiceModel.Extensions.dll 扩展程序集的引用。最初的程序集已被重构，有些类已移至新程序集。 自 Silverlight 4 Beta 以来的重大更改 如果您创建了 Silverlight 4 Beta 应用程序，Silverlight 4 Beta 与 Silverlight 4 之间存在一些重大更改，下面各节将对此进行介绍。 RichTextArea 已重���名为 RichTextBox RichTextArea 已重命名为 RichTextBox。CLR 命名空间和程序集位置保持不变。 针对 DRM API 的更改 自 Silverlight 4 Beta 以来更改了一些与 DRM 相关的 API。 以前 复制 public class DomainAcquirer { public void DomainJoinAsyncCancel(); public void DomainLeaveAsyncCancel(); public event EventHandler<DomainoperationCompletedEventArgs> DomainoperationCompleted; } public class LicenseAcquirer { public void AcquireLicenseAsyncCancel(); public string CustomData; } public class MediaLicense { public DateTime ExpirationDate; } public enum ContentKeyType { AES128Bit, Cocktail } 之后 复制 public class DomainAcquirer { public void CancelAsync(); public event EventHandler<DomainJoinCompletedEventArgs> DomainJoinCompleted; public event EventHandler<DomainLeaveCompletedEventArgs> DomainLeaveCompleted; } public class LicenseAcquirer { public void CancelAsync(); public string ChallengeCustomData; } public class MediaLicense { public Nullable<DateTimeOffset> ExpirationDate; } public enum ContentKeyType { Aes128Bit, Cocktail } TextSelection.SetPropertyValue 已重命名为 TextSelection.ApplyPropertyValue 如果您的代码关联到 RichTextArea/RichTextBox（使用 TextSelection.SetPropertyValue 设置选定文本的格式），您必须将此代码改为调用 TextSelection.ApplyPropertyValue。 INotifyDataErrorInfo 和 DataErrorsChangedEventArgs 移至 System.Windows.dll Silverlight 4 Beta 中添加了 INotifyDataErrorInfo 和 DataErrorsChangedEventArgs。这些类型在 Silverlight 4 中已从 System.dll 移至 System.Windows.dll。如果您使用这些类型，则必须重新编译您的项目，并且可能需要调整您的引用程序集。 Webbrowser.ScriptNotify 签名更改 复制 public event NotifyEventHandler ScriptNotify; 更改为： 复制 public event EventHandler<NotifyEventArgs> ScriptNotify; 而且，Webbrowser.LoadCompleted 现在使用更具体的委托：LoadCompletedEventHandler。您可以继续使用 EventHandler，您的应用程序仍将编译，但是应用程序可能要升级以接收 NavigationEventArgs 事件数据。 NotificationWindow API 更改 在 NotificationWindow API 中： 复制 public bool Visible { get; } public event EventHandler<EventArgs> Closed; 更改为： 复制 public Visibility Visibility { get; } public event EventHandler Closed; 网络摄像机和输出保护 API 的更改 存在一些与网络摄像机和输出保护相关的 API 更改。 * 针对音频/视频捕获设备的集合以及支持的格式现在返回 ReadOnlyCollection<T> 格式的不可变的集合。这将影响对 GetAvailableAudioCaptureDevices、GetAvailableVideoCaptureDevices 或 VideoCaptureDevice 方法的所有调用。 * Connectors 重命名为 VideoOutputConnectors 且返回的集合不可变：ReadOnlyCollection<VideoOutputConnector>。 * 若干枚举的大小写已更改： 复制 VGA -> Vga DVI -> Dvi HDMI -> Hdmi LVDS -> Lvds SDI -> Sdi UDIExternal -> UdiExternal UDIInternal -> UdiInternal * CanEnablehdcp 重命名为 CanEnablehdcp，CanEnableCGMSA 重命名为 CanEnableCgmsa。 * VideoFormat.Height 重命名为 VideoFormat.PixelHeight。VideoFormat.Width 重命名为 VideoFormat.PixelWidth。 * WaveFormatType.PCM 重命名为 WaveFormatType.Pcm。 * ContentKeyType.AES128Bit 重命名为 ContentKeyType.Aes128Bit。 * AsyncCaptureImage 的使用模式已更新为基于标准 .NET 事件的异步模式。在 Silverlight 4 中，您调用 CaptureImageAsync 并且处理 CaptureImageCompleted。所需的图像是事件数据的 Result 值，且和以前一样是一个 WriteableBitmap。 复制 // Old usage void CallbackFunc(WriteableBitmap img) { //... } myCaptureSource.AsyncCaptureImage(CallbackFunc); // New usage. void CallbackFunc(object sender,CaptureImageCompletedEventArgs args) {//...} myCaptureSource.ImageCaptureCompleted += CallbackFunc; myCaptureSource.ImageCaptureAsync(); COM 互操作 API 更改 用于 Silverlight 4 中的 COM 互操作的类型已移至新的命名空间，并且类型名称已更改。 复制 namespace System.Windows.Interop { public sealed class ComAutomationEvent public sealed class ComAutomationEventArgs : EventArgs public delegate void ComAutomationEventHandler(object sender,ComAutomationEventArgs e) public static class ComAutomationFactory } 更改为： 复制 namespace System.Runtime.InteropServices.Automation { public sealed class AutomationEvent public sealed class AutomationEventArgs : EventArgs public static class AutomationFactory } RichTextBox.textwrapping 默认值现已设置为 Wrap 对于 Silverlight 4，textwrapping 的默认值为 textwrapping.Wrap。以前的默认值为 textwrapping.Nowrap。 在 XAML 中设置 Binding 且目标为 DependencyObject 时的行为更改 在 Silverlight 4 中，在 XAML 中对 DependencyObject 的依赖项属性设置的绑定将向这些属性附加一个 BindingExpression 而不是设置 Binding 对象。 在 Silverlight 3 中，绑定目标必须是一个 FrameworkElement，所以不会出现上述情况。在 Silverlight 4 Beta 中添加了对任何 DependencyObject 依赖项属性的绑定。 如果存在以下任何情况，则您不会受到此更改的影响： * 应用程序面向 Silverlight 3 编译或以此为目标。 * 目标对象是一个 FrameworkElement（在与 UI 相关的绑定中使用的多数对象都是 FrameworkElement 派生类） * 目标属性是 CLR 属性而不是依赖项属性 在这一更改前： 复制 <local:MyDependencyObject MyProperty="{Binding MyItem}" /> 这将 MyProperty 设置为具有路径 MyItem 的 Binding 对象。 在这一更改后： 复制 <local:MyDependencyObject MyProperty="{Binding MyItem}" /> 这会将 BindingExpression 附加到侦听路径 MyItem 的 MyProperty（类似调用 SetBinding）。想要设置 Binding 对象的行为的 Silverlight 4 应用程序应将目标属性设置为 CLR 属性而不是 DependencyProperty。这与 FrameworkElement 行为是一致的。 HtmlBrush 已重命名为 WebbrowserBrush 将针对 HtmlBrush 的所有引用更改为 WebbrowserBrush。CLR 命名空间和程序集位置保持不变。 ListBoxItem 可视状态已重命名 ListBoxItem 已对它的两个指定可视状态进行重命名。 * Silverlight 4 Beta 中的 Loaded 可视状态现在名为 AfterLoaded * Silverlight 4 Beta 中的 Unloaded 可视状态现在名为 BeforeUnloaded 如果您已经为包括这些可视状态的项控件编写模板，则此更改对您有影响。应该更改这些模板，以使用新的状态名称。如果您编写的 visualstatemanager 逻辑使用 ItemsControl 中定义的状态名称，则此更改也可能对您有影响。 新状态名称反映在针对 ListBoxItem 类型的 CLR 特性中。相关状态在 Silverlight 3 ListBoxItem 中不存在。 不支持样式 Setter 中的绑定 在 Silverlight 4 Beta 中，样式 setter 中的绑定（Setter.Property 值）在语法上是允许的（尽管与等效的 WPF 用法相比，这些绑定不能发挥预期作用）。 在 Silverlight 4 中，样式 setter 中的绑定现已在语法级别上禁用。在 Silverlight 3 中也同样禁用。 CultureNotFoundException API 更改 以下 API 存在于 Silverlight 4 Beta 的 CultureNotFoundException 中，但是已从 Silverlight 4 中删除： 复制 public CultureNotFoundException(string message,int invalidCultureId,Exception innerException); public CultureNotFoundException(string paramName,string message); public virtual Nullable`1<int> InvalidCultureId { get; } Contract.ContractFailed API 更改 System.Diagnostics.Contracts.Contract.ContractFailed 存在于 Silverlight 4 Beta 中，但是已从 Silverlight 4 中删除。还删除了 ContractFailedEventArgs。 Action 和 Func (T5+) API 更改 .NET Framework 包含几个 Action 和 Func 委托的元数。这个重大更改专门影响具有至少 5 个输入参数（T5 的参数名称存在）的 Silverlight Action 和 Func 委托，这些委托对于 .NET Framework 4 也是新的。所有这些委托在 Silverlight 4 Beta 和 4 RC 中以前都位于程序集 System.Core 中。现在它们已移到 mscorlib 中。如果在 Beta/RC 中使用了这些委托，必须使用 Silverlight 4 RTM 位重新编译。 请参见 任务 如何创建新 Silverlight 项目 概念 Silverlight 的 JavaScript API XAML 概述 其他资源 Silverlight 4 中的新增功能
我们今天的关于My Silverlight系列和10—— Silverlight中的InkCanvas的分享就到这里，谢谢您的阅读，如果想了解更多关于Silverlight 5 beta新特性探索系列:1.安装Silverlight 5 beta环境以及OOB模式下Silverlight 5 多窗口支持、Silverlight for Windows Phone 7开发系列（2）：第一个Silverlight程序、silverlight 学习笔记 （三）： silverlight中的数据绑定、Silverlight 确保您的 Silverlight 应用程序能与 Silverlight 4 一起工作的相关信息，可以在本站进行搜索。
本文标签：
