Recommended Downloads

• Visual Studio 2010 SP1 (required)
• Silverlight 5 Beta Tools for Visual Studio SP1 (required)
• Expression Blend Preview for Silverlight 5(optional)

VS/VWD 2010 SP1 + SL5Tools

SL4 development requires VS2010 or VWD2010 RTM and SL4Tools, and optionally Blend 4. VS2010 SP1 has SL4 support built in, so SL4Tools is not needed if you’ve already upgraded to VS2010 SP1. SL5 development requires VS2010 or VWD2010 SP1 and SL5Tools, and optionally Blend Preview for Silverlight 5.

Install

SL5 Beta Tools installs Silverlight 5 Beta Developer Runtime, SDK, Update to VS2010 SP1 (KB2502836), and WCF RIA Services V1.0 SP2 Preview.

Multi-targeting

Once installed, you can create SL5 projects like you used to with previous versions of SL:

SL5 projects can reference assemblies built against early versions of Silverlight. Below screenshot shows a SL5 project using SL4 SDK via Project->Add Reference…–>Browse:

And the result in .csproj file:

<Reference Include="System.Windows.Controls, Version=2.0.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>..\..\..\..\..\..\..\Program Files (x86)\Microsoft SDKs\Silverlight\v4.0\Libraries\Client\System.Windows.Controls.dll</HintPath>
</Reference>

Please notice the HintPath and assembly version (Btw, SL5 increased assembly version from 2.0.5.0 to 5.0.5.0).

You can also upgrade existing SL4 projects to target SL5:

The upgrade changes <ProjectGuid> and <TargetFrameworkVersion> in .csproj, as well as upgrading all SDK references to SL5’s.

Binding Debugging

A popular new feature in SL5Tools is xaml binding debugging:

Blend Preview for Silverlight 5

Optionally, you can also install Blend Preview for Silverlight 5, which is basically Blend 4 with SL5 support:

And you can use both VS and Blend on the same SL5 project and switch between them:

Troubleshoot & Uninstall

VS2010 SP1, SL5Tools and Blend Preview install all take a long time, so please be patient. If you run into install issues, you may want to take a look at install logs in %temp% directory, and attach those logs when you report install issues to Microsoft:

C:\Users\ningz\AppData\Local\Temp>dir /b /o-d *silver*
Silverlight 5 Beta Tools for Visual Studio 2010 SP1_20110413_220121704.html
Silverlight 5 Beta Tools for Visual Studio 2010 SP1_20110413_220121704-MSI_RiaServices.msi.txt
Silverlight 5 Beta Tools for Visual Studio 2010 SP1_20110413_220121704-MSI_silverlight_sdk.msi.txt
Silverlight0.log

To uninstall Silverlight 5 tools, use control panel to uninstall each component individually:

• SL5 runtime, SDK, RIA Services, Blend Preview

• And Update to VS2010 (KB2502836) (please click “View installed updates” to see below)

Enjoy developing against Silverlight 5!

Overview

Below class diagram shows key classes for Silverlight touch support:

• Touch
  • Touch events are asynchronous.
  • Touch events are always fired via application level Touch.FrameReported event.
  • Since touch events are global, they are direct, and there is no need for touch capture.
  • Multitouch is supported.
• Manipulation
  • Manipulation events are exposed by UIElement. They are routed events.
  • Manipulation events are always fired, IsManipulationEnabled property isn’t supported.
  • Manipulation events are synchronous.
  • Only translation and expansion are supported, rotation is not.
  • Concurrent multiple manipulations are not supported.
  • Gesture isn’t supported directly. It is supported by XNA and Silverlight for Windows Phone Toolkit.
• Controls: on Windows Phone 7, ScrollViewer supports pan & flick, Button supports tab.

Silverlight 3

Platform Requirements

Multitouch requires an environment (device; platform and operating system; hosting application such as a browser) that can propagate the touch input to an individual application, such as your Silverlight-based application.

Windows 7 supports multitouch input at the operating system level. This is supported in part through a message (WM_TOUCH). Already at this level, the operating system provides a promotion of multitouch messages to mouse messages. The promotion is present so that multitouch users can use touch and gestures to substitute as mouse moves or mouse clicks. This is useful when interacting with applications that may not be touch-aware, and the application does all its spatial input processing through mouse events and messages. Windows 7 also coalesces the messages when appropriate, so that applications do not have to process an overflow of intermediate messages that all generate incremental events.

Internet Explorer version 8 as a browser host is also multitouch aware. Internet Explorer version 8 forwards platform multitouch messages to plug-ins such as Silverlight that are running within Internet Explorer, such that Silverlight applications can interact with multitouch input.

Multitouch Input for Silverlight (shown for IE8 host)

Multitouch is also supported for Silverlight in current versions of Firefox hosts running on Windows 7, and for out-of-browser applications running on Windows 7. However, multitouch input is not supported for applications running in full-screen mode.

Registering for Multitouch

As part of the broader platform architecture for multitouch, each application that wants to receive multitouch messages must register its HWND (Touch API for Windows 7 includes RegisterTouchWindow for this purpose). The Silverlight 4 run time takes care of this registration step, and registers Silverlight as a runtime and all applications that use Silverlight as the runtime. Therefore it is not generally necessary to interact directly with platform code to process multitouch input. However, the characteristics of multitouch interaction within Touch API for Windows 7 and Silverlight 4 multitouch are fairly specific:

• Silverlight 4 is registered for raw touch input, not gestures. If your requirements include gestures, you have to process touch input into gestures using your own application code, within the context of Silverlight. Alternatively, you may need a larger interoperation design so that you can include a separate HWND that is multitouch registered for gestures from the platform, and interoperates with a Silverlight content area.

• In general, Silverlight 4 promotes raw touch input to mouse events. (However, on a per-touchframe basis, you can disable promotion, as is described in upcoming sections of this topic.)

• Within a host, certain gestures might be promoted by the browser host to become events other than mousedown/mousemove/mouseup.

Promotion to Mouse Events

Mouse event promotion exists so that multitouch users can use touch and gestures to substitute as mouse moves or mouse clicks. Conceptually this is the default, because applications that predate or do not consider multitouch would not know what API to call to perform the promotion, and therefore the platform does the mouse promotion in most cases. Silverlight 4 perpetuates the general concept of mouse event promotion for much the same reasons. Any given existing Silverlight control might have handlers for mouse events, but not specifically for multitouch events. For example, a button would be expected to act as if clicked when the user used a multitouch device to interact with it.

Mouse event promotion does have the potential for event dualism in cases where there is deliberate handling of a multitouch frame and its touch points. Within the body of the handler for a Silverlight multitouch event, you can suspend mouse event promotion for the duration of the primary touch down. For example, if you wanted to create a touch-aware button that performed different actions based on the touch characteristics, you could suspend the promotion so that your button did not promote to the usual "click" behavior, and instead went to your discrete logic for how to handle the input. To do this, call SuspendMousePromotionUntilTouchUp as one of the first operations of your handler.

The exact nature of mouse promotion is not documented here, because it is a platform characteristic. Generally speaking, the mechanism is a message-to-message promotion.

Touch to Gesture

Silverlight processes multitouch messages at the level of the raw message, analogous to the platform WM_TOUCH, along with access to other APIs that can capture touchpoint characteristics at that raw level that are then exposed as Silverlight APIs. Silverlight does not natively process touch to gestures, use the platform capabilities to that effect, or process WM_GESTURE. (Processing WM_GESTURE would require a registration state with the platform that Silverlight 4 does not opt into.)

If you want to process multitouch using the gesture metaphor, your code must handle the touch events and use the API exposed under Silverlight 4 and process into gestures, with or without using the platform API for gestures. This is not trivial.

Touch API

One important difference between multitouch input and other input techniques supported in Silverlight (mouse, keyboard, stylus) is that you register for multitouch events on an application-wide basis, not by adding handlers to specific input elements (UIElement objects). This is consistent with the metaphor that Silverlight as a whole is the "application" registered with the platform.

• To assign a multitouch event handler, you assign a handler for the static event Touch.FrameReported. System.Windows.Input.Touch is a static service class that exists solely for this purpose with Touch.FrameReported as its only API.

• The handler you write for Touch.FrameReported is based on the TouchFrameEventHandler delegate.

• In a typical UI design, you might have areas of the UI that you intend to support specific multitouch actions within, and other areas where it would be better to use mouse promotion and not necessarily process the input as multitouch. To determine where the primary touch point is, you may have to evaluate the overall coordinate against the location of your multitouch-aware element, and its bounds. See GetPrimaryTouchPoint for more information and example code.

• As mentioned previously, you may want to suspend mouse event promotion as part of your TouchFrameEventHandler logic. To do this, call SuspendMousePromotionUntilTouchUp as one of the first operations.

• Touch messages as reported to Silverlight 4 are typically combined as frames, which start with a primary "down" touch point. Sometimes you are only interested in the first touch point and the first "up" But the frame may contain other touch points and "move" actions. To access the full collection of points in a frame in your handlers, call GetTouchPoints. For a given touch point, probably the most important information is its Position.

• Other APIs expose information that in the platform API would be found in the TOUCHINPUT structure. Examples of such API are:TouchFrameEventArgs.Timestamp; TouchDevice.DirectlyOver; TouchPoint.Size; TouchPoint.TouchDevice. Depending on your scenario, you might not always need this level of information.

Manipulation API in Silverlight Version 4

The Silverlight 4 UIElement class has several events related to manipulations, as well as event support classes such as ManipulationStartedEventArgs. However, these APIs and the related manipulation concepts do not have full support under Silverlight 4 at run time. To handle these events, your application must be targeting Silverlight for Windows Phone. The events exist in the Silverlight 4 assemblies in order to provide common designer support for both Silverlight 4 and Silverlight for Windows Phone.

Silverlight for Windows Phone 7

Gesture Support in the Silverlight Framework

For a full list of supported Windows Phone Silverlight gestures, see the UI Design and Interaction Guide.

Silverlight for Windows Phone allows you to process touch input by using manipulation events. By using these events, you can move and scale objects in response to touch and multi-touch input. The events are described in the following table.

Event	Description
ManipulationStarted	This event occurs when the user starts a direct manipulation by placing their finger or fingers on the screen.
ManipulationDelta	This event occurs repeatedly while the user is moving their finger or fingers on the screen.
ManipulationCompleted	This event occurs when the user removed their finger or fingers from the screen

Note:

Silverlight controls that are supported on Windows Phone are gesture-aware, and support gestures such as tap, pan, and flick. You can handle simple gestures such as tap, double-tap, and tap-and-hold by using mouse events. For more information, see the Input for Windows Phone topic.

Gesture Support in the XNA Framework

The XNA framework offers a robust touch gesture system for developing applications. Developers can leverage this built-in gesture system instead of implementing one from scratch. The following XNA gestures are supported in Windows Phone.

GestureType	Description
Tap	A finger touches the screen and releases.
DoubleTap	This gesture represents two taps in succession.
Hold	A finger touches the screen and holds it in place for a brief period of time.
FreeDrag	A finger touches the screen and moves in any direction.
VerticalDrag	A finger touches the screen and moves in an up or down direction.
HorizontalDrag	A finger touches the screen and moves in a left or right direction.
DragComplete	Marks the end of a FreeDrag, VerticalDrag, or HorizontalDrag gesture.
Flick	A finger drags across the screen and is lifted up without stopping.
Pinch	Two fingers press on the screen and move around.
PinchComplete	This gesture marks the end of a Pinch gesture.

The following list provides useful topics and articles for implementing gesture support in an XNA application:

• Working with Touch Input (Windows Phone)

• Detecting Gestures on a Multi-touch Screen (Windows Phone)

• Windows Phone 7 Gestures Compared

Diagram

Summary

• Timeline is the base class of animation classes and Storyboard. It provides BeginTime, Duration, FillBehavior, RepeatBehavior, AutoReverse etc. dependent properties, and Completed event.
• Storyboard is a collection of Timelines, including animations and storyboards. It provides Begin, Stop, Pause, Resume etc. methods, and TargetName and TargetProperty attached properties.
• Basic animations: [Double|Point|Color]Animation classes animate correspondingly typed dependent properties between two values specified by From, To, By properties. They use EasingFunction property to animate changes non-linearly:
  • Easing functions: Silverlight provides 11 easing function classes ([Back|Bounce|Circle|Cubic|Elastic|Exponential|Power|Quadratic|Quartic|Quintic|Sine]Ease), all subclass of EasingFunctionBase, which provides dependent property EasingMode. 
• Key-frame animation: key-frame animations support animating through a collection of key frames, each with KeyTime and Value properties. They also support multiple interpolation methods between key frames: discrete, easing, linear, spline. So there are 13 key frame classes: [Discrete|Easing|Linear|Spline][Double|Point|Color]KeyFrame and ObjectKeyFrame.

Table

Visual Studio setup cannot run in compatibility mode. For more information see the ‘Installing’ section in the Visual Studio Readme at "http://go.microsoft.com/fwlink/?LinkId=143397".

After searching the Internet and tried a few things, what worked for me is to uncheck “Run this program in compatibility mode” in vm_web.exe’s Properties dialog:

If the checkbox is checked and grayed out, click “Change settings for all users” button at the bottom of the dialog, and then uncheck “Run this program in compatibility mode” in the popped up “Compatibility for all users” dialog:

After that, rerun vm_web.exe and it should succeed.

Below is relevant section in Visual Studio readme at http://go.microsoft.com/fwlink/?LinkId=143397. I removed the registry entry for vm_web.exe and VS2010’s setup.exe, but not sure whether it helped or not.

2.1.10 Visual Studio Setup cannot be run in Program Compatibility Mode

Visual Studio 2010 and/or the .NET Framework 4 Setup fails with 1603 error code or blocks running in Program Compatibility Mode.

Windows Program Compatibility Assistant indicates that Visual Studio Setup might not have installed correctly, and prompts the user to reinstall by using the recommended setting (program compatibility mode).

To resolve this issue:

Visual Studio Setup cannot run in program compatibility mode.  Ensure that the compatibility mode setting is not enabled system-wide or for the Visual Studio Setup application.

Check the manual setting

Compatibility mode could have been set manually on the Compatibility tab on the executable file properties.

1. On the Visual Studio Setup media, locate setup.exe.
2. Right-click setup.exe and then click Properties.
3. On the Compatibility tab, clear "Run this program in compatibility mode for" and then then click OK.

Check Program Compatibility Assistant registry settings

Compatibility mode could have been set by Program Compatibility Assistant on earlier failed or canceled attempts to run Visual Studio setup.exe.

1. Click Start, and then click Run.
2. Type regedit, and then click OK.
3. Browse to each of the following keys and delete any value that refers to setup.exe in the Visual Studio install path:
   • HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Compatibility Assistant\Persisted
   • HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers

Rerun Visual Studio Setup

1. Open Windows Explorer.
2. Browse to Visual Studio setup.exe.
3. Double-click setup.exe to run Visual Studio Setup.

Related KB Article

http://support.microsoft.com/kb/931709

Another Workaround:

Instead of executing the <DVD ROOT>\setup.exe, execute <DVD ROOT>\setup\setup.exe

Troubleshooting Steps

• Is Silverlight installed?
  on Windows, make sure “Microsoft Silverlight” is in Control Panel –> Programs and Features:
  
  On Mac, make sure /Library/Internet Plug-Ins/Silverlight.plugin is there. If Silverlight isn’t installed, you can install the latest version from http://www.silverlight.net or http://www.microsoft.com/silverlight.
  • Do you have administrative privilege on the machine?
    You will need local administrative privilege to install Silverlight.
  • Do you have webshots/kiwee toolbar installed?
    There are known issues with Silverlight and old version of Webshots/Kiwee from American Greetings. The fix is to upgrade to their latest version from their web sites. Please see Why do I keep getting prompted to install Silverlight? for details.
• Is Silverlight enabled?
  For Internet Explorer, select menu item Tools –> Manage Add-ons, make sure Microsoft Silverlight is enabled for all web sites:
  For Firefox, select menu item Tools –> Add-ons, click Plugins tab, make sure Silverlight Plug-In is enabled:
  
• Is the issue site specific?
  try http://silverlight.net: if you see the showcase Silverlight application on the top right of the page, then your issue is likely to be site specific, please report the issue to the site owner. O/w, please click the Forums tab at http://silverlight.net page, search and/or report the issue there.  
• Is the issue browser specific?
  try open the page in a different browser (IE/Firefox/Chrome on Windows, Safari/Firefox/Chrome on Mac) and see whether the issue repros. If it doesn’t repro, it is likely to be a browser specific configuration issue. Again, it may help to search http://forums.silverlight.net to see whether this is a known issue; and if not, report it.

Report Silverlight Setup Issue

When you report a Silverlight setup issue, it’d help a lot if you can include the following information:

• a short description of the issue
• operating system and browser you are using
• the site you are having problem with
• Silverlight setup log: under %temp% folder (like C:\Users\ningz\AppData\Local\Temp on Win7 or C:\Documents and Settings\ningz\Local Settings\Temp on WinXP), there are two files: a short Silverlight0.log and a longer SilverlightMSI.log).

Other Helpful Sources

• For Vancouver Olympics:
  • http://www.mediaevangelism.com/olympics/faq2.aspx
  • http://www.mediaevangelism.com/olympics/faq.aspx
• How to manually clean up a broken Silverlight installation?
• Uninstalling Silverlight 4 Beta on OSX
• http://silverlight.net

This is first version, I will keep adding content to the post and keep it up to date with issues I see reported. Thanks!

Solution: if you have old version of Webshots Toolbar or Kiwee Toolbar from American Greetings, you should upgrade to latest version from their web sites.

Details:

A few people trying to view Olympics videos from www.nbcolympics.com got prompted to install Silverlight, so they did and then hit F5; the page somehow prompted them to install Silverlight again, so they did again; but this time Silverlight install fails with a telltale error code 1514: Silverlight is already installed; if you want to reinstall, you need to uninstall first. So they uninstall and reinstall, but that didn’t help: they got prompted to install Silverlight again.

After quick investigation, I’ve found a common cause of old version of Webshots or Kiwee installed on those users’ machines. To check, you can find Webshots from Control Panel –> Programs and Features:

or on disk:

The fix is to go to www.webshots.com and upgrade to the latest version (3.1.5.7617 for now):

then you should be able to watch Olympics video just fine with Webshots toolbar enabled as well:

I will publish another blog post with common setup issues and solutions for Silverlight.

Disclaimer:

• I am publishing this blog in a hurry to help those with trouble viewing Olympics video, so I may not get all facts right. I’d appreciate all feedback/correction/suggestion.
• This is my personal blog. What I say in this blog is my opinion only. It doesn’t represent Microsoft or any other organization.

If you write Silverlight controls, you should consider writing design time assemblies for your controls too, for two simple reasons:

• developer productivity: try to imagine Silverlight development without tools like Visual Studio or Blend! For custom controls, you may need to provide much of the design time experience for your controls in Visual Studio or Blend yourself.
• designers: XAML and tools like Blend enable developers and designers work together. A key design criteria for Silverlight controls is to make sure designers can use them without writing a single line of code.

Design time experience usually includes (but not limited to) the following:

1. Metadata for property window, like category, infotip, custom property/binding/collection editors etc.
2. Metadata for design surface, like initializer, adorner, context menu, adapters etc.
3. Toolbox integration, like icons, control registration
4. intellisense for code editor

Except intellisense (please see Add Rich Intellisense for Your Silverlight Controls) and control registration (please see Register Silverlight Controls with visual Studio and Blend), above design time experience are usually delivered through design time assemblies. Below I will discuss various approaches of delivering design time experiences, in increasing complexity and flexibility, and gradually introduce pieces of the naming convention for design time assemblies.

Runtime Assembly Only

The simplest way to deliver design time experience is to package design time code into the runtime assemblies, especially when design time metadata are meaningful at runtime too, like TypeConverterAttribute.

The pros and cons of this approach:

• Pro: simple
  • no separate design time assemblies, simpler setup
  • design time attributes are specified directly on the runtime code, easier to maintain
• Con: tight coupling of runtime and design time code
  • perf degradation because of useless design time code at runtime
  • design time dependencies (like MWDs and other VS/Blend assemblies) get dragged into runtime unnecessarily
  • can’t service runtime or design time independently
  • can’t support multiple designers (like both VS2008/Blend2 and VS2010/Blend3)

The cons are particularly bad for Silverlight, because design time assemblies are actually .NET assemblies, with references to Silverlight types. Mixing Silverlight and .NET assemblies can be challenging and confusing, and may lead to subtle bugs. Also, Silverlight applications are mostly web applications, so download size and performance are particularly important. Dragging in .NET assemblies in Silverlight applications certainly doesn’t help. So this approach is highly discouraged, unless there is strong justification for it.

Shared Design Time Assembly

So the revolutionary step forward is to decouple design time and runtime code, release and service them with separate assemblies. This opens up all kinds of possibilities. Of course, we need a way to link design time assemblies to their corresponding runtime assemblies, without introducing any unnecessary dependency or perf degradation to runtime assemblies. Hence the naming convention: if a runtime assembly Foo.dll is referenced in a Silverlight project, the designer (like Visual Studio and Blend) will first try to load design time information like icons (via another naming convention, see How to Add an Toolbox Icon for Your Silverlight Control) and design time metadata (via interface, like IRegisterMetadata for VS2008 and Blend2, or IProvideAttributeTable for VS2010 and Blend3. Please see How to Write Silverlight Design Time for All Designers: Visual Studio 2008, Blend 2; Blend 3, and Visual Studio 2010) from the runtime assembly; it will then look for a design time assembly by the name Foo.Design.dll in the same directory as Foo.dll; if found, the designer will try to load design time information from Foo.Design.dll as well.

Designer Specific Design Time Assembly

Visual Studio is mostly for developers, while Blend is mostly for designers, so they have different requirements for design time experiences. Putting all design time code in one shared design time assembly introduces tight coupling among designers. So the naming convention is enhanced: for runtime assembly Foo.dll, there is a shared design time assembly Foo.Design.dll that’s loaded by all designers; each designer will also try to load its own design time assemblies, like Foo.VisualStudio.Design.dll for Visual Studio, and Foo.Expression.Design.dll for Blend. The designer specific design time assembly is loaded after the shared design time assembly. Third party designers can define their own designer specific design time assembly. Silverlight Toolkit December 2008 Release is using this naming convention. Please see Design Time Features in Silverlight Toolkit and Design Time Feature Implementation in Silverlight Toolkit for more information.

Design Sub Folder

So to support both Visual Studio and Blend, each runtime assembly has three design time assemblies, in the same directory, and a package (like Silverlight SDK or Silverlight Toolkit) usually contains several runtime assemblies. So the directory gets a bit crowded. A minor improvement is to put the design time assemblies under a Design subfolder. So the naming convention is further enhanced: if a designer (like Visual Studio or Blend) can’t find corresponding design time assemblies in the same directory as a runtime assembly, it will look for them in the Design subfolder, if it exists. 

Support Multiple Versions of MWDs

Design time are built on top of designer extensibility framework, which consists of several dlls like Microsoft.Windows.Design.Extensibility.dll and Microsoft.Windows.Design.Interaction.dll. We usually call them collectively as MWDs. To make life more interesting, sometimes we have to introduce breaking changes to the extensibility framework, like VS2008 and Blend2 use MWD version 3.5, VS2010 and Blend3 use MWD version 4.0, and they are incompatible. So if you have a runtime assembly Foo.dll, and you want your users to be able to develop against it with both VS2008 and VS2010, you have to provide two sets of design time assemblies: one set built against v3.5 MWDs and used by VS2008, and another set built against v4.0 MWD and used by VS2010. The two sets of design time assemblies probably have a lot of code in common, while the one for VS2010 may have some new code to leverage the new functionalities exposed by VS2010. Since design time assemblies are loaded by name and you can’t have two files with the same name, so the naming convention is enhanced yet again:

for a runtime assembly Foo.dll, the shared design time assembly is named Foo.Design*.dll, the Visual Studio specific design time assembly is named Foo.VisualStudio.Design*.dll, and the Blend specific design time assembly is named Foo.Expression.Design*.dll, where * can be zero or more valid characters for file names. When a designer (like Visual Studio or Blend) tries to load a design time assembly and several fit the naming convention, zero or one will be loaded:

• If the MWD version referenced by the design-time assembly has a different major version number than the designer’s MWD version, then the design-time assembly will not load and is bypassed.
• If more than one design-time assembly is compatible with the designer’s MWD version, the Designer loads the one compiled against the highest MWD version that is less than or equal to the designer’s MWD version.

Silverlight 3 Toolkit October 2009 Release uses this naming convention to support both VS2008 and Blend3/VS2010. Please see Silverlight Design Time: Toolkit October 2009 Release Update, How to Write Silverlight Design Time for All Designers: Visual Studio 2008, Blend 2; Blend 3, and Visual Studio 2010, and Extensibility Series – WPF & Silverlight Design-Time Code Sharing – Part I more information.

Support Both WPF and Silverlight

To complicate life further, since WPF and Silverlight are so awfully similar, you may be tempted to try to write it once and run with both WPF and Silverlight. You are not alone. There are many articles on how to share source code and/or binaries across Silverlight and WPF. We’d like to do that for design time assemblies too, i.e. have the same design time assemblies for both WPF and Silverlight controls. One approach is to make most of the design time assemblies platform agnostic, and limit platform specific (WPF or Silverlight) code and references to a small platform specific assembly. Silverlight 3 SDK GDR 2 (installed by VS2010 automatically too) uses this approach for DataGrid designer (there is a System.Windows.Controls.Data.VisualStudio.Design.4.0.Silverlight.dll in the SDK directory). Please see Extensibility Series – WPF & Silverlight Design-Time Code Sharing – Part I for more information.

Last One Wins

The same design time metadata for a class or its member can be specified multiple times in multiple design time assemblies, which allows the shared design time assembly to specify default/common behavior and then designer specific design time assemblies to override it if necessary. The same design time metadata can also be specified multiple times within a single design time assembly (please see Design Time Feature Implementation in Silverlight Toolkit as an example, where DescriptionAttribute for a class or its property can be added by AddDescriptions, AddAttributes and AddTables methods). So we need to know which metadata wins. The simplest and most logic design is last one wins. This is mostly true but not always. Sometimes the result can be un-deterministic when the same design time metadata is specified several times but with different values.

Feedback

Design time sounds easy, but devil is in the details! Feedbacks are always appreciated. Please let me know what issues you run into, what requests/improvements you’d like to make, for both design times experience and designer extensibility framework. Thanks!

Drag and drop is a common UX paradigm and a top requested feature. In Silverlight 4 Beta, we introduced a basic set of API to enable the most common scenario of dragging pictures files and dropping them to Silverlight applications, and we designed the API to allow us to expose more drag and drop functionalities down the road without API change, hopefully.

API

Below is the core of the new API:

namespace System.Windows
{
    public abstract class UIElement : DependencyObject
    {
        // Fields
        public static readonly DependencyProperty AllowDropProperty;

        // Events
        public event DragEventHandler DragEnter;
        public event DragEventHandler DragLeave;
        public event DragEventHandler DragOver;
        public event DragEventHandler Drop;

        // Properties
        public bool AllowDrop { get; set; }
    }

    public delegate void DragEventHandler(object sender, DragEventArgs e);

    public sealed class DragEventArgs : RoutedEventArgs
    {
        // Methods
        public Point GetPosition(UIElement relativeTo);

        // Properties
        public IDataObject Data { [SecuritySafeCritical] get; }
        public bool Handled { get; set; }
    }
}

namespace System.Windows.Controls
{
    public abstract class Control : FrameworkElement
    {
        protected virtual void OnDragEnter(DragEventArgs e);
        protected virtual void OnDragLeave(DragEventArgs e);
        protected virtual void OnDragOver(DragEventArgs e);
        protected virtual void OnDrop(DragEventArgs e);
    }
}

• AllowDrop: this is dependency property, indicating whether an element is a drop target.
• DragEnter, DragLeave, DragOver & Drop: these are routed events. They bubble up, and fire only on elements with AllowDrop set to true.
• OnDragEnter, OnDragLeave, OnDragOver & OnDrop: these are protected virtual functions for subclasses to override. 
• DragEventArgs: this class allows drop target event handlers or method overrides to access the data being dragged or dropped.

Usage

There are primarily two ways to use Silverlight’s drag and drop API:

• Silverlight applications can handle those drop target events and process the files dropped in the event handlers.
• Silverlight controls can override those drop target virtual functions to process the data being dragged and dropped, and enable themselves to be drop targets.

Limitations

The drag and drop functionality shipped in Silverlight 4 Beta only enables the most common scenario: Silverlight plugin as a file drop target. Please notice the following limitations with current implementation:

• there is no drop source support (QueryContinueDrag & GiveFeedback).
• there is no DragDropEffects or DragDropKeyStates in DragEventArgs.
• there is no visual for the dragged object or DragDropEffects.
• only file drag and drop is supported:
  • all drop target events fire only when files are being dragged and dropped.
  • IDataObject, DataObject and DragEventArgs.Data support only one format: “FileDrop”, and the data is of type FileInfo[].
• most of IDataObject methods throw NotImplementedException.
  
• for drag and drop to work on Windows, Silverlight plugin must be windowed. In another word, if <param name="windowless" value="true"/> is specified, drop events won’t fire.
• since Silverlight plugin on Mac is always windowless, you need to hook up JavaScript drop events to trigger Silverlight drop events. In another word, if you want your Silverlight application to support file drop on Mac as well as Windows, you will need to add following script and Silverlight plugin attributes to the hosting html or aspx page:

  <!-- add following script before end of HEAD tag -->
  <script type="text/javascript">
      function handleDragEnter(oEvent) {
          // Prevent default operations
          oEvent.preventDefault();
  
          var flag = silverlightControl.dragEnter(oEvent);
  
          // If we handled it successfully then stop propagation of the event
          if (flag)
              oEvent.stopPropagation();
      }
  
      function handleDragLeave(oEvent) {
          // Prevent default operations
          oEvent.preventDefault();
  
          var flag = silverlightControl.dragLeave(oEvent);
  
          // If we handled it successfully then stop propagation of the event
          if (flag)
              oEvent.stopPropagation();
      }
  
      function handleDragOver(oEvent) {
          // Prevent default operations
          oEvent.preventDefault();
  
          var flag = silverlightControl.dragOver(oEvent);
  
          // If we handled it successfully then stop propagation of the event
          if (flag)
              oEvent.stopPropagation();
      }
  
      function handleDropEvent(oEvent) {
  
          // Prevent default operations
          oEvent.preventDefault();
  
          var flag = silverlightControl.dragDrop(oEvent);
  
          // If we handled it successfully then stop propagation of the event
          if (flag)
              oEvent.stopPropagation();
      }
  </script>
  <!-- use JavaScript drop target events to trigger Silverlight's drop target events -->
  <object data="data:application/x-silverlight-2," type="application/x-silverlight-2" width="100%" height="100%"
    id="silverlightControl" ondragenter="handleDragEnter(event)" ondragover="handleDragOver(event)" 
    ondragleave="handleDragLeave(event)" ondrop="handleDropEvent(event)" >
  

  
  

• DragEventArgs.Data is only accessible in Drop event. Accessing DragEventArgs.Data in DragEnter, DragOver and DragLeave may cause SecurityException. And accessing Directory, DirectoryName or FullName property of the FileInfo object from DragEventArgs.Data may cause ArgumentNullException. 

Demo App

Below is a demo app:

• the top left nested grids use drop target event handler to display DragEventArgs info.
• the top right nested grids contain an ImageDropTarget user control, which overrides OnDrop method to render the dropped file if it is an image.
• the bottom listbox shows the sequence of drop target events, their bubbling up, and DragEventArgs info.

you can find the complete source here.

Feedback

While we are excited to add drag and drop to Silverlight, we know there are a lot to finish/improve, and what we released is just a Beta. As always, your feedback is highly appreciated, and will be used as an important data point to help us prioritize the work. Thanks!

• Install, configuration and runtime UI are in Arabic and RTL layout on Arabic culture
• Support mixed BiDi/ComplexScript text
• Support RTL layout with FlowDirection attribute and implemented by all controls

Below screenshots demonstrate some of the support:

• Install UI:
  
• Configuration UI:
  
• Controls with FlowDirection set to RightToLeft:
  

For those curious, you may notice that:

• there is a new ar directory under %programfiles%\Microsoft Silverlight\4.0.41108.0, besides the 10 directories that have been there since SL3: de, en-us, es, fr, it, ja, ko, zh-Hans, zh-Hint. The ar directory contains Arabic resources for Silverlight runtime assemblies.
• the MUI resource dlls contain Arabic resources:
  

We will continue adding more support to more cultures in Silverlight. The Arabic support debuted in Silverlight 4 Beta is particularly important, since it is the first RTL language Silverlight supports. If you notice any bug or have suggestions, please let me know.

Silverlight 4 adds Clipboard support. Check out the amazing demos by Scott Guthrie and Brian Goldfarb today at PDC that showcase scenarios enabled by Silveilght4 Clipboard support.

Silverlight’s Clipboard API is a subset of WPF’s Clipboard API:

public static class Clipboard 
{ 
    public static bool ContainsText(); 
    public static string GetText(); 
    public static void SetText(string text); 
}

It allows copy/paste Unicode strings to/from system clipboard. GetText and SetText require either of following to succeed:

1. the calling Silverlight application is an elevated trust application, or
2. it is user initiated and user grants clipboard access

For the second case, when GetText or SetText is first called in an user initiated event handling, Silverlight pops up a dialog like the one below (UI may change at RTW):

If user clicks yes, Silverlight will allow this and later GetText/SetText calls to succeed for this application during this session; if user clicks no, the default, Silverlight will throw a SecurityException. In another word, the setting is per application, per session, for both get and set access to system clipboard, and it is not persisted.

Clipboard API in JavaScript and WPF

We need to consider many factors while designing Clipboard API for Silverlight. Among them, the Clipboard APIs of JavaScript and WPF are particularly interesting, because we need to study the security lessons in JavaScript and try to be compatible with WPF.

There is no cross browser, cross platform JavaScript API for clipboard access. IE provides clipboardData object that allows get/set/clear strings in system clipboard:

bResult = window.clipboardData.setData(sDataFormat, sData);

sData = window.clipboardData.getData(sDataFormat);

bResult = window.clipboardData.clearData([sDataFormat]);

where sDataFormat is a string constant of "Text" or "URL", sData is a string, and bResult is a Boolean.

The first time the clipboadData object is accessed, IE will prompt user to allow the script to access clipboard, and the setting is valid for the session only.

WPF’s Clipboard API supports more and extensible data format via IDataObject, and has helper functions for common formats like text, image, audio, and filedrop.

public static class Clipboard 
{ 
    [SecurityCritical] 
    public static void Clear(); 

    public static bool ContainsAudio(); 
    public static bool ContainsData(string format); 
    public static bool ContainsFileDropList(); 
    public static bool ContainsImage(); 
    public static bool ContainsText(); 
    public static bool ContainsText(TextDataFormat format); 
    public static Stream GetAudioStream(); 
    public static object GetData(string format); 
    [SecurityCritical] 
    public static IDataObject GetDataObject(); 
    public static StringCollection GetFileDropList(); 
    public static BitmapSource GetImage(); 
    public static string GetText(); 
    public static string GetText(TextDataFormat format); 

    public static bool IsCurrent(IDataObject data); 

    public static void SetAudio(byte[] audioBytes); 
    public static void SetAudio(Stream audioStream); 
    public static void SetData(string format, object data); 
    [SecurityCritical] 
    public static void SetDataObject(object data); 
    [SecurityCritical] 
    public static void SetDataObject(object data, bool copy); 
    public static void SetFileDropList(StringCollection fileDropList); 
    public static void SetImage(BitmapSource image); 
    public static void SetText(string text); 
    public static void SetText(string text, TextDataFormat format); 
}

Clipboard API in Windows and Mac OS X

Silverlight’s clipboard API is ultimately implemented on top of the clipboard APIs of the underlying operating system. Windows’ clipboard APIs are documented at MSDN, below excerpt gives an overview on how to set/get clipboard data:

Cut and Copy Operations

To place information on the clipboard, a window first clears any previous clipboard content by using the EmptyClipboard function. This function sends the WM_DESTROYCLIPBOARD message to the previous clipboard owner, frees resources associated with data on the clipboard, and assigns clipboard ownership to the window that has the clipboard open. To find out which window owns the clipboard, call the GetClipboardOwner function.

After emptying the clipboard, the window places data on the clipboard in as many clipboard formats as possible, ordered from the most descriptive clipboard format to the least descriptive. For each format, the window calls the SetClipboardData function, specifying the format identifier and a global memory handle. The memory handle can be NULL, indicating that the window renders the data on request. For more information, see Delayed Rendering.

Paste Operations

To retrieve paste information from the clipboard, a window first determines the clipboard format to retrieve. Typically, a window enumerates the available clipboard formats by using the EnumClipboardFormats function and uses the first format it recognizes. This method selects the best available format according to the priority set when the data was placed on the clipboard.

Alternatively, a window can use the GetPriorityClipboardFormat function. This function identifies the best available clipboard format according to a specified priority. A window that recognizes only one clipboard format can simply determine whether that format is available by using the IsClipboardFormatAvailable function.

After determining the clipboard format to use, a window calls the GetClipboardData function. This function returns the handle to a global memory object containing data in the specified format. A window can briefly lock the memory object in order to examine or copy the data. However, a window should not free the object or leave it locked for a long period of time.

For now, Silverlight Clipboard API only supports CF_UNICODETEXT format for copy/paste Unicode text to/from clipboard.

Mac OS X uses Pasteboard Manager. It is documented at Mac Dev Center. Below excerpt (with APIs added) gives an overview:

The copying application is responsible for placing copied or cut data onto the pasteboard:

1. The user selects some data and invokes the Copy (or Cut) menu item.

2. If the application doesn’t already have a reference to the Clipboard pasteboard, it creates one (PasteboardCreate).

3. The application then takes ownership of the pasteboard and clears the current contents (PasteboardClear).

4. The application assigns item IDs to the selected data.

5. If any data is to be promised, the application must register a promise keeper callback function to supply the promised data (PasteboardSetPromiseKeeper).

6. The application adds one or more flavors of each item to the pasteboard, including either the actual flavor data or a promise with each flavor (PasteboardPutItemFlavor).

The receiving application has a slightly different set of tasks to handle the Paste action:

1. When the application becomes active, it checks to see if the pasteboard has been modified (PasteboardSynchronize). If so, it obtains a listing of the flavors on the pasteboard. If there are any flavors the application supports, it can enable its Paste menu item.

2. The user invokes the Paste menu item.

3. The application requests the item (or items) on the pasteboard in the flavors that it supports (PasteboardGetItemCount, PasteboardGetItemIdentifier, PasteboardCopyItemFlavors, PasteboardCopyItemFlavorData).

4. If the pasted data is to be stored as a file, the receiving application needs to set a paste location before requesting any flavor data. In any other case, the receiving application doesn’t need to worry about whether the paste data was promised or not.

If the copying application’s promise keeper is called, the callback must do the following:

• If the data is to be stored as a file, determine the paste location specified by the receiving application.

• Generate or otherwise prepare the promised data for transfer.

• If the promised data is not be stored as a file, add the flavor and data to the pasteboard. Otherwise, transfer the promised data to the specified file location.

Some time later, when the application quits, or when it no longer needs the pasteboard, the application can release the pasteboard reference.

As on Windows, Silverlight Clipboard API only uses kPasteboardClipboard and kUTTypeUTF16PlainText flavor to support copy/paste Unicode text to/from clipboard.

Feedback

We are excited to add clipboard support to Silverlight, and see all the important scenarios enabled by this simple API. I am interested in hearing your feedbacks, especially:

• any security concerns over Silverlight clipboard API design and implementation
• how important it is to add support for other data type/format, and in what priority order
• how important it is to make the API extensible, like supporting IDataObject, allowing custom format/flavor and delayed rendering/promised data

Thanks!

-Ning