Visually Located

XAML and GIS

Migrating from the Windows Phone Toolkit ContextMenu to the new Runtime MenuFlyout

This is part of a series on migrating from the WP Toolkit.

With the release of the new Windows Phone 8.1 Runtime (aka XAML) apps comes a heap of new controls. Many of these controls were only available through third party control libraries. One of these controls was the ContextMenu. In Windows Phone Silverlight apps (even 8.1) displaying a context menu requires another library. One of the most popular (and free) libraries is the Windows Phone Toolkit. If you are used to using the ContextMenu from the toolkit you may be wondering how to show a context menu in Windows Phone Runtime apps.

Previously you would generally add a ContextMenu to your items in XAML like such (this example assumes context is set in an item template of a list.

<toolkit:ContextMenuService.ContextMenu >
    <toolkit:ContextMenu>
        <!-- using the Click event -->
        <toolkit:MenuItem Header="reply" Click="OnReplyClicked"/>
        <!-- using commanding to DataContext of MenuItem -->
        <toolkit:MenuItem Header="retweet" Command="{Binding RetweetCommand}"/>
        <!-- using commanding to DataContext of parent list -->
        <toolkit:MenuItem Header="favorite"
                          Command="{Binding DataContext.FavoriteCommand, 
                                    ElementName=TweetList}"
                          CommandParameter="{Binding}"/>
    </toolkit:ContextMenu>
</toolkit:ContextMenuService.ContextMenu>

The above example shows how you can use the toolkit to display a ContextMenu when an item is tapped and held. It has three different items all behaving differently. One responds to the Click event and the other two using commanding. The two commanding items bind to different DataContext objects. One item (the retweet item) uses the command, RetweetCommand, which is on the item (model) it is bound to. The other item (favorite) binds to the ListBox that it is contained within. I generally use the first and last examples when building context menus. I rarely find a need to put a command on a model.

You could also create and open a context menu in code-behind if you wanted.

contextMenu = new ContextMenu();
// this example does not respond to an item selected, only a sample
contextMenu.Items.Add(new MenuItem { Header = "retweet"});
 
// Have to set the owner!
contextMenu.Owner = element;
contextMenu.IsOpen = true;

Windows Phone 8.1 Runtime apps brings the MenuFlyout for showing a context menu in your apps. The MenuFlyout is a FlyoutBase object which means you can place it on anything that has a Flyout dependency property like a button. If the control you want to place it on does not have a Flyout DP, no problem because there is also the AttachedFlyout attached DP on FlyoutBase. Adding the MenuFlyout to an item template is very similar to how we did it in the WP toolkit, but there are some things still missing.

<StackPanel>
    <FlyoutBase.AttachedFlyout>
        <MenuFlyout>
            <!-- using the Click event -->
            <MenuFlyoutItem Text="reply" Click="OnReplyClicked"/>
 
            <!-- using commanding to DataContext of MenuItem -->
            <MenuFlyoutItem Text="retweet" Command="{Binding RetweetCommand}"/>
 
            <!-- using commanding to DataContext of parent list -->
            <MenuFlyoutItem Text="favorite"
                            Command="{Binding DataContext.FavoriteCommand, 
                                      ElementName=TweetList}"
                            CommandParameter="{Binding}"/>
        </MenuFlyout>
    </FlyoutBase.AttachedFlyout>
 
    <!-- Content for you template -->
</StackPanel>

Looks like the toolkit code for the most part. If you build an app with this and tap and hold an item you will notice that the menu does not open. I said above there are some things missing, this is one of them, and it’s a big one! We now have a context menu built into the controls, but it won’t show. To show the menu, we need to subscribe to the Holding event of the element the menu will be attached to.

<StackPanel Holding="OnElementHolding">
    <FlyoutBase.AttachedFlyout>
        <!-- MenuFlyout -->
    </FlyoutBase.AttachedFlyout>
    <!-- content -->
</StackPanel>

In the event handler we can show the menu.

private void OnElementHolding(object sender, HoldingRoutedEventArgs args)
{
    // this event is fired multiple times. We do not want to show the menu twice
    if (args.HoldingState != HoldingState.Started) return;
 
    FrameworkElement element = sender as FrameworkElement;
    if (element == null) return;
 
    // If the menu was attached properly, we just need to call this handy method
    FlyoutBase.ShowAttachedFlyout(element);
}

Here is an example using the Pivot App project template

MenuFlyout

So there you have it. But wait. This is not acceptable. I am not going to add a holding event to all of the items and pages that I want to show a context menu. 

I really liked the ContextMenuSerice from the WP Toolkit. It was easy to use, little xaml required, just got to the point. Why don’t we create a MenuFlyoutService that works the same way the ContextMenuService did? 

The first step is to add a new file to Visual Studio named MenuFlyoutService. Then copy the source for the [class only] ContextMenuService. Paste the class into your file and find/replace ContextMenu for MenuFlyout. Happy news, most of the work is already done! Last thing we need to do is attach a menu to the element and subscribe to the Holding event. We’ll make all of our changes within the new OnMenuFlyoutChanged method. Any new line below are shown with comments.

private static void OnMenuFlyoutChanged(DependencyObject o, DependencyPropertyChangedEventArgs e)
{
    var element = o as FrameworkElement;
    if (null != element)
    {
        // just in case we were here before and there is no new menu
        element.Holding –= OnElementHolding;
 
        MenuFlyout oldMenuFlyout = e.OldValue as MenuFlyout;
        if (null != oldMenuFlyout)
        {
            // Remove previous attachment
            element.SetValue(FlyoutBase.AttachedFlyoutProperty, null);
        }
        MenuFlyout newMenuFlyout = e.NewValue as MenuFlyout;
        if (null != newMenuFlyout)
        {
            // attach using FlyoutBase to easier show the menu
            element.SetValue(FlyoutBase.AttachedFlyoutProperty, newMenuFlyout);
 
            // need to show it
            element.Holding += OnElementHolding;
        }
    }
}

The holding event handler is the same handler that we created above. Now our xaml will need to change to match our new MenuFlyoutService

<StackPanel>
    <local:MenuFlyoutService.MenuFlyout>
        <MenuFlyout>
            <!-- using the Click event -->
            <MenuFlyoutItem Text="reply" Click="OnReplyClicked"/>
 
            <!-- using commanding to DataContext of MenuItem -->
            <MenuFlyoutItem Text="retweet" Command="{Binding RetweetCommand}"/>
 
            <!-- using commanding to DataContext of parent list -->
            <MenuFlyoutItem Text="favorite" 
                            Command="{Binding DataContext.FavoriteCommand, 
                                      ElementName=TweetList}"
                            CommandParameter="{Binding}"/>
        </MenuFlyout>
    </local:MenuFlyoutService.MenuFlyout>
 
    <!-- content for template -->
</StackPanel>

And now we are able to show a MenuFlyout (aka context menu) whereever we want. No extra code needed in our pages that wasn’t there before. We can even copy/paste find/replace from old WP Silverlight apps to new Runtime apps pretty easily.

You can download a sample app using the MenuFlyoutService.

Migrating from the Windows Phone Toolkit ListPicker to the new XAML ComboBox (Display a ListPicker in XAML apps)

This is part of a series on migrating from the WP Toolkit.

With the release of the new Windows Phone 8.1 XAML (Runtime) SDK comes a lot of new controls that were previously only available in the Windows Phone Toolkit. One of these controls in the ComboBox. Well, this control isn’t new, but now it works as one would expect. In Windows Phone 8, the ComboBox displayed more of a ListBox than a ComboBox. It would display all items and not a dropdown. Getting the drop down like functionality required you to use a third party control like the Windows Phone Toolkit ListPicker control. This control would have a dropdown if the number of items was limited, and would show full screen for large number of items. The new ComboBox helps us scratch an itch, but it does not match up to the ListPicker from the toolkit. Before we get into the things the ComboBox does not do, let’s get into the things is does do, and how you can modify your code to start using the ComboBox if you are used to using the ListPicker.

The ComboBox works great for the scenario where you have a list of text you want to show. It works great when the content you want to show will be the same in the three states of the control.

image     image     image

In the above examples the content is displayed the same in all three states, collapsed, expanded (dropdown open), and full screen.

Let’s assume you were displaying something like this in a Windows Phone 7 or 8 app and that you used the ListPicker. If you do have this simple scenario, then all you need to do s swap “toolkit:ListPicker” for “ComboBox” in your XAML.

<!-- from -->
<toolkit:ListPicker Header="List Picker" ItemsSource="{Binding Items}">
    <toolkit:ListPicker.ItemTemplate>
        <DataTemplate>
            <TextBlock Text="{Binding Name}"/>
        </DataTemplate>        
    </toolkit:ListPicker.ItemTemplate>
</toolkit:ListPicker>
 
<!-- to -->
<ComboBox Header="Combo picker" ItemsSource="{Binding Items}">
    <ComboBox.ItemTemplate>
        <DataTemplate>
            <TextBlock Text="{Binding Name}"/>
        </DataTemplate>
    </ComboBox.ItemTemplate>
</ComboBox>

With both controls, if the count of the items is six or more, it would expand to full screen.

You can get a little complex with the CombBoBox ItemTemplate. If you wanted to display colors with their text you could set the ItemTemplate to the following:

<StackPanel Orientation="Horizontal">
    <Rectangle Width="20" Height="20" >
        <Rectangle.Fill>
            <SolidColorBrush Color="{Binding Color}" />
        </Rectangle.Fill>
    </Rectangle>
    <TextBlock Text="{Binding Name}" Margin="12,0"/>
</StackPanel>

 

image     image

That’s about it for the simple use cases. Now, where the ComboBox falls short of the ListPicker

  1. No way to set that it should expand to full screen only (ExpansionMode from ListPicker)
  2. No way to set a template when in full screen (FullModeItemTemplate from ListPicker)
  3. No way to set the header when in full screen (FullModeHeader from ListPicker)
  4. No way to set the number of items the ComboBox should contain before showing in full screen (ItemCountThreshold from ListPicker)
  5. Cannot have a picker that is only shown in full screen (does not display the “button”). This is useful when you want to display a picker based on clicking an app bar button

We can work through most of these shortcomings, but it requires some extra work. To show some workarounds for the above items, we’ll work to create a ListPicker that will display the following no matter how many items are in the collection.

image    image

It’s important to note that we will not be using the ComboBox to display the above. With this sample we will cover items 1, 2, and 3. To display a custom picker, we’ll start with a standard button and set it’s Flyout to be a ListPickerFlyout. The button will need to be stretched and the content needs to display on the left, so we need to set the HorizontalAlignment and HorizontalContentAlignment property.

<Button HorizontalAlignment="Stretch" HorizontalContentAlignment="Left">
    <Button.Flyout>
        <ListPickerFlyout >
        </ListPickerFlyout>
    </Button.Flyout>
</Button>

When the button is tapped, it will open the flyout that is set. The ListPickerFlyout works just like an Selector control. It has an ItemsSource, SelectedItem, SelectedIndex and more. However, instead of a SelectedItemChanged event, it has a ItemsPicked event. The ListPickerFlyout is not a control so you cannot place it in the visual tree like you would a ListBox,, TimePicker, etc. Instead it can only be set within a Flyout property. It is a DependencyObject, so you can use binding with it.

We’ll setup the ListPickerFlyout to display our custom header and custom template

<ListPickerFlyout Title="SELECT CITY" ItemsSource="{Binding Items}"
                  SelectedItem="{Binding SelectedCity, Mode=TwoWay}">
    <ListPickerFlyout.ItemTemplate>
        <DataTemplate>
            <StackPanel>
                <TextBlock Text="{Binding City}" FontSize="{StaticResource TextStyleExtraLargeFontSize}"/>
                <TextBlock Text="{Binding State}" FontSize="{StaticResource TextStyleLargeFontSize}"/>
                <TextBlock Text="{Binding TimeZone}" FontSize="{StaticResource TextStyleMediumFontSize}"/>
            </StackPanel>
        </DataTemplate>
    </ListPickerFlyout.ItemTemplate>
</ListPickerFlyout>

Now we’ll need to set the content of the button to display the the selected city.

<TextBlock DataContext="{Binding SelectedCity}">
    <Run Text="{Binding City}"/><Run Text=","/>
    <Run Text="{Binding StateAbr}"/>
</TextBlock>

So the complete XAML for our custom ListPicker is:

<Button HorizontalAlignment="Stretch" HorizontalContentAlignment="Left">
    <TextBlock DataContext="{Binding SelectedCity}">
        <Run Text="{Binding City}"/><Run Text=","/>
        <Run Text="{Binding StateAbr}"/>
    </TextBlock>
    <Button.Flyout>
        <ListPickerFlyout x:Name="CityPicker" Title="SELECT CITY" ItemsSource="{Binding Items}"
                          SelectedItem="{Binding SelectedCity, Mode=TwoWay}">
            <ListPickerFlyout.ItemTemplate>
                <DataTemplate>
                    <StackPanel>
                        <TextBlock Text="{Binding City}" FontSize="{StaticResource TextStyleExtraLargeFontSize}"/>
                        <TextBlock Text="{Binding State}" FontSize="{StaticResource TextStyleLargeFontSize}"/>
                        <TextBlock Text="{Binding TimeZone}" FontSize="{StaticResource TextStyleMediumFontSize}"/>
                    </StackPanel>
                </DataTemplate>
            </ListPickerFlyout.ItemTemplate>
        </ListPickerFlyout>
    </Button.Flyout>
</Button>

Unlike the ComboBox, the Button does not have a Header property, so if you want to display a header for the picker you will need to add one.

<StackPanel>
    <TextBlock Text="Expanding picker" 
               Foreground="{StaticResource PhoneMidBrush}"
               FontSize="{ThemeResource TextStyleMediumFontSize}"
               Margin="0,0,0,-4.5" />
    <Button />
</StackPanel/>

Not to much work, and we were able to solve the following drawbacks of the ComboBox

  1. SOLVED: No way to set that it should expand to full screen only (ExpansionMode from ListPicker)
  2. SOLVED: No way to set a template when in full screen (FullModeItemTemplate from ListPicker)
  3. SOLVED: No way to set the header when in full screen (FullModeHeader from ListPicker)

Which leaves us with the following items unsolved

  1. No way to set the number of items the ComboBox should contain before showing in full screen (ItemCountThreshold from ListPicker)
  2. Cannot have a picker that is only shown in full screen (does not display the “button”). This is useful when you want to display a picker based on clicking an app bar button

Unfortunately there is no way to solve number 1 without writing your own ComboBox, I won’t go into that as I don’t see this item being a big deal. We can solve the last one. In Windows Phone 8 you could put a button (or a menu item) in the app bar and when it was tapped, show a ListPicker. Take the example of a share button in your app. I would solve this by doing the following:

<toolkit:ListPicker x:Name="SharePicker" 
                    ExpansionMode="FullScreenOnly"
                    Visibility="Collapsed"
                    FullModeHeader="SHARE"
                    SelectionChanged="SharePickerSelectionChanged">
    <toolkit:ListPicker.FullModeItemTemplate>
        <DataTemplate>
            <TextBlock Margin="0,20" Text="{Binding Name}" 
                       Style="{StaticResource PhoneTextExtraLargeStyle}" />
        </DataTemplate>
    </toolkit:ListPicker.FullModeItemTemplate>
</toolkit:ListPicker>

Notice that the ExpansionMode is FullScreenOnly and the Visibility is Collapsed. This would hide the button look of the picker, but would still allow it to be shown when the Open method is called.

private void OnShareButtonClick(object sender, EventArgs e)
{
    SharePicker.Open();
}

Pretty simple, but you cannot accomplish this with the ComboBox. Once again you can accomplish this the ListPickerFlyout. You’ll want to define the ItemTemplate in the resources of the page so that it can be accessed from your code. When the button is clicked, show a picker.

private void OnAppBarButtonClick(object sender, RoutedEventArgs e)
{
    var picker = new ListPickerFlyout();
    picker.ItemsSource = Items;
    picker.ItemTemplate = (DataTemplate)Resources["PickerTemplate"];
    picker.ItemsPicked += OnItemsPicked;
    picker.ShowAt(this);
}

Even though the ComboBox does not do as much as the ListPicker did, we are able to easily get those missing items accomplished!

Migrating from the Windows Phone Toolkit TimePicker to the new Runtime TimePicker

This is part of a series on migrating from the WP Toolkit.

The release of Windows Phone 8.1 comes a load of new controls for Runtime (aka XAML) apps. One of these new controls is the TimePicker. This control was previously only available in toolkits like the Windows Phone Toolkit, Coding4Fun or paid versions like Telerik. If you were using on of these version, you can easily move to the new TimePicker in the runtime. This post will focus on moving from the WP Toolkit version.

The TimePicker is part of the new core controls, so you no longer need a namespace prefix.

<!-- from -->
<toolkit:TimePicker/>
 
<!-- to -->
<TimePicker/>

Setting the time value on the TimePicker is done through the Time property. This was previously done through the Value property in the WP Toolkit version. The property is now a TimeSpan rather than a DateTime from the toolkit.

<!-- from -->
<toolkit:TimePicker Value="{Binding Date}” />
 
<!-- to -->
<TimePicker Time="{Binding Time}"/>

If you have a DateTime property already, then bind to the TimeOfDay property of the date.

<TimePicker Time="{Binding Date.TimeOfDay}"/>

Like most of the new runtime (aka XAML) controls, it has a Header property to display what the time represents.

<TimePicker Header="Time" Time="{Binding Date.TimeOfDay}"/>

When the time changes for the picker, it will fire the TimeChanged event. This is different from the ValueChanged in the WP Toolkit.

Once again there are not side margins for the control. You will need to add any margins to ensure it fits your page appropriately. If you margins in your root grid, then you will not need any additional margins.

The new TimePicker has two new great properties. The first is the MinuteIncrement property. This property allows you to specify how many minutes the picker is allowed to be incremented by. This value can be set from 0 to 59. A value of 0 states that only the hour can change while a value of 30 states that the hour can change and the minute value can be either 0 or 30.

increment-0          increment-30

The second new property is the ClockIdentifier property. This allows you to specify if the clock should show a 12 or 24 hour clock. Rather than being an enumeration, this property is a string. It only allows the values 12HourClock and 24HourClock.

<TimePicker Header="12HourClock" ClockIdentifier="12HourClock"/>
<TimePicker Header="24HourClock" ClockIdentifier="24HourClock"/>
image

Like the DatePicker, the new TimePicker does not have a way to format the value as it did in the WP Toolkit. In the below example you could format a TimePicker, in the WP Toolkit, to display with seconds, or with AM/PM, etc..

<toolkit:TimePicker Header="With AM/PM" 
                    Value="{Binding Time}"
                    ValueStringFormat="{}{0:hh:MM tt}"/>
<toolkit:TimePicker Header="With seconds"
                    Value="{Binding Time}"
                    ValueStringFormat="{}{0:hh:MM:ss}"/>

image

Once again we can hope that this will be added.

Migrating from the Windows Phone Toolkit DatePicker to the new Runtime DatePicker

This is part of a series on migrating from the WP Toolkit

With the release of the new Windows Phone 8.1 SDK comes new controls that previously were only available in the Windows Phone Toolkit. One of these controls is the DatePicker. The new DatePicker is a nice addition to the SDK and something people have been asking for since the beginning.

The DatePicker is part of the core controls, so you no longer need a namespace prefix

<!-- from -->
<toolkit:DatePicker/>
 
<!-- to -->
<DatePicker/>

To set the Date on the DatePicker, you use the Date property rather than the Value property from the toolkit. And of course the Date property allows for binding.

<!-- from -->
<toolkit:DatePicker Value="{Binding Date}” />
 
<!-- to -->
<DatePicker Date="{Binding Date}"/>

It still has a Header property allowing you to place a label for what the date represents

<DatePicker Header="Date" Value="{Binding DateValue}"/>

image

Like other Runtime (aka XAML) controls, the DatePicker does not have the same margins as the toolkit version. If you want to do a direct replacement, you add a left and right margin of 9.5 (assuming it is contained within an element that also has a 9.5 side margin).

<DatePicker Margin="9.5,0"/>

To match the Date property, the event you want to listen to for the date changing is the DateChanged event. This replaces the ValueChanged event from the toolkit. The event gives you event args with the old and new values.

The DatePicker has some awesome properties to format date values, but they do not work in Windows Phone Apps. The docs has a few samples listed that allow you to format different parts of the date.

<!-- DatePicker formatted using format templates. -->
<DatePicker DayFormat="day" MonthFormat="month.numeric" YearFormat="year.abbreviated"/>
 
<!-- DatePicker formatted using format patterns. -->
<DatePicker DayFormat="{}{day.integer}" MonthFormat="{}{month.integer}" YearFormat="{}{year.abbreviated}"/>
 
<!-- combines 2 format patterns to display both the numeric date and the day of the week -->
<DatePicker DayFormat="{}{day.integer} {dayofweek.abbreviated}"/>

When adding these three samples we get the following from Windows and Windows Phone.

image            image

You can set the MinYear and MaxYear that is allowed for the DatePicker, but unfortunetly, that’s it. I would prefer the ability to have a Min and MaxValue allowing me to restrict every part of the date from day, month, and year. It does however come with a great new property, CalendarIdentifier. This new property allows you to set what calender system should be used. It has nine supported values. Adding each calendar to a page gives us the following.

image

One property that was lost is the ValueStringFormat from the Windows Phone Toolkit DatePicker. This property allowed you to format how the date was displayed. Here is an example of two DatePickers from the Toolkit. The top one has no formatting while the bottom does.

<toolkit:DatePicker Header="Default"/>
<toolkit:DatePicker Header="Formatted" ValueStringFormat="{}{0:dd-MM-yyyy}"/>

image

I’m hoping the ability to change the format will return.

Migrating from the Windows Phone Toolkit ToggleSwitch to the new XAML ToggleSwitch

This is part of a series on migrating from the WP Toolkit.

The new Windows Phone 8.1 XAML SDK comes with new controls that previously were only in the Windows Phone Toolkit. One of these controls in the ToggleSwitch. The new ToggleSwitch control is really nice. The team has made some great improvements to this control.

Migrating to the new control is pretty easy. Along with all of the new controls, you no longer need to declare a namespace when using the control in XAML.

<!-- from -->
<toolkit:ToggleSwitch/>
 
<!-- to -->
<ToggleSwitch/>
 

Instead of IsChecked, you’ll use the IsOn property.

<!-- from -->
<toolkit:ToggleControl IsChecked=”True/>
 
<!-- to -->
<ToggleControl IsOn=”True/>

The IsOn property is still a dependency property, so you can use binding as well.

<ToggleControl IsOn=”{Binding SomeSetting}”/>

The toolkit ToggleControl has built in Margins designed for use within a Phone app. The new XAML ToggleControl does not have any Margins defined. This is the case for all of the XAML controls. For a direct replacement you will have to add the margins in.

<ToggleControl Margin="9.5,5,9.5,33.6"/>

The new ToggleSwitch comes a few new properties. Four of these new properties allow you to control the “On” and ”Off” content. With the toolkit ToggleSwitch controlling the On/Off content was not that easy. The new OnContent and OffContent allow you to control the text to display when the switch is on or off. So if you wanted to display “true” and “false” you could do the following.

<ToggleSwitch OnContent=”trueOffContent=”false/>
image            image

The ToggleSwitch also comes with two properties for the template to use for the on and off content. If for some reason you wanted to display an image, you could set the templates to do just that.

<DataTemplate x:Key=”ImageToggleContent> 
    <Image Source=”{Binding}” Stretch="None"/> 
</DataTemplate>
 
<!-- Other xaml -->
<ToggleSwitch OnContent=”Assets/On.pngOffContent=”Assets/Off.png
              OnContentTemplate=”{StaticResource ImageToggleContent}” 
              OffContentTemplate=”{StaticResource ImageToggleContent}”/> 
 

image            image 

Replacing the four previous events is one simple Toggled event. I like this change as it is the one stop location for being notified of state change. Having Checked, Unchecked, etc. events just adds bloat.

There you go, easy to move over to the new ToggleSwitch and you get some nice new features to boot!

Migrating from the Windows Phone Toolkit to the new Runtime XAML controls

With the introduction of the new Windows Phone XAML Apps, Microsoft released new controls that previously only existed in the Windows Phone Toolkit. For any years these controls existed in open source format, but did not allow for contributions. These controls would get some bug fixes, or new functionality/controls every now and then. Ownership of the toolkit changed hands many times and the toolkit was mostly forgotten.

There was often complaints from the community that Microsoft would put “must have controls” in a toolkit. I personally liked that these controls were in a toolkit in which I could see the source. It allowed me to learn from  the people that know the core code the best.

Sidebar: Take advantage of open source software. Contribute or not, it is a great learning tool.

A nice thing about it being open was that you could fix bugs that you found. While the source was open, contributions were closed, so you could not submit bug fixes are add features to the toolkit. However, it was possible for bug fixes to come out at any time from the Windows team. With the transition to the new XAML platform, source will be closed. This means that you will not be able to fix any bugs that you find. You will have to submit a Connect ticket and hope it gets fixed in the next update of Visual Studio.

The new  SDK comes with replacements or the following controls that were previously only in the Windows Phone Toolkit. I’ll walk through each one showing how to replace code that used the toolkit version with the new XAML controls.

ToggleSwitch

DatePicker

TimePicker

ListPicker

ContextMenu

Transitions