The following controls and types have been removed from the Silverlight SDK:

• DockPanel

• WrapPanel

• Expander

• HeaderedContentControl

• Viewbox

• DataForm

• ExpandDirection

• ExpanderAutomationPeer

• LengthConverter

• StretchDirection

These controls are now in the Silverlight Toolkit, which is available at http://www.codeplex.com/Silverlight.

The following members and types of AutoCompleteBox have been renamed:

• AutoCompleteBox.SearchMode property is now AutoCompleteBox.FilterMode

• AutoCompleteSearchMode enum is now AutoCompleteFilterMode

• AutoCompleteSearchPredicate delegate is now AutoCompleteFilterPredicate

Before:

<input:AutoCompleteBox SearchMode="Contains" />

After:

<input:AutoCompleteBox FilterMode="Contains" />

If you have an AutoCompleteBox control template with a part named SelectionAdapter, you should rename it to Selector.

Previously, AutoCompleteBox would use any template part named SelectionAdapter, and attempt to either use it as an adapter, or wrap it in a pre-defined SelectorSelectionAdapter.

With this change, the basic logic to prepare the Selection Adapter for the AutoCompleteBox is:

• Find a template part named Selector.

  • If the control implements ISelectionAdapter, use it.

  • Else, if a Selector was found, create a new SelectorSelectionAdapter for it.

• If no SelectionAdapter has been prepared, locate a template part named SelectionAdapter.

Previously, the AutoCompleteBox API contained a protected virtual method named TryGetSelectionAdapter. The API did not actually implement the TryGet pattern.

The new API is simply a protected virtual method with no parameters named GetSelectionAdapterPart.

The default control template for AutoCompleteBox never has made use of this template part. To improve the templating experience in Expression Blend, this template part has been removed.

How do I update an existing application?

In the file with the custom control template definition, add a Click event handler in XAML and the code-behind. Then, locate the AutoCompleteBox control in the visual tree hierarchy and toggle its IsDropDownOpen dependency property.

Code that derived from AutoCompleteBox should still be able to define its own ToggleButton template part and toggle the IsDropDownOpen property.

From an updated sample application, here is part of the custom control template:

And the code-behind file:

These events did not completely work in the Beta, and have been removed.

The SortDescriptions and GroupDescriptions properties were removed from DataGrid. You can use the code-behind to setup the group descriptions. For more information, see How to: Group, Sort, and Filter Data in the DataGrid Control.

Silverlight 3 Beta

<dataGrid.GroupDescriptions>
      <windata:PropertyGroupDescription PropertyName="State" />
</dataGrid.GroupDescriptions>

Silverlight 3 Release

pagedCollectionView.GroupDescriptions.Add(new PropertyGroupDescription("State"));

Who Is Affected: Silverlight 3 Beta managed applications that re-templated the DataGrid to a custom template that includes a ListBox for validation errors.

Summary: To have a standard look and feel for entity level validation errors, the DataGrid now uses a ValidationSummary. Previously, the DataGrid used a ListBox.

Fix Required: Users with custom DataGrid templates that include a ListBox for validation errors need to update their templates.

Silverlight 3 Beta

<ListBox Name="ErrorsListBox" Grid.Row="3" Grid.ColumnSpan="3" MaxHeight="91" Background="#FFEFEFEA" BorderThickness="0,1,0,0">

Silverlight 3 Release

<dataInput:ValidationSummary Name="ValidationSummary" Filter="ObjectErrors" Grid.Row="3" Grid.ColumnSpan="3" MaxHeight="90"/>

Important Note:
The DataForm control has been removed from the SDK. It is now in the Silverlight Toolkit, which is available at http://www.codeplex.com/Silverlight.

The largest change related to DataForm impacts anyone using the Fields collection in the DataForm, and is as follows:

DataFormFields have all been removed and DataForm.Fields collection has been removed. They have been replaced with the new DataField control, which is a control that wraps content with a label and DescriptionViewer. Also, note that you must now explicitly specify Mode=TwoWay on bindings in the DataField, whereas before you could just specify the path and the DataFormField would inject TwoWay into the binding. For example, if you have the following in the Fields collection:

<dataControls:DataFormTextField Binding="{Binding FirstName}" />

you would want to instead place this in the EditTemplate:

<dataControls:DataField>
    <TextBox Text="{Binding FirstName, Mode=TwoWay}" />
</dataControls:DataField>

Note that since these are now controls, DataFormFieldGroups can be replaced just with regular panels.

Also note that since these are now controls unto themselves, the DataForm no longer handles all of the alignment of the labels in these fields. The DataForm will group these fields together at the top level, but if you want more fine-tuned grouping (for example, two columns of fields), you can use the attached property DataField.IsFieldGroup on a Panel to specify that the DataFields within the Panel should have their labels grouped together in width. The following shows an example:

<StackPanel Orientation="Horizontal">
    <StackPanel dataControls:DataField.IsFieldGroup="True">
        <dataControls:DataField>
            <TextBox Text="{Binding FirstName, Mode=TwoWay}" />
        </dataControls:DataField>
        <dataControls:DataField>
            <TextBox Text="{Binding LastName, Mode=TwoWay}" />
        </dataControls:DataField>
    </StackPanel>
    <StackPanel dataControls:DataField.IsFieldGroup="True">
        <dataControls:DataField>
            <TextBox Text="{Binding StreetAddress, Mode=TwoWay}" />
        </dataControls:DataField>
        <dataControls:DataField>
            <TextBox Text="{Binding State, Mode=TwoWay}" />
        </dataControls:DataField>
    </StackPanel>
</StackPanel>

This would cause the FirstName/LastName DataFields to have their labels the same width, and similarly for StreetAddress/State DataFields.

That represents the bulk of this breaking change. In addition, there are other breaking changes on the DataForm which are as follows:

• FieldEditEnding and FieldEditEnded have been removed.

• GetFieldElement() has been removed.

• ItemEditEnding, ItemEditEnded, CommitItemEdit() have been changed to EditEnding, EditEnded, and CommitEdit() respectively.

• CanMoveToXXXXItem have been removed, as they can be derived from the collection given to the DataForm.

• CanUserAdd/DeleteItems have been removed, as they are implied through CommandButtonsVisibility.

• IsEditing and IsAddingItem have been removed, as they are implied through Mode.

• FieldLabelPosition and FieldLabelStyle have become LabelPosition and LabelStyle.

• WrapAfter and Orientation have been removed.

• The type names DataFormFieldLabelPosition and DataFormDescriptionViewerPosition have been changed to DataFieldLabelPosition and DataFieldDescriptionViewerPosition.

These breaking changes are summarized below:

• System.ComponentModel.dll has been deleted.

• From System.ComponentModel, the following classes/interfaces have been moved to the new System.Windows.Data.dll (namespaces have remained unchanged):

  • PagedCollectionView

  • CollectionViewGroup

  • IEditableCollectionView

  • IPagedCollectionView

  • PageChangingEventArgs

  • PropertyGroupDescription

• The following classes/interfaces will no longer be part of the Silverlight SDK:

  • EntityAction

  • IEditableCollection

  • IIndexableCollection

• IPagedCollection has been removed. PagedCollectionView no longer has special-cases implementers of IPagedCollection.

• DataPager.Source is no longer of type IPagedCollectionView, but is now an IEnumerable that may also be an IPagedCollectionView.  When non-IPagedCollectionViews are given to the DataPager, it behaves as though a collection with a single large page was bound to the control.  To invoke IPagedCollectionView APIs, cast the Source property to an IPagedCollectionView.

PagedCollectionView no longer supports arbitrary remote paging. As a result, PagedCollectionView.NewItemPlaceholder has been removed, and PagedCollectionView.ItemCount and TotalItemCount properties are now read-only.

The DataPagerAutomationPeer now implements IRangeValueProvider explicitly rather than implicitly. As a result, the following members have been removed from the DataPagerAutomationPeer class:

• public bool IsReadOnly { get; set; }

• public double LargeChange { get; set; }

• public double Maximum { get; set; }

• public double Minimum { get; set; }

• public double SmallChange { get; }

• public double Value { get; }

• public void SetValue(double value);

In Silverlight 3 Beta, the Bindable attribute was used to annotate the properties of a business object allowing the UI to react in two ways:

• To treat the property as read only in the UI.

• To tell controls that perform auto-generation, such as DataGrid and DataForm, if they should generate UI for the property.

In the Silverlight 3 release, the Editable and Display attributes should be used for these purposes.

Marking a property as ReadOnly in the UI:

Marking a property to not have controls auto-generate UI for it:

Any classes that derive from the Beta of ValidationAttribute will likely need to be updated. Instead of returning a bool from IsValid, implementations should only override the ValidationContext-based IsValid method and return ValidationResult. ValidationContext can be ignored if it is not needed.

The following changes have been made to the ValidationAttribute API:

• ValidationAttribute.Validate(object value, string name) changed to Validate(object value, ValidationContext validationContext).

• TryValidate(object value, ValidationContext validationContext, ref ValidationResult validationResult) has been removed.

• GetValidationResult(object value, ValidationContext validationContext, out ValidationResult validationResult) has been changed to public GetValidationResult(object value, ValidationContext validationContext).

• public abstract bool IsValid(object value) has been removed.

• protected virtual bool ValidationResult IsValid(object value, ValidationContext validationContext, out ValidationResult validationResult) has been changed to protected virtual ValidationResult IsValid(object value, ValidationContext validationContext).

Representing Success and Failure: ValidationAttribute implementations need to return ValidationResult to represent both success and failure.  In order to represent success, public static readonly ValidationResult Success was added to ValidationResult. For failure scenarios, ValidationResult has two constructors for providing an error message and optionally a list of member names.  These constructors did not change, but the Success field was an addition.

Here is a very simple implementation of a ValidationAttribute, illustrating both success and failure.

public class IsTrueAttribute : ValidationAttribute {
    protected override ValidationResult IsValid(object value, ValidationContext validationContext) {
        if (value is bool && (bool)value) {
            return ValidationResult.Success;
        }
        else {
            return new ValidationResult("The value provided was not true");
        }
    }
}

The Validator class was updated to call GetValidationResult instead of TryValidate. Anything else that was calling TryValidate will also need to be updated, although there is no other framework code affected by this change.

Anywhere that a custom validation method was implemented, the signature will have to be updated. Conflicts will not be discoverable at run time. If you have implemented any custom validation methods, you must find those implementations and update the method signatures to match one of the new supported signatures.

CustomValidationAttribute is used to provide a Type and a Method to invoke for validation.  This is a simple mechanism for extending the validation framework to call custom validation routines, which uses a convention for the method signatures so that the referenced method can be called.

In Silverlight 3 Beta, [CustomValidation] attributes required one of the following method signatures:

public static bool MethodName([type] value) {...}
public static bool MethodName([type] value, ValidationContext context, out ValidationResult result) {...}

In the final version of Silverlight 3, the supported method signatures have been changed to the following:

public static ValidationResult MethodName([type] value) {...}
public static ValidationResult MethodName([type] value, ValidationContext context) {...}

The return type has changed, and the "out ValidationResult" parameter has been removed.

Frame only supports navigation to XAML for controls derived from Page.  Attempts to navigate to items other than pages will result in an exception.

In Silverlight 3 Beta, it was possible to navigate to XAML for a UserControl, which increased complexity and required users to know how to reach the Navigation service to get navigation-related information within that UserControl.  If this is still necessary, wrap the UserControl in a Page or use a Page as the parent class.

Previously, the way to provide a UriMapper to a Frame control was by adding it as a resource with a key of "uriMapper":

Prior to this change:

<navigation:Frame.Resources>
    <nav:UriMapper x:Key="uriMapper">
    ...
    </nav:UriMapper>
</navigation:Frame.Resource>

After the change:

The Frame control has a property named UriMapper that takes a UriMapperBase:

public static readonly DependencyProperty UriMapperProperty;public UriMapperBase UriMapper { get; set; }

Now, you can explicitly declare and specify a UriMapper, for example by binding to a resource:

<navigation:Frame UriMapper="{StaticResource uriMapper}" ...>
</navigation:Frame>

Or, you can specify it directly:

<navigation:Frame ...>
    <navigation:Frame.UriMapper>
        <nav:UriMapper>
       ...
       </nav:UriMapper>
    </navigation:Frame.UriMapper>
</navigation:Frame>

The API for UriMapper itself is unchanged.

In Silverlight 3 Beta, effects files (pixel shaders) could be packaged as Content or as Resource (Build Action = Content or Resource in the Visual Studio Properties window). Silverlight now only supports effects files packaged as Resource. (There is no change to the built-in DropShadow and Blur effects.)

To use a PS file, set its build action in Visual Studio to Resource and access it via an assembly URI of the form "<assemblyName>;component/<filename>.ps". The following shows an example of the SilverlightCustomEffect application loading GrayScaleEffect.fx.ps:

pshader = new PixelShader() { UriSource = new Uri("SilverlightCustomEffect;component/GrayScaleEffect.fx.ps", UriKind.Relative) };

The PixelFormat parameter for the WriteableBitmap constructor has been removed. WriteableBitmap(int pixelWidth, int pixelHeight, PixelFormat format) is now WriteableBitmap(int pixelWidth, int pixelHeight).

The only supported PixelFormat is now Pbgra32.

Similarly, the PixelFormat and PixelFormats type has been removed.

Lock() and Unlock() have been removed.

RenderOptions.TextRenderingOptions is now TextOptions.TextHintingMode.

Prior to this change:

    public static class RenderOptions  {
        public static DependencyProperty TextRenderingMode TextRenderingModeProperty;
    }

    public enum TextRenderingMode {
        Default = 0, 
        RenderForAnimation = 1
    }

After the change:

    public static class TextOptions {
        public static DependencyProperty TextHintingMode TextHintingModeProperty;
    }

    public enum TextHintingMode {
        Fixed = 0, 
        Animated = 1
    }

Transparent platform extensions will not be hosted on Microsoft.com. Instead they will be hosted by default on the application’s site of origin. Application developers can override this setting by editing the assembly-to-extension mapping file (<assemblyShortName>.extmap.xml) located with the assembly.

Change to the Detach method in the System.Windows.Application type.

Changes to the ExecutionStates enumeration.

Change to the ApplicationIdentity property in the Deployment element of the application manifest (AppManifest.xaml).

Moved ApplicationIdentity.Title to OutOfBrowserSettings.WindowSettings.Title.

The ExecutionStates.DetachedUpdatesAvailable value has been removed from the ExecutionStates enum (which is now the InstallState enum). Consider instead using one of the following new APIs:

• Application.CheckAndDownloadUpdateAsync() method

• Application.CheckAndDownloadUpdateCompleted event

• CheckAndDownloadUpdateCompletedEventArgs class

• CheckAndDownloadUpdateCompletedEventArgs.UpdateAvailable property

This type is typically used inside AppManifest.xaml to specify icon information for out-of-browser applications. Changes affect both XAML and programmatic usage:

• The Icon.Size property has changed from type string to type Size.

• Values "small", "medium", and "large" are no longer accepted for Icon.Size

• The XAML format is now the same as other properties of type Size. For example, "16,16" instead of "16x16".

• Icon sizes are now validated. Valid icon sizes are "16,16"; "32,32"; "48,48"; "128,128"; "256,256"; "512,512".

Example:

Before:

<Icon Size="16x16">16.png</Icon>
<Icon Size="32x32">32.png</Icon>
<Icon Size="48x48">48.png</Icon>
<Icon Size="128x128">128.png</Icon>

After:

<Icon Size="16,16">16.png</Icon>
<Icon Size="32,32">32.png</Icon>
<Icon Size="48,48">48.png</Icon>
<Icon Size="128,128">128.png</Icon>

The following methods have been removed:

• XmlConvert.IsNCNameSurrogatePair(char lowChar, char highChar)

• XmlConvert.IsStartNCNameSurrogatePair(char lowChar, char highChar)

The SaveFileDialog.File property has been removed. It has been replaced with the SaveFileDialog.SafeFileName property:

public String SafeFileName { get; }

A String that only contains the file name for the selected file. The default is Empty, which is also the value when either no file is selected or a directory is selected.

Beta Behavior:

Validator.[Try]ValidateObject would validate entity-level validation attributes regardless of the success or failure of the property-level validation attributes.

New Behavior

Validator.[Try]ValidateObject will only validate entity-level validation attributes if all property-level attributes were validated successfully.

The ASP.NET Silverlight and MediaPlayer controls have been removed from the Silverlight 3 SDK. These are contained in a server assembly named System.Web.Silverlight.dll that typically gets copied to the test Web site’s BIN folder.

<asp:silverlight ../>
<asp:mediaplayer ../>

Existing Silverlight 2 web sites will continue to work as they have the System.Web.Silverlight assembly in their Web application’s BIN folder (even if the Silverlight 2 SDK is uninstalled).

When upgrading existing projects to Silverlight 3, in most cases, you should replace these controls with the equivalent <object> tag. For <asp:silverlight>, the equivalent <object> tag is the following:

<div id="silverlightControlHost">
    <object data="data:application/x-silverlight-2," type="application/x-silverlight-2" width="100%" height="100%">
     <param name="source" value="{XAP_FILE}"/>
         <param name="onerror" value="onSilverlightError" />
         <param name="background" value="white" />
         <param name="minRuntimeVersion" value="{BUILD}" />
          <param name="autoUpgrade" value="true" />
          <a href="http://go.microsoft.com/fwlink/?LinkID=149156&v={BUILD}" style="text-decoration: none;">
               <img src="http://go.microsoft.com/fwlink/?LinkId=108181" alt="Get Microsoft Silverlight" style="border-style: none"/>
           </a>
       </object>
        <iframe id="_sl_historyFrame" style='visibility:hidden;height:0;width:0;border:0px'></iframe>
</div>

Existing Silverlight applications will continue to have the System.Web.Silverlight assembly in their Web application’s BIN folder, even if the Silverlight 2 SDK is uninstalled. Therefore upgrading to Silverlight 3 SDK will not remove this local assembly and applications should continue to work. Notionally, a developer will set the relevant version flag for Silverlight 3.

• In the client, the older fwlinks rendered should now point to Silverlight 3.

• Developers who added the System.Web.Silverlight assembly to the GAC would have to manually remove it from the GAC per the install.

Developers creating new applications will want to use the latest templates that contain the OBJECT tag and other markup.

• Developers could add the System.Web.Silverlight assembly manually and use the server controls. However, these controls will not provide the latest installation logic, or be able to render iframes for Silverlight history support for example.

Silverlight applications (old and new) will have the opportunity to respond to Browser Zoom depending on their current behavior. Silverlight applications will now zoom by default if the application does not handle the Resized event. To the application, zooming is equivalent to a RenderTransform = new ScaleTransform() being applied to the imaginary parent of the root element.

Applications may customize this behavior by using the following new APIs:

• System.Windows.Interop.Content's Zoomed event and ZoomFactor property. (Content class is usually used as App.Current.Host.Content)

• The EnableAutoZoom parameter on the Silverlight plugin

In Silverlight 2, if you have focus inside a popup and you press the TAB key, focus leaves Silverlight entirely and goes to the browser; ignoring other tab stops within the popup. The new and correct behavior in Silverlight 3 is to tab around inside the popup first. If you want the old behavior you can set TabNavigation="Cycle" on the root of your popup.

In Silverlight 2, if there is a vertical scrollbar in the ComboBox popup, and the popup is wider than the ComboBox itself, the popup is too narrow by the width of the scrollbar:

If you worked around this Silverilght 2 bug by artificially increasing the size of the ComboBox items, in Silverlight 3 there will be extra space and you may want to remove your workaround.

In Silverlight 2, Silverlight did not always redraw popups when Popup.RenderTransform was changed. This has been fixed in Silverlight 3.

Previously, if you set ContentPresenter.Content = string, and then queried ContentPresenter.ContentTemplate you would see a non-null value, the template used to display the string. Now, setting ContentPresenter.Content = string no longer changes the ContentTemplate property. This change was done so that ContentPresenter.Content could not be set again after it has been set to string.

Note that this is ContentPresenter, not ContentControl. ContentPresenter is typically used only inside control templates, as shown in the following XAML:

<ContentPresenter
  Content="{TemplateBinding Content}"
  ContentTemplate="{TemplateBinding ContentTemplate}"
  HorizontalAlignment="{TemplateBinding HorizontalContentAlignment}"
  VerticalAlignment="{TemplateBinding VerticalContentAlignment}"
  Margin="{TemplateBinding Padding}"/>

In Silverlight 2, if you give a ContentControl (such as Button) an empty ContentTemplate, the control will ignore the template and displays the content anyway using a ContentPresenter. For example, the following displays "ABC" in Silverlight 2:

  <ContentControl Content="ABC">
        <ContentControl.ContentTemplate>
            <DataTemplate></DataTemplate>
        </ContentControl.ContentTemplate>
  </ContentControl>

This has been fixed in Silverlight 3 and so the previous code now displays no content.

In Silverlight 2, setting ContentControl.Content will call OnApplyTemplate every time, even if ContentControl.ControlTemplate has been set. In Silverlight 3, OnApplyTemplate will only be called the first time if ContentControl.ControlTemplate has been set.

In Silverlight 2, if you put enums into a ComboBox (its ItemsSource property), the ComboBox will display the numeric value of the enum rather than the name of the enum. For example:

enum MyEnum { First, Second, Third }
...
MyComboBox.ItemsSource = new MyEnum[] { MyEnum.First };

This code displays "1" instead of "First". This has been fixed in Silverlight 3 so now the string value of the enum is displayed.

In Silverlight 2, when you open a ComboBox that has no selected item, the first item in the list is treated as having focus (even though it is not selected), so the first down arrow key moves both focus and selection to the second item. In Silverlight 3, when that ComboBox is opened, the first item is not considered focused. The first keydown moves selection and focus to the first item, and the second keydown moves selection and focus to the second item.

In Silverlight 2, these properties were set locally in the constructor, overriding any value from the style. This has been fixed.

In Silverlight 2, when using the default template for a ListBoxItem, the HorizontalContentAlignment was ignored. This has been fixed.

In Silverlight 2, if you set ListBoxItem.Style and then later (in code) set ListBox.ItemContainerStyle, that would erroneously override the ListBoxItem.Style you set earlier. This has been fixed.

In Silverlight 2, pressing TAB when focus is inside a ListBox moves to the next ListBox item, rather than moving focus to the next control. Now the tabbing behavior is consistent with other platforms.

For Silverilght 2, PasswordBox and TextBox had a number of [TemplatePart] attributes describing parts the control did not actually have. These attributes have been removed in Silverlight 3.

In Silverlight 2, text in TextBox did not center based upon the "document", but based upon the width property of the TextBox, This caused center rendering to be incorrect. For example, suppose that you start with centered text like the following:

In Silverlight 2, if you type a long string, the TextBox looks like the following:

In Silverlight 3, this behavior was corrected. The correct behavior is for "ABC" to be centered for the entire document, not the center of the visible portion of the document. This change does not affect the overall size of the TextBox, and if the user needs to, they can scroll the viewport to see the centered text. Nevertheless, if you counted on the previous behavior, you may want to adjust your application.

In Silverlight 2, read-only text boxes looked almost identical to editable text boxes.

If the application changes ClickMode to Press, the click handler will not be able to execute code that causes reentrancy. (Examples of code that could cause reentrancy include OpenFileDialog and SaveFileDialog.)

In Silverlight 2, if you made the slider really tall, you could click in an area that does not look like it is part of the slider, even though it is.

In Silverlight 2, an invalid URL caused the remainder of the clientaccesspolicy.xml to be ignored. This has been fixed.

In certain circumstances, Silverlight 2 would not redraw content when Opacity was changed. This has been fixed.

Silverlight data binding generally requires properties and types to be public. In Silverlight 2, there was a bug where a property with a public getter but a private setter could be data bound to. This has been fixed.

In Silverlight 2, it's possible to set the Binding.Path programmatically after using that Binding in a SetBinding call, but before DataContext is set, eg:

Binding binding = new Binding();

myElement.SetBinding(HeightProperty, binding);

binding.Path = new PropertyPath("propertyname");

myElement.DataContext = ...;

In Silverlight 3, once SetBinding has been called, the Path property may no longer be changed, so the above code needs to be changed to:

Binding binding = new Binding();

binding.Path = new PropertyPath("propertyname");

myElement.SetBinding(HeightProperty, binding);

myElement.DataContext = ...;

If Path is changed after SetBinding() is called, the Silverlight 3 behavior depends on what version of Silverlight the application was compiled against. If compiled against Silverlight 3, setting Path after SetBinding() will throw an exception. However, to reduce the chance of breaking Silverlight 2 applications, if the .xap is built against Silverlight 2 setting Path after SetBinding() will be silently ignored and the old Path will be used (see also discussion of "quirks mode" in section 5).

For security reasons, OpenFileDialog.ShowDialog() may only be called during a user initiated event (MouseLeftButtonDown/Up and KeyDown/Up) or derived user event like clicking a button or checking a check box. This makes Silverlight behave in the same way as other major browsers and plug-ins.

In Silverlight 2, there was a bug associated with tabbing over the last control on the page. As a side effect of fixing this bug, the tabbing processing and associated callbacks, like the GotFocus event, were changed from asynchronous to synchronous. (Where "asynchronous" really means PostMessage. It happens on the same thread after the current message has been processed.) This is a breaking change because during an asynchronous event in Silverlight, you cannot call into the HTML DOM. This is the Silverlight version of WPF's unexpected reentrancy guard. In quirks mode, applications continue to get asynchronous tab processing that does not work very well for the last control on the page.

Suppose that you have an element inside a pop-up that listens to mouse events:

        <Popup>
            <Border Name="border" MouseLeftButtonDown="OnMouseLeftButtonDown"/>
        </Popup>

void OnMouseLeftButtonDown(object sender, MouseButtonEventArgs e)
{
    ...  e.GetPosition(border) ...
}

In Silverlight 2, the coordinates from MouseButtonEventArgs.GetPosition will be relative to the entire Silverlight plug-in, even though the application asked for coordinates relative to the border control (the parameter to GetPosition is supposed to indicate the frame of reference). This has been fixed in Silverlight 3.

In Silverlight 2, under certain circumstances a Popup can actually have two parents. Silverlight 3 allows only a single parent for Popup.

Silverlight 2 had several bugs where named items inside a Popup were put in the wrong namescope when Popup.Child was its own namescope (for example, child was created with XamlReader.Load). This resulted in FindName() and Storyboard.TargetName finding elements that should not have been found (because Silverlight looked in the wrong name scope), and not finding elements that should be found. In some cases, FindName() would find elements that had been removed from the tree. This has been fixed in Silverlight 3. The correct name scope behavior is when Popup is added to the live tree, and Popup.Child is not a namescope owner, the popup children become part of the popup parent's name scope. Otherwise, popup’s children live in a namescope attached to Popup.Child.

In Silverlight 2, FindElementsInHostCoordinates would not look inside Popup’s. This has been fixed.

In Silverlight 2, replacing items in ItemsControl generates three events: Remove, Add, and Replace. This is not compatible with WPF and it is hard to code against. When you receive the remove and add events, you do not know if it is really a replace that is about to follow. In Silverlight 3, only the Replace event occurs.

As a result, the Width and Height of content inside a ScrollViewer will be zero until the layout pass is complete.

In Silverlight 2, if Stretch != UniformToFill and Height or Width was not set on a Rectangle or Ellipse within a ContentControl, then the object was not rendered. In Silverlight 3, if the Stretch property of a Rectangle or Ellipse is other than None, the object will be rendered.

In Silverlight 2, if you let PasswordBox, TextBlock and TextBox autosize themselves, they will truncate the final character if the natural width of the text is not a whole number and the fractional part of that is less than .5. For example, text which measures to 96.34 units wide will get rounded down to 96.00, and the TextBlock does not have enough space to display the text. Now the width is rounded up but this could potentially affect the layout of your applications.

In Silverlight 2, textblock.FontFamily = null throws a NullRefException. Now it throws ArgumentNullException.

Inside a template, Silverlight 2 implicitly inserted a space between elements, so <TextBlock><Run Text="Hel"/><Run Text="lo"/></TextBlock> would have a space between "Hel" and "lo". In Silverlight 3, this space is no longer rendered.

In Silverlight 2, if you use RadioButton.GroupName inside a template, Silverlight only looks inside that template for RadioButtons with the same group name. This is different from WPF and makes it difficult to perform a lot of useful scenarios. So in Silverlight 3, the RadioButton searches outside the template as well.

In Silverlight 2, the selected item inside a ComboBox will receive mouse events. This interfered with ComboBox displaying correct visuals for mouse over state, so ComboBox will now set IsHitTestVisible="false" on the ContentPresenter inside its control template. ComboBox itself continues to get mouse events.

In Silverlight 2, the Opacity property was ignored (always treated as 1). This has been fixed.

In Silverlight 2, the FrameworkElementAutomationPeer ctor with a null parameter threw a NullReferenceException. Now this throws an ArgumentNullException.

In Silverlight 2, HyperlinkButton behaved inconsistently across browsers. In Internet Explorer, HyperlinkButton navigated the entire browser, not just the current IFrame.

In other browsers, HyperlinkButton navigates only the current IFrame, which is consistent with HTML behavior. In Silverlight 3 Beta, the behavior inside Internet Explorer was changed to match the behavior in other browsers.

With the Silverlight 2 plug-in, if you renamed a .xap file to have a different extension, Silverlight erroneously thought the application was designed for Silverlight 1, and Silverlight ran it in version 1 compat mode. One impact was the base URI was considered to be the HTML page, not the (renamed) .xap. Another impact was that the default font was different from a .xap. This has been fixed.

In Silverlight 2, if the URL the .xap was loaded from contained a query string, Application.Current.Host.Source could return a relative URL.  In Silverlight 3, this has been fixed and Application.Current.Host.Source always returns an absolute URL.  The URL of the .xap is typically specified as a <param> within the <object> tag, the following is an example of a .xap URL with a query string:

<param name="source" value="Bin/Debug/bug24857.xap?a=b"/>

In Silverlight 2, if you put an enum into a ResourceDictionary and take it out again, you get back an object of type Integer32 rather than something of the expected enum type. This has been fixed for Silverlight 3.

The ReadOnlyObservableCollection class has been moved into System.Windows.dll so that other APIs in System.Windows.dll can use it. In order to minimize download size impact, some uncommonly used methods were removed.

Note that this will not affect applications compiled for Silverlight 2. If you use ReadOnlyObservableCollection in Silverlight 2, your .xap file will contain a copy of System.Windows.Controls.Data.dll. When Silverlight 3 Beta runs your .xap, it will use the .xap's copy of System.Windows.Controls.Data.dll and that version of ReadOnlyObservableCollection, not the version that ships in the System.Windows.dll of Silverlight 3 Beta.

There was no event that returns this EventArgs, so it was removed. DataGridCellEditEndingEventArgs, DataGridCellEditEndedEventArgs, DataGridRowEditEndingEventArgs, and DataGridRowEditEndedEventArgs have been added in Silverlight 3.

PollingDuplexHttpBinding now derives from HttpBinding instead of BasicHttpBinding. PollingDuplexHttpBinding now uses SOAP 1.2 instead of 1.1. As a result, Silverlight 3 PollingDuplexHttpBinding will not work with ASP.NET servers running the Silverlight 2 version of System.ServiceModel.PollingDuplex.dll.

Normally, when you remove an event listener (-= in C#), you remove a particular delegate for a particular event. Silverlight 2 ignored the event part. For example, "object.SomeEvent -= SomeMethod" would remove all event listeners tied to the SomeMethod method, including events other than SomeEvent. In Silverlight 3 this has been fixed.

In Silverlight 2, the following was allowed:

<DiscreteObjectKeyFrame.Value>
    <Cursors>Hand</Cursors>  <! -------note plural -->
</DiscreteObjectKeyFrame.Value>

This was incorrect because the name of the type is Cursor not Cursors. Silverlight 3 only allows <Cursor>.

In Silverlight 2, the following illegal XAML was accepted by Silverlight:

<local:MyControl MyControl.DesignerID="12" />

This has been fixed in Silverlight 3. The correct XAML uses an XML prefix on the attached property:

<local:MyControl local:MyControl.DesignerID="12" />

In Silverlight 2, under certain conditions, if class A is defined in one user assembly, and markup inherits from class B in a different user code assembly, Application.LoadComponent(A) will try to load XAML from B's assembly instead of A's assembly. This has been fixed.

Silverlight 2 data binding is inconsistent about how it handles nulls. If you specify Path=a.b.c.d and a, b, or c is null, Silverlight 2 calls the value converter. However, if you specify Source=null, that does not call the value converter, even though it logically means the same thing. Silverlight 3 will always call the value converter.

Suppose the HTML page and the xap file are in different directories (e.g. http://example.com/ and http://contoso.com/ClientBin/), and you have a relative URL to a resource (eg images/myImage.jpg) that is not contained within the xap file. Silverlight 2 would interpret that URL relative to the HTML page's location (http://contoso.com/images/myImage.jpg). In order to make it easier to move Silverlight apps to different locations, Silverlight 3 interprets the URL relative to the .xap’s location (http://contoso.com/ClientBin/images/myImage.jpg).

In Silverlight 2, it is possible to programmatically set various properties on Binding between when SetBinding() is called, but before DataContext is set. For example:

Binding binding = new Binding();

myElement.SetBinding(HeightProperty, binding);

binding.SomeProperty = value;

myElement.DataContext = ...;

Different properties had different behaviors in Silverlight 2:

• Converter, ConverterParameter, ConverterCulture, NotifyOnValidationError, and ValidatesOnExceptions properties would retroactively change the binding established with SetBinding().

• Mode and Source properties would be ignored (their values were copied when SetBinding() was called)

Silverlight 3 throws an exception if these properties are changed after SetBinding() is called.  (Silverlight 2 will throw a similar exception if these properties are changed after DataContext is set)

In Silverlight 2, under certain circumstances the content (child element) inside a ContentPresenter can actually have two parents, because the content has been added to a second ContentPresenter without removing it from the first ContentPresenter.  Silverlight 3 will throw an exception if an element is added to a second parent without removing it from the first parent.

This is most noticeable if the parent element is moving as a result of the drag.

Who Is Affected: Silverlight 2 applications that depend on the DataGrid selecting the first item by default.

Summary

Based on customer feedback, the DataGrid no longer selects the first item by default, which matches the behavior of other list based controls like the ListBox.  Now, the DataGrid’s current item is by default the first item, but that item is not selected.  Tabbing in to the DataGrid causes the current item to be selected.  The DataGrid will, however, select an ICollectionView’s current item by default if its ItemsSource is set to an ICollectionView implementation.  This is consistent with the ListBox and consistent with other consumers of ICollectionView, and it also supports the master/details scenario via CollectionView.

Fix Required

Silverlight 2 users depending on the DataGrid to select the first item by default now need to explicitly set the SelectedItem or the SelectedIndex after setting the ItemsSource.