Visual Studio 2010 Beta 2 is available now. For Silverlight developers, the most exciting news about VS2010 is that Silverlight designer will be in feature parity with WPF designer, and VS2010 will support multi-targeting for Silverlight development. Silverlight Toolkit team has been working closely with Cider team in providing the design time experience for Silverlight SDK and Toolkit controls. The design time for Silverlight 3 SDK controls has been released with SL3 SDK in August 2009, and is also chain installed by VS2010 Beta2. The design time for Toolkit controls, together with sources for both SDK and Toolkit controls, and their design time, samples, unit tests etc, are in Silverlight Toolkit October 2009 Release. We purposely made October 2009 release to be in sync with Visual Studio 2010 Beta 2 on Monday, 10/19/2009. This post demonstrates the new design time experiences for Silverlight controls in VS2010. 

Install

VS2010 installs side by side with VS2008. Multiple releases of Toolkit install side by side too. So it is perfectly safe to install VS2010 and Toolkit October 2009 release on your main machine. The only caveat is that if you have a pre August 2009 version of Silverlight 3 SDK installed, you will need to uninstall it first, before installing VS2010. You can install VS2010 Beta2 from http://msdn.microsoft.com/en-us/vstudio/dd582936.aspx, and Silverlight Toolkit from http://silverlight.codeplex.com.

Walkthrough

The October 2009 release is for Silverlight 3 only. It provides design time support for both VS2008 and VS2010, as well as Blend 3. Below walkthrough will be VS2010 only. Design time experience for VS2008 and Blend 3 are similar to July 2009 release. Please see my previous posts for design time experience with VS2008 and Blend3.

• Create a new Silverlight Application project in VS2010, notice that:
  
  • the toolbox is populated with both SDK and Toolkit controls, with nice icons. If you have Blend3 installed before Toolkit, you may see a lot of Blend controls on the toolbox that are not supposed to. You can safely remove them by right click a control in the toolbox and select delete.
  • it is a real designer: both the design view and the properties window work!
• double click TabControl in the toolbox will add a tabControl1. Notice that:
  
  • A reference to System.Windows.Controls.dll is added, together with a xmlns definition: xmlns:controls="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls"
  • tabControl1 is initialized with a tabItem1, which itself is initialized with a header and <Grid/> content. (via DefaultInitializer)
  • Property Items is selected in the Properties window (via DefaultPropertyAttribute)
  • Properties are categorized (via CategoryAttribute), and have tooltip (via DescriptionAttribute)
• Double click tabControl1 will add an event handler for SelectionChanged event (via DefaultEventAttribute)
  
• right click tabControl1, select Add Tab (via PrimarySelectionContextMenuProvider):
  
• A new tabItem2 is added. Notice that:
  
  • tabItem2 is initialized with a <Grid/> content
  • tabItem2’s default property Header is highlighted. You can type into the text box next to it and change the object typed Header property directly. (via TypeConverterAttribute)
  • all properties have nice infotip
• double click DatePicker on toolbox:
  
  • a datePicker1 is added to tabItem2’s <Grid> (via ParentAdapter)
  • datePicker1 is fully expanded, even though its IsDropDownOpen property is false (via DesignModeValueProvider)
• Now click tabItem1, notice that tabItem2’s content is hidden and tabItem1’s is shown:
  
• click Chart on toolbox:
  
  • a chart1 is added to the right place, initialized with sample data, and nicely rendered
  • default property Series is selected in the properties window
• click the … button next to Series property to pop up the Collection Editor:
  
  • the Select item combobox is populated with the correct types (via NewItemTypesAttribute). The pink background for the icons are fixed now.
  • the Properties window for the series highlights the default property DependentValuePath, have all properties categorized (like the Data Visualization category), and you can modify the object typed Title property directly in the text box.
• Create a simple data class with some simple properties, and add it as a data source, via Data |  Show Data Sources menu item: 
  
• Drag MyData over tabItem1’s header and drop it :
  
  • a CollectionViewDataSource is inserted, used as DataContext of the LayoutRoot, and tabItem1’s Header is bound to it. (Via DefaultBindingPropertyAttribute)
• Just for fun, open the project in Blend 3, you will see very similar design time behaviors:
  

Conclusion

Above walkthrough is only a peek into all the design time features we have implemented for VS2010. I am very excited that VS2010 now provides a real designer for Silverlight, and I will continue enriching the design time experience for Silverlight in VS and Blend. Your feedback is welcome.

I will write a series of posts explaining how those design time experience are implemented.

• Install Silverlight 3, Blend 3 and Toolkit from http://silverlight.net/getstarted/
• Open Blend 3, create a new Silverlight 3 Application project
• Open Asset Library, notice few improvements:
  • the new Asset Library. See Unni’s blog The Blend 3 Asset Library for more info. 
  • the nicer icons and more informative infotip

• Add an Expander control, and set it as the new active container:

• Add a DatePicker to the Expander, notice that both the DatePicker and its Calendar drop down are shown, even though both Expander’s IsExpanded and DatePicker’s IsDropDownOpen are false.

• Select LayoutRoot so Expander and the nest DatePicker are no longer selected, notice that both are now collapsed.

Open the project in Visual Studio,notice that the Toolbox is populated with lots of controls from Silverlight SDK and Toolkit, with nice icons.

So far, design time features for Silverlight are mostly exposed through Blend. This will change with next beta of Visual Studio 2010, which will come out soon, according to this Visual Studio Magazine article. Stay tuned!

Introduction

This is part of the series on design time feature implementation in Silverlight Toolkit. This post uses the Chart default initializer to illustrate how to implement default initializer for Silverlight controls, and explain the underlying editing model architecture.

Experience

If you install Silverlight 3 Toolkit in March 2009 Release, you can drag the Chart control from Blend Asset Library and drop it onto designer surface, and you have a chart nicely initialized and rendered:

You can read more about it in prior post Silverlight Toolkit Design Time Features: March 2009 Release Update.

Architecture

DefaultInitializer

It is actually pretty simple to provide a default initializer for a Silverlight control:

• implement a subclass of DefaultInitializer, and override its InitializeDefaults function
• associate the default initializer class with the control class via a FeatureAttribute

Below screenshot shows the implementation of DefaultInitializer abstract base class, and other classes in Microsoft.Windows.Design.Model namespace that will be discussed shortly:

Initialization is done in InitializeDefaults override, and result is serialized into xaml. So the first step in implementing a default initializer is to define the desired xaml to be produced.

Editing Model

Once the result xaml is defined, I wish there is a higher level abstraction/method that would just take the xaml. But unfortunately we have to use a much lower level (thus more flexible and powerful) imperative API called editing model that consists of classes like ModelItem, ModelProperty, ModelEvent, ModelFactory and ModelService. The MSDN page Editing Model Architecture gives an basic overview:

Your design-time implementation interacts with run-time controls though a programming interface called the editing model. The objects being designed are called editable objects.

Your controls are defined in Extensible Application Markup Language (XAML). You update the XAML for your controls programmatically by using the editing model.

Model, Wrapper, and View

The editing model consists of three functional subunits: a model, a public wrapper that abstracts the model, and a view that represents the user interface (UI) of the model. The model and the view are separate, but the wrapper and model are closely related. The following illustration shows the relationship among the three subunits.

The design environment uses the ModelItem type to communicate with the underlying model. All changes are made to the ModelItem wrappers, which affect the underlying model. This allows the model to be simple. The ModelItem wrappers handle complex designer features, such as transaction support, undo tracking, and change notifications.

Below class diagram may help explain interactions among core classes of the editing model:

Use below xaml as an example:

<UserControl
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    x:Class="ModelTest.Page" Width="640" Height="480">
    <Grid x:Name="LayoutRoot" Background="White">
        <Button x:Name="Button">
            <Rectangle x:Name="Rectangle" />
        </Button>
    </Grid>
</UserControl>

• ModelItem: assume variable item is the ModelItem for the Button control above,
  • Name is persisted as x:Name attribute in xaml: item.Name = “Button” is persisted in xaml as x:Name = “Button”.
  • ItemType is the Type object of the underlying control, and decides the tag used in xaml: item.PropertyType == tyepof(Button), and the xaml tag is <Button />.
  • Properties is the collection of properties, wrapped in ModelProperty type, of the underlying control. For example: item[“ClickMode”] = ClickMode.Release will be persisted in xaml as ClickMode=”Release”.
  • Content represents the Content property defined in ContentControl (and inherited by its subclasses): item.Content is the ModelItem representing the Rectangle object.
  • Source: when a ModelItem represents an element that’s a property of another element, Source is the ModelProperty wrapper of that property. For example, item.Content.Value.Source == item.Content // the Rectangle.
  • Events represents the collection of events of the underlying control, wrapped in ModelEvent type. From my debugging experience, it is always null, so it seems Events property is not yet supported by Blend3 for Silverlight3 yet.
  • Parent is the the logic parent of the underlying control, wrapped in ModelItem type. ex: item.Parent is the ModelItem for Grid.
  • Root is the ModelItem wrapper for root visual, ex: item.Root represents the UserControl.
• ModelProperty: assume variable prop is the ModelProperty for Button.Content, i.e. prop = item.Content,
  • Name is the name of the property of the underlying control. It is persisted in xaml as attribute name. ex: prop.Name == “Content”.
  • PropertyType is the Type object of the property of the underlying control this ModelProperty object represents. ex: prop.PropertyType = typeof(object).
  • AttachedOwnerType is the Type object of the control that first defines the property this ModelProperty object represents. ex: prop.AttachedOwnerType == typeof(ContentControl) // note: not Button.
  • Value is the value of the property of the underlying control, wrapped in ModelItem type. ex: prop.Value is the ModelItem representing the Rectangle object.
  • Parent is the control, wrapped in ModelItem type, of which the property belongs to. ex: prop.Parent == item.
• ModelEvent: as mentioned above, item.Events is always null, so it doesn’t seem that ModelEvent is supported in Blend3 for Silverlight3 yet. But assume it works, and variable evt is the ModelEvent for Button.Click, i.e., evt = item.Events[“Click”],
  • Name is the name of the event. ex: evt.Name == “Click”.
  • EventType is the type of the event delegate, ex: evt.EventType == typeof(RoutedEventHandler).
  • Handlers is the string collection of event handlers, ex: evt.Handlers = new string[] { “Button_Click” } will be persisted as Click = “Button_Click”. Note: this is pure speculation, since ModelEvent isn’t yet supported, and I don’t know whether/when/how it will be supported for Silverlight.
  • Parent is the control, wrapped in ModelItem type, of which this event belongs to. ex: evt.Parent == item.

Implementation

The Chart default initializer class ChartDefaultInitializer is implemented in ChartDefaultInitializer.cs, and registered in ChartMetadata.cs. Both files are in Controls.DataVisualization.Toolkit.Design.csproj of Silverlight.Controls.Design.sln. Please read prior post Design Time Feature Implementation in Silverlight Toolkit for more information.

Result XAML

As the first step, define the result xaml to be produced by ChartDefaultInitializer:

<Charting:Chart Title="Chart Title">
    <Charting:Chart.DataContext>
        <PointCollection>
            <Point X="1" Y="10" />
            <Point X="2" Y="20" />
            <Point X="3" Y="30" />
            <Point X="4" Y="40" />
        </PointCollection>
        <Charting:Chart.Series>
            <Charting:ColumnSeries ItemsSource="{Binding}"
                DependentValuePath="X"
                IndependentValuePath="Y" />
        </Charting:Chart.Series>
    </Charting:Chart.DataContext>
</Charting:Chart>

Registration

Done in ChartMetadata.cs with following code:

b.AddCustomAttributes(new FeatureAttribute(typeof(ChartDefaultInitializer)));

References

See below screenshot:

Even though DefaultInitializer is defined in version 3.5 of Microsoft.Windows.Design.Interaction.dll (under %devenvdir%\PublicAssemblies, i.e. c:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PublicAssemblies on 32bit Windows), it is not supported by Blend2 or Visual Studio 2008 for Silverlight. It is supported by Blend3 and Visual Studio 2010, but they both switch to newer version of Microsoft.Windows.Design*.dll (3.7 for Blend 3 Preview, 4.0 for Blend 3 RTM and Visual Studio 2010), so we need to link against the newer version of MWDs. Please see prior post How to Write Silverlight Design Time for All Designers: Visual Studio 2008, Blend 2; Blend 3, and Visual Studio 2010 for more information.

Please also notice that reference to Silverlight’s System.Windows.dll is aliased, and the PointCollection is specifically called out to be the Silverlight one, not WPF’s. Since WPF and Silverlight share a lot of classes in same namespaces, it is important that Silverlight types, not WPF’s, are used in creating ModelItem and ModelProperty in default initializer for Silverlight controls.

Collections

Please note in below screenshot that while all other property value can be set via ModelProperty.SetValue:

Chart.Series is of collection type (Collection<Series>), so its value has to be set by first creating a ModelItem via ModelFactory.CreateItem for the value, and then add the created ModelItem via ModelProperty.Collection.Add. Otherwise, even though the correct xaml may be generated, Blend won’t refresh to render the Chart control correctly, you have to reload the page to have it rendered correctly.

ChartDefaultInitializer.cs

// (c) Copyright Microsoft Corporation.
// This source is subject to the Microsoft Public License (Ms-PL).
// Please see http://go.microsoft.com/fwlink/?LinkID=131993 for details.
// All other rights reserved.

extern alias Silverlight;
using System.Windows.Controls.DataVisualization.Charting;
using System.Windows.Controls.Design.Common;
using Microsoft.Windows.Design.Metadata;
using Microsoft.Windows.Design.Model;
using SSW = Silverlight::System.Windows;
using SSWD = Silverlight::System.Windows.Data;
using SSWM = Silverlight::System.Windows.Media;

namespace System.Windows.Controls.DataVisualization.Design
{
    /// <summary>
    /// Default initializer for chart. 
    /// </summary>
    internal class ChartDefaultInitializer : DefaultInitializer
    {
        /// <summary>
        /// Sets the default property values for chart. 
        /// </summary>
        /// <param name="item">Chart ModelItem.</param>
        public override void InitializeDefaults(ModelItem item)
        {
            string propertyName;

            // <Charting:Chart Title="Chart Title">
            propertyName = Extensions.GetMemberName<Chart>(x => x.Title);
            item.Properties[propertyName].SetValue(Properties.Resources.ChartTitle);

            // <Charting:Chart.DataContext>
            //     <PointCollection>
            //         <Point X="1" Y="10" />
            //         <Point X="2" Y="20" />
            //         <Point X="3" Y="30" />
            //         <Point X="4" Y="40" />
            //     </PointCollection>
            // </Charting:Chart.DataContext>

            SSWM::PointCollection defaultItemsSource = new SSWM::PointCollection();
            for (int i = 1; i <= 4; i++)
            {
                defaultItemsSource.Add(new SSW::Point(i, 10 * i));
            }

            propertyName = Extensions.GetMemberName<Chart>(x => x.DataContext);
            item.Properties[propertyName].SetValue(defaultItemsSource);

            // <Charting:Chart.Series>
            //     <Charting:ColumnSeries ItemsSource="{Binding}"
            //         DependentValuePath="X"
            //         IndependentValuePath="Y" />
            // </Charting:Chart.Series>

            ModelItem columnSeries = ModelFactory.CreateItem(item.Context, typeof(ColumnSeries));
            propertyName = Extensions.GetMemberName<ColumnSeries>(x => x.ItemsSource);
            columnSeries.Properties[propertyName].SetValue(ModelFactory.CreateItem(columnSeries.Context, typeof(SSWD::Binding)));
            propertyName = Extensions.GetMemberName<ColumnSeries>(x => x.DependentValuePath);
            columnSeries.Properties[propertyName].SetValue("X");
            propertyName = Extensions.GetMemberName<ColumnSeries>(x => x.IndependentValuePath);
            columnSeries.Properties[propertyName].SetValue("Y");

            propertyName = Extensions.GetMemberName<Chart>(x => x.Series);
            item.Properties[propertyName].Collection.Add(columnSeries);
        }
    }
}

• robocopy posts under “%userprofile%\Documents\My Weblog Posts”
• copy auto linking entries in “%appdata%\Windows Live Writer\LinkGlossary\linkglossary.xml”

For those curious, this is where Windows Live Writer settings are stored:

• posts:
  
• User dictionaries, keywords and auto links:
  
• other settings in registry:
  

For those even more curious, this is how I found out where those settings are, besides web search:

• configuration is usually persisted in registry and/or files, and those registry and files usually follow well known path convention. Registry is usually a good start. For files, try %appdata% and/or “%userprofile%.
• use sysinternals’ procmon to see what registry and files a process is accessing:
  
• for managed code, load all their assemblies (usually under %programfiles%) into reflector, and see how it is implemented:
  

Happy blogging, and hacking

I’ve been using Windows Live Spaces for personal blogging, but since I moved my work blog to WordPress, I wanted to build my personal blog with WordPress too. WordPress is a great blog software, but features for photo blogging, which my personal blog is mostly about, are lacking out of box. So I spent the past weekend experimenting with various desktop software and WordPress plugins, and here is the result:

Basically my photoblog solution consists of:

• Build my WordPress blog site with WP-SimpleViewer and NextGEN Gallery plugins
  • WP-SimpleViewer for slow connection (< 1mbps)
  • NextGEN Gallery for fast connection (>10mbps), gallery, and widgets
• Manage photos locally using Windows Live Photo Gallery 
• Backup photos remotely on both Live Spaces and my WordPress site
• Write blogs and cross post them to both Live Spaces and WordPress site using Windows Live Writer

WP-SimpleViewer

WP-SimpleViewer plugin “enables you to easily add fancy SimpleViewer Flash galleries to your posts and pages. The admin interface helps you to create the thumbs for a new gallery and change its settings.” The slideshow in the middle of the screenshot above is generated with WP-SimpleViewer. Besides the fancy UI and easy keyboard navigation for in-page photo viewing, the biggest benefit, to me at least, is that WP-SimpleViewer generates 20-30KB sized scaled down photos under reg folder, and 1-2KB sized thumbnails under tn subfolder, and display those photos instead of the originals in the slide show. This allows very slick photo viewing experience even on slow connections (<1mbps).

It is pretty easy to install WP-SimpleViewer, but making it work isn’t so trivial. By default, it always hangs during gallery creation. The fix is to uncomment line 101 of wp-simpleviewer-admin.php:

/*If the plugin should hang up while it is creating the thumbs (last line on the admin is: "Now I am working on file xzy.jpg:") you
can try to uncomment the following line (remove // ) to define a new memory limit (40MB in this case). More info on the plugins FAQ.*/
//ini_set("memory_limit","40M");

I changed it to ini_set(“memory_limit”, “120MB”). I also increased the limits in php.in:

;;;;;;;;;;;;;;;;;;;
; Resource Limits ;
;;;;;;;;;;;;;;;;;;;

max_execution_time = 30     ; Maximum execution time of each script, in seconds
max_input_time = 60    ; Maximum amount of time each script may spend parsing request data
memory_limit = 128M      ; Maximum amount of memory a script may consume (32MB)

But even with those changes, WP-SimpleViewer still hangs when there are a lot of photos in one gallery.

Another trick I did is to set the images directory to wp-content/gallery instead of the default wp-content/photos in WP-SimpleViewer’s admin page, so the same original photos can be used by both WP-SimpleViewer and NextGEN Gallery.

NextGEN Gallery

NextGen Gallery is probably the most popular image gallery plugin for WordPress. It has a basic set of image gallery functions, like albums, tags, roles etc, and a set of shortcode for different rendering. NextGEN’s slideshow and PicLens view both display the original photos. My photos are usually 2-3MB in size, so they look great with fast connection (>10mpbs), and can be displayed with cooliris browser addin (need separate install) as shown below:

But that doesn’t really work with slow connections (<1mbps): those MB sized photos take forever to download on slow connection, so I usually put both WP-SimpleViewer and NextGEN shortcode on a page. Besides the nice rendering UI, NextGEN Gallery also comes with two nice widgets: the NextGEN Slideshow and NextGEN Gallery widget, as shown at the top left corner of my personal blog screenshot above.

Just like WP-SimpleViewer, it is pretty easy to install to NextGEN Gallery, but it takes some effort to make it work. Besides modifying php.ini as mentioned above, I also need to uncomment line 168 of lib/gd.thumbnail.inc.php:

lib\gd.thumbnail.inc.php:168:           // @ini_set(’memory_limit’, ‘128M’);

Once working, it seems more reliable than WP-SimpleViewer.

Windows Live Photo Gallery

I used to use Picasa, but after trying out the new Windows Live Photo Gallery 2009, I am really impressed. The features I really like about Windows Live Photo Gallery:

• easy navigation with folder, date, people and tag hierarchical views
• tagging, rating, and people tagging features
• metadata in the info panel
• fix functions, especially straighten photo: I am getting into the habit of applying it on all photos
• easy publishing to live spaces, and other photo sharing sites (require plugin)
• and the publishing plugin platform

Windows Live Writer

Windows Live Writer is probably the best blog authoring tool. The nice new feature related to photo blogging is the Insert –> Photo album… function:

It is nicely integrated with Live Spaces, allowing users to browse their existing photo albums or create new one, and insert it into blog post with four different layout. In my personal blog screenshot above, the top photo album in scatter view is inserted via Insert –> Photo album. You can find more from Windows Live Writer blog, like post Windows Live Writer 2009: Now Available for Download.

Photo in Live Spaces are also doubled scaled for easy browsing on both slow and fast connections, just like WP-SimpleViewer: thumbnail and regular photos are displayed, but user can also click on a photo to get the original version. Live Spaces allows 25GB for photo storage, so it can be used as an online storage for photos.

Conclusion

I am by no means a blog or photoblog expert, and don’t really know WordPress, PHP, or the various Live services as a developer. This post is just to share what I’ve learned about photo blogging with WordPress. I am actually quite happy with what I’ve managed to do over the weekend. It is good enough for me for now, photo blogging wise.

Invalid Server Response – The response to the metaWeblog.newMediaObject method received from the blog server was invalid

I searched the web, tried a few things, and fixed the issue pretty quickly. Share my findings here in hope it may be helpful for others run into similar problems.

Windows Live Writer Log

WLW has pretty good log. Open Help->About Windows Live Writer menu item:

You will see the About dialog, click the Show log file link:

the folder “%localappdata%\Windows Live Writer” will pop up, which contains “Windows Live Writer.log” file. I copied relevant error log below. Pretty good stack trace, very helpful for debugging and diagnosing

WindowsLiveWriter,1.7696,Fail,00031,30-Apr-2009 01:28:58.595,"WindowsLive.Writer.Extensibility.BlogClient.BlogClientInvalidServerResponseException: Invalid Server Response - The response to the metaWeblog.newMediaObject method received from the blog server was invalid:

Invalid response document returned from XmlRpc server
   at WindowsLive.Writer.BlogClient.Clients.XmlRpcBlogClient.CallMethod(String methodName, XmlRpcValue[] parameters)
   at WindowsLive.Writer.BlogClient.Clients.MetaweblogClient.DoBeforePublishUploadWork(IFileUploadContext uploadContext)
   at WindowsLive.Writer.PostEditor.WeblogBlogFileUploader.DoUploadWorkBeforePublish(IFileUploadContext uploadContext)
   at WindowsLive.Writer.PostEditor.BlogPostReferenceFixer.FileUploadWorker.DoUploadWork(String fileReference, BlogFileUploader fileUploader, Boolean isWindowsLiveLightboxCloneEnabled)
   at WindowsLive.Writer.PostEditor.BlogPostReferenceFixer.LocalFileTransformer.Transform(BeginTag tag, String reference)
   at WindowsLive.Writer.CoreServices.HTML.HtmlReferenceFixer.LocalFileReferenceFixupFilter.FixReferences(BeginTag tag, String reference)
   at WindowsLive.Writer.CoreServices.HTML.HtmlReferenceFixer.OnBeginTag(BeginTag tag)
   at WindowsLive.Writer.CoreServices.LightWeightHTMLDocumentIterator.Parse()
   at WindowsLive.Writer.CoreServices.HTML.HtmlReferenceFixer.FixReferences(TextWriter output, ReferenceFixer referenceFixer, ReferenceFixedCallback referenceFixed)
   at WindowsLive.Writer.CoreServices.HTML.HtmlReferenceFixer.FixReferences(String html, ReferenceFixer fixer, ReferenceFixedCallback referenceFixed)
   at WindowsLive.Writer.CoreServices.HTML.HtmlReferenceFixer.FixLocalFileReferences(String html, ReferenceFixer fixer, ReferenceFixedCallback referenceFixed)
   at WindowsLive.Writer.CoreServices.HTML.HtmlReferenceFixer.FixLocalFileReferences(String html, ReferenceFixer fixer)
   at WindowsLive.Writer.PostEditor.UpdateWeblogAsyncOperation.LocalSupportingFileUploader.UploadFilesBeforePublish()
   at WindowsLive.Writer.PostEditor.UpdateWeblogAsyncOperation.DoWork()
   at WindowsLive.Writer.CoreServices.AsyncOperation.InternalStart()","   at System.Environment.GetStackTrace(Exception e, Boolean needFileInfo)
   at System.Environment.get_StackTrace()
   at WindowsLive.Writer.CoreServices.Diagnostics.LogFileTraceListener.Fail(String message)
   at System.Diagnostics.TraceInternal.Fail(String message)
   at System.Diagnostics.Trace.Fail(String message)
   at WindowsLive.Writer.PostEditor.BlogPostEditingManager.UpdateWeblog(Boolean publish)
   at WindowsLive.Writer.PostEditor.BlogPostEditingManager.PostToWeblog(Boolean publish)
   at WindowsLive.Writer.PostEditor.BlogPostEditingManager.PublishAsDraft()
   at WindowsLive.Writer.PostEditor.PostEditorMainControl.commandPostAsDraft_Execute(Object sender, EventArgs e)
   at WindowsLive.Writer.ApplicationFramework.Command.RaiseEvent(Object eventKey, EventArgs e)
   at WindowsLive.Writer.ApplicationFramework.Command.OnExecute(EventArgs e)
   at WindowsLive.Writer.ApplicationFramework.CommandOwnerDrawMenuItem.OnClick(EventArgs e)
   at System.Windows.Forms.MenuItem.MenuItemData.Execute()
   at System.Windows.Forms.Command.Invoke()
   at System.Windows.Forms.Command.DispatchID(Int32 id)
   at System.Windows.Forms.Control.WmCommand(Message& m)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
   at System.Windows.Forms.ContainerControl.WndProc(Message& m)
   at System.Windows.Forms.Form.WndProc(Message& m)
   at WindowsLive.Writer.ApplicationFramework.ApplicationForm.WndProc(Message& m)
   at WindowsLive.Writer.ApplicationFramework.SatelliteApplicationForm.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
   at System.Windows.Forms.NativeWindow.DefWndProc(Message& m)
   at System.Windows.Forms.NativeWindow.WndProc(Message& m)
   at WindowsLive.Writer.PostEditor.ImageInsertion.InsertImageDialog.ThumbnailReadinessListener.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
   at System.Windows.Forms.NativeWindow.DefWndProc(Message& m)
   at System.Windows.Forms.NativeWindow.WndProc(Message& m)
   at WindowsLive.Writer.PostEditor.ImageInsertion.InsertImageDialog.ThumbnailReadinessListener.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
   at System.Windows.Forms.NativeWindow.DefWndProc(Message& m)
   at System.Windows.Forms.NativeWindow.WndProc(Message& m)
   at WindowsLive.Writer.PostEditor.ImageInsertion.InsertImageDialog.ThumbnailReadinessListener.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
   at System.Windows.Forms.NativeWindow.DefWndProc(Message& m)
   at System.Windows.Forms.NativeWindow.WndProc(Message& m)
   at WindowsLive.Writer.PostEditor.ImageInsertion.InsertImageDialog.ThumbnailReadinessListener.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
   at System.Windows.Forms.NativeWindow.DefWndProc(Message& m)
   at System.Windows.Forms.NativeWindow.WndProc(Message& m)
   at WindowsLive.Writer.PostEditor.ImageInsertion.InsertImageDialog.ThumbnailReadinessListener.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
   at System.Windows.Forms.NativeWindow.DefWndProc(Message& m)
   at System.Windows.Forms.NativeWindow.WndProc(Message& m)
   at WindowsLive.Writer.PostEditor.ImageInsertion.InsertImageDialog.ThumbnailReadinessListener.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
   at System.Windows.Forms.NativeWindow.DefWndProc(Message& m)
   at System.Windows.Forms.NativeWindow.WndProc(Message& m)
   at WindowsLive.Writer.PostEditor.ImageInsertion.InsertImageDialog.ThumbnailReadinessListener.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
   at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
   at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData)
   at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
   at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
   at System.Windows.Forms.Application.Run(Form mainForm)
   at WindowsLive.Writer.ApplicationFramework.SatelliteApplicationForm.Launcher.ThreadMain(Object[] parameters)
   at WindowsLive.Writer.CoreServices.Threading.ThreadStartWithParams.Run()
   at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.ThreadHelper.ThreadStart()"

It is the Gold Star Rating Plugin!

Since WLW has always worked fine with my WordPress site till now, so I suspect it is some recent changes on my WordPress site, and most likely recent plugin updates, so I tried deactivating plugins one by one. I was lucky! Since I knew what plugins I updated lately, so I first deactivated Gold Start Rating plugin and then use WLW to open and post, and it worked!

Updates

2009-05-05

I ran into this error again while publishing a post from Windows Live Writer:

Windows Live Writer log shows similar error message and call stack as before. I opened error_log under the top directory of my WordPress site, it has something like this:

05-May-2009 08:10:59] PHP Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 865469 bytes) in /[deleted]/wp-includes/class-IXR.php on line 242

and line 242 of class-IXR.php is the second line below:

case 'base64':
    $value = base64_decode( trim( $this->_currentTagContents ) );
    $valueFlag = true;
    break;

So it looks like it ran out of memory while base64_decode an image. I removed the largest image in my post, post draft to blog, and it succeeded. I then edited the draft from WordPress web UI, select Add an Image from computer and insert it to post:

and it succeeded.

I don’t really know WordPress or PHP as a developer, so if anyone know how to raise this better, please let me know. A general novice user approach seems:

• post draft to server frequently to pinpoint the troublemaker image while you are authoring
• upload and insert the image to post from WordPress web UI

Introduction

This is part of the series on design time implementation changes in Silverlight Toolkit March 2009 Release. This post illustrates the integration of Silverlight Toolkit with Visual Studio and Blend 3 after running Silverlight 3 Toolkit March 2009 Installer, and explains how it is done, so you can register your own Silverlight controls with Visual Studio and Blend too.

Blend Integration

After installing Silverlight 3 Beta1 Tools, Blend 3 Preview, and Silverlight 3 Toolkit March 2009 (please see Silverlight Toolkit Design Time Features: March 2009 Release Update, Silverlight 3 Development with Visual Studio 2008 and Blend 3 section for more information), create a Silverlight 3 Application from Blend 3, we can see that Silverlight Toolkit controls show up automatically in Asset Library:

User can drag and drop Toolkit controls from Asset Library to design or xaml view, and Blend will automatically add assembly reference, xmlns prefix and xaml code, very convenient:

Visual Studio Integration

Open the project in Visual Studio, we can see that Toolkit controls show up automatically in Visual Studio Toolbox, and user can drag and drop controls from Toolbox to design or xaml view as well:

Besides Toolbox, Toolkit assemblies also show up in Add Reference Dialog:

and Choose Toolbox Items Dialog:

Implementation

The integration with Visual Studio and Blend is done via registry. If you open “Silverlight 3 Toolkit March 2009.msi” in Orca, you can see the registration magic:

Register with Visual Studio

AssemblyFoldersEx

Registering with Visual Studio is mostly done via [HKLM|HKCU]\Software\Microsoft\Microsoft SDKs\Silverlight\v3.0\AssemblyFoldersEx:

The References in Visual Studio page has very good explanation on AssemblyFoldersEx and reference resolution. It is a bit outdate, and is about .net instead of Silverlight, but it is mostly right for Silverlight too. I duplicated the registration schema section below, and modified it to fit Silverlight. Text in small italic fonts are purely hypothetical, meaning: it doesn’t work for Silverlight today; I have it here simply because it is in originally text, works for .NET, and seems making sense for Silverlight to duplicate or to be consistent with .Net.

Registration Schema

Assembly directories can be added to the registry so that the build process can resolve references to assemblies in those directories. Here’s an example of the registry schema.

[HKLM | HKCU]\SOFTWARE\MICROSOFT\Silverlight\

  v3.0

    AssemblyFoldersEx

      Silverlight Toolkit

        @Default = C:\Program Files\Microsoft SDKs\Silverlight\v3.0\Toolkit\March 2009\Libraries\

        @Description = Silverlight 3 Toolkit March 2009

        20090401

          @Default = C:\Program Files\Microsoft SDKs\Silverlight\v3.0\Toolkit\March 2009\20090401

          @Description = April Fool’s Updates

In the above example, there are several interesting fields.

(1) AssemblyFolderBase – The registry path “\SOFTWARE\MICROSOFT\Silverlight” indicates the target framework platform. Typical values for this property are:

\SOFTWARE\MICROSOFT\Silverlight(default) – for Silverlight

\SOFTWARE\MICROSOFT\.NetCompactFramework– for .NET Compact Framework

(2) FrameworkVersion – The version of the frameworks that this component is meant to work against.

(3) AssemblyFoldersSuffix – Describes the sub-target, examples include:

AssemblyFoldersEx (default) – for Silverlight

PocketPC\AssemblyFoldersEx – for the .NET Compact Framework for Pocket PC

SmartPhone\AssemblyFoldersEx – for the .NET Compact Framework for SmartPhone

WindowsCE\AssemblyFoldersEx – for the .NET Compact Framework for WindowsCE

(4) ControlName – The name of the control. In the example above, “Silverlight 3 Toolkit March 2009”. The control vendor chooses this name.

(5) ServicingCode – For service packs that update the same component. In the above example, “20090401”. The control vendor chooses this name.

Toolbox Controls Installer

Jim Nakashima blogged about Toolbox Controls Installer for WPF controls in his post Have you seen the Toolbox Controls Installer? in 2007. Toolbox Controls Installer package is now part of Visual Studio 2008, and kind of works, with a bug that will be fixed in Visual Studio 2010. It can be tweaked to work for Silverlight controls too: set string registry value SilverlightControls instead of WPFControls to 1.

I am working with various teams inside Microsoft to improve the Visual Studio registration story for Silverlight controls. All feedbacks and suggestions are welcome!

Register with Blend

Registering with Blend is via HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Expression\Blend\v3.0\Toolbox\Silverlight\v3.0:

Unni Ravindranathan’s blog post Blend 3 Extensibility has more information about this mechanism. One caveat: if the registered assemblies depend on other assemblies, those other assemblies need to be in the same directory as registered assemblies, or registered with AssemblyFoldersEx mentioned above. 

Conclusion

Registration with Visual Studio and Blend makes Silverlight Toolkit controls a lot easier to use for developers. We are constantly looking at improving the registration mechanism in hope to make it simple and consistent across designers (Visual Studio and Blend) and technologies (WPF and Silverlight). All feedbacks are welcome!

This is part of the series on design time implementation changes in Silverlight Toolkit March 2009 Release. This post illustrates the rich intellisense support for Silverlight Toolkit, and explains implementation workflow from xmldoc in source to infotip in intellisense xml file and design assemblies.

Intellisense

Silverlight Toolkit has rich Intellisense in code and XAML editors in both Visual Studio and Blend:

• Visual Studio Code Editor:
  
• Blend 3 Code Editor:
  
• Blend 3 XAML editor:
  

Visual Studio XAML editor has intellisense too, but no infotip:

 

Implementation

Code Editor Intellisense Infotip from XML Files

The intellisense infotips in code editors in Visual Studio and Blend come from intellisense xml files installed under Silverlight SDK and Toolkit directories:

Localization

Those intellisense xml files can be localized. If you install localized Visual Studio and localized Silverlight SDK, you will see localized infotips, which is a great help for those who don’t speak English. Below is the screenshot of Visual Studio running with Simplified Chinese language and simplified Chinese version of Silverlight Tools for Visual Studio SP1:
 

The Chinese infotip is from localized System.Windows.Controls.xml under zh-CHS sub directory:

C:\Program Files\Microsoft SDKs\Silverlight\v2.0\Libraries\Client>dir/s /b system.windows.controls.xml
C:\Program Files\Microsoft SDKs\Silverlight\v2.0\Libraries\Client\system.windows.controls.xml
C:\Program Files\Microsoft SDKs\Silverlight\v2.0\Libraries\Client\zh-CHS\system.windows.controls.xml

XAML Editor Intellisense Infotip from Design Assemblies

The intellisense infotips in Blend 3 XAML editor come from a different mechanism: they come from DescriptionAttribute implemented by design dlls installed under the Design subdirectory:

So it is the same as infotips in Blend Properties panel (please see Design Time Features in Silverlight Toolkit for more information):

xmldoc comment –> intellisense xml file –> DescriptionAttribute in design assembly

All those infotips come from xml documentation comments in source code, as seen from below screenshot:

1. we put xmldoc comments in source code
2. build generates .xml files from those xmldoc comments
3. the generated .xml files are embedded in design dlls (see Design Time Feature Implementation in Silverlight Toolkit for more information)
4. the control dlls, design dlls, and xml files are installed by SDK and Toolkit setup

Conclusion

This post describes the rich intellisense support of Silverlight Toolkit and its implementation workflow from xmldoc comments to intellisense xml files to design dlls. Good commenting pays!

This is part of the series on design time implementation changes in Silverlight Toolkit March 2009 Release. This post discusses how to enhance property editing experience for Silverlight controls using property value editor and type converter. I will start with describing the overall property editing architecture in WPF/Silverlight designer extensibility framework, then use examples in  Silverlight Toolkit March 2009 Release to demonstrate how it is done, and unique issues/tricks in Silverlight design time development.

Property Editing Architecture

Visually editing object properties is an important part of designers. Designers usually don’t know how to render properties of custom type (struct, class or interface), much less to provide an nice editing user interface. Control developers usually need to provide TypeConverter, PropertyValueEditor, or both, to provide rendering/editing UI and XAML serialization for properties of custom types.

The designer extensibility framework defines three types of property value editor: inline editor, extended editor, and dialog editor, each implemented by a class:

Editing UI of those editors are defined by DataTemplate. The property being edited is exposed to editor as DataContext of PropertyValue type. Editor UI usually bind to the underlying property being edited via one of the three properties of PropertyValue: Value, StringValue, or Collection.

PropertyValueEditor

PropertyValueEditor holds a single inline editor defined by InlineEditorTemplate property. Inline editor appears inside the properties window. Below is an simple example of InlineEditorTemplate that uses a TextBox to display and edit a property:

<DataTemplate x:Key="TextBoxEditor">
    <TextBox Text="{Binding Path=Value}"/>
</DataTemplate>

ExtendedPropertyValueEditor

<DataTemplate x:Key="inlineEditor">
    <Button Content="..." Command="{x:Static PropertyEditing:PropertyValueEditorCommands.ShowDialogEditor}"/>
</DataTemplate>
<DataTemplate x:Key="extendedEditor" xmlns:PropertyEditing="clr-namespace:Microsoft.Windows.Design.PropertyEditing;assembly=Microsoft.Windows.Design.Interaction">
    <Slider x:Name="slider" Value="{Binding Path=Value}" />
</DataTemplate>

DialogPropertyValueEditor

DialogPropertyValueEditor has two editors too: the inline editor inherited from PropertyValueEditor, and an additional dialog editor defined by DialogEditorTemplate property. The dialog editor is usually popped up by inline editor via PropertyValueEditorCommands.ShowDialogEditor command. Below is a simple example:

<DataTemplate x:Key="inlineEditor">
    <Button Content="..." Command="{x:Static PropertyEditing:PropertyValueEditorCommands.ShowDialogEditor}"/>
</DataTemplate>
<DataTemplate x:Key="dialogEditor" xmlns:PropertyEditing="clr-namespace:Microsoft.Windows.Design.PropertyEditing;assembly=Microsoft.Windows.Design">
    <Grid>
        <Grid.ColumnDefinitions>
            <ColumnDefinition Width="Auto" />
            <ColumnDefinition Width="*" />
        </Grid.ColumnDefinitions>
        <Grid.RowDefinitions>
            <RowDefinition Height="*"/>
            <RowDefinition Height="*"/>
        </Grid.RowDefinitions>
        <TextBlock Text="User Name:" VerticalAlignment="Center" HorizontalAlignment="Right" Margin="0,0,4,4"/>
        <TextBox Text="{Binding Path=Value}" VerticalAlignment="Center" HorizontalAlignment="Stretch" Margin="0,0,4,4" Grid.Column="1"/>
    </Grid>
</DataTemplate>

Implement Custom Property Editor

To implement a custom property editor for a Silverlight control:

• implement a custom property editor class
  • inherit from PropertyValueEditor, ExtendedPropertyValueEditor, or DialogPropertyValueEditor
  • set its editor template(s): InlineEditorTemplate, ExtendedEditorTemplate, and/or DialogEditorTemplate;
• Associate the custom property editor with a property of a Silverlight control via a AddCustomAttributes call, something like

  attributeTableBuilder.AddCustomAttributes(
      typeof(MyControl),
      "MyProperty",
      new PropertyValueEditor.CreateEditorAttribute(typeof(MyValueEditor)));

   

A correctly implemented property value editor must satisfy the following requirements:   
• The property value editor must be designed so that the inline editor and extended editor parts can be used independently.
• A property value editor must not store state. Property value editors are stateless, might be cached by a host implementation, and can be re-used across multiple property values.
• A property value editor must not assume that only one value editor part (view/inline/extended) control is active at a given time. For example, a dialog box could have the view part, inline part, and extended UI part active at the same time.
• A control implemented as part of a property value editor must not store state. A control implemented as part of a value editor should not assume that it will only be bound to one property value. Controls may be recycled to change different property values. Any information that is cached should be flushed if the data model is updated.
• A control implemented as part of a property value editor must not make any assumptions about the host or its parent controls. The only communication mechanisms that should be used are the PropertyValue data model, by way of the DataContext, and the standard set of commands.

You can read more about property editing architecture and designer extensibility framework on MSDN.

Reference Both WPF and Silverlight Assemblies

A design assembly is a .NET/WPF assembly loaded by Visual Studio or Blend, but it usually needs to reference Silverlight assemblies (at least the Silverlight control assembly it provides design time features for). This can create reference ambiguity for design assembly project: it sometimes needs to reference the same fully qualified type in both WPF and Silverlight, say System.Windows.FrameworkElement in both PresentationFramework.dll of WPF and System.Windows.dll of Silverlight. To avoid confusing Visual Studio, you can use extern alias to distinguish WPF and Silverlight references.

For example, see the screenshot below for Controls.DataVisualization.Toolkit.Design project in Silverlight 3 Toolkit in March 2009 Release:

• the project references both PresentationFramework and System.Windows, but System.Windows is under Silverlight alias, instead of the default global alias. The System.Windows reference under Silverlight alias is persisted in .csproj file as below:

  <Reference Include="System.Windows, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e, processorArchitecture=MSIL">
    <SpecificVersion>False</SpecificVersion>
    <HintPath>..\Binaries\System.Windows.dll</HintPath>
    <Private>False</Private>
    <Aliases>Silverlight</Aliases>
  </Reference>

   

• in source code, we add

  extern alias Silverlight;
  using SSW = Silverlight::System.Windows;

   

  and reference Silverlight’s FrameworkElement via SSW::FrameworkElement.

TextBoxEditor

There is a inline editor TextBoxEditor in Controls.DataVisualization.Toolkit.Design project for displaying and editing Title property of object type for  [Area|Bar|Bubble|Column|Line|Pie|Scatter]Series and Chart controls, as shown below:

Text filled in Title field in Properties window on the right shows up automatically in XAML and design views in the middle.

The implementation of TextBoxEditor followed the steps outlined before:

• TextBoxEditor is a subclass of PropertyValueEditor. It sets InlineEditorTemplate in its default constructor. Here I use code instead of XAML to construct the DataTemplate, because somehow I can’t get xaml to build, and everything in XAML can be rewritten in C# anyway.
• It is associated with Chart.Title in ChartMetadata.cs (see Design Time Feature Implementation in Silverlight Toolkit for more information on *Metadata.cs files)

TextBoxEditor.cs:

// (c) Copyright Microsoft Corporation.
// This source is subject to the Microsoft Public License (Ms-PL).
// Please see http://go.microsoft.com/fwlink/?LinkID=131993 for details.
// All other rights reserved.

using System;
using Microsoft.Windows.Design.PropertyEditing;
using System.Windows;
using System.Windows.Data;

namespace System.Windows.Controls.DataVisualization.Design
{
    /// <summary>
    /// Simple TextBox inline editor.
    /// </summary>
    public partial class TextBoxEditor : PropertyValueEditor
    {
        /// <summary>
        /// Preserve the constructor prototype from PropertyValueEditor.
        /// </summary>
        /// <param name="inlineEditorTemplate">Inline editor template.</param>
        public TextBoxEditor(DataTemplate inlineEditorTemplate)
            : base(inlineEditorTemplate)
        { }

        /// <summary>
        /// Default constructor builds the default TextBox inline editor template.
        /// </summary>
        public TextBoxEditor()
        {
            FrameworkElementFactory textBox = new FrameworkElementFactory(typeof(TextBox));
            Binding binding = new Binding();
            binding.Path = new PropertyPath("Value");
            binding.Mode = BindingMode.TwoWay;
            textBox.SetBinding(TextBox.TextProperty, binding);

            DataTemplate dt = new DataTemplate();
            dt.VisualTree = textBox;

            InlineEditorTemplate = dt;
        }
    }
}

CultureInfoEditor

My colleague RJ wrote inline editor CultureInfoEditor for TimePicker.Culture property, because the default editing experience for CultureInfo in Blend leads to invalid XAML. Below screenshot shows the CultureInfoEditor uses a ComboBox to display all CultureInfo and generates right XAML.

CultureInfoEditor is a more complex example than TextBoxEditor, really shows how the underlying property is associated with editor via DataContext property.

CultureInfoEditor.cs:

// (c) Copyright Microsoft Corporation.
// This source is subject to the Microsoft Public License (Ms-PL).
// Please see http://go.microsoft.com/fwlink/?LinkID=131993 for details.
// All other rights reserved.

using System.Reflection;
using Microsoft.Windows.Design.PropertyEditing;
using System.Globalization;
using System.ComponentModel;

namespace System.Windows.Controls.Input.Design
{
    /// <summary>
    /// Editor for CultureInfo.
    /// </summary>
    /// <remarks>Currently does not support binding from xaml to the editor.</remarks>
    public class CultureInfoEditor : PropertyValueEditor
    {
        /// <summary>
        /// The ComboBox being used to edit the value.
        /// </summary>
        private ComboBox _owner;

        /// <summary>
        /// Preserve the constructor prototype from PropertyValueEditor.
        /// </summary>
        /// <param name="inlineEditorTemplate">Inline editor template.</param>
        public CultureInfoEditor(DataTemplate inlineEditorTemplate)
            : base(inlineEditorTemplate)
        { }

        /// <summary>
        /// Default constructor builds a ComboBox inline editor template.
        /// </summary>
        public CultureInfoEditor()
        {
            // not using databinding here because Silverlight does not support
            // the WPF CultureConverter that is used by Blend.
            FrameworkElementFactory comboBox = new FrameworkElementFactory(typeof(ComboBox));
            comboBox.AddHandler(
                ComboBox.LoadedEvent,
                new RoutedEventHandler(
                    (sender, e) =>
                    {
                        _owner = (ComboBox) sender;
                        _owner.SelectionChanged += EditorSelectionChanged;
                        INotifyPropertyChanged data = _owner.DataContext as INotifyPropertyChanged;
                        if (data != null)
                        {
                            data.PropertyChanged += DatacontextPropertyChanged;
                        }
                        _owner.DataContextChanged += CultureDatacontextChanged;
                    }));

            comboBox.SetValue(ComboBox.IsEditableProperty, false);
            comboBox.SetValue(ComboBox.DisplayMemberPathProperty, "DisplayName");
            comboBox.SetValue(ComboBox.ItemsSourceProperty, CultureInfo.GetCultures(CultureTypes.SpecificCultures));
            DataTemplate dt = new DataTemplate();
            dt.VisualTree = comboBox;

            InlineEditorTemplate = dt;
        }

        /// <summary>
        /// Handles the SelectionChanged event of the owner control.
        /// </summary>
        /// <param name="sender">The source of the event.</param>
        /// <param name="e">The <see cref="System.Windows.Controls.SelectionChangedEventArgs"/> 
        /// instance containing the event data.</param>
        private void EditorSelectionChanged(object sender, SelectionChangedEventArgs e)
        {
            // serialize with name.
                object DataContext = _owner.DataContext;
                DataContext
                    .GetType()
                    .GetProperty("Value", BindingFlags.Public | BindingFlags.Instance | BindingFlags.GetProperty)
                    .SetValue(DataContext, ((CultureInfo)_owner.SelectedItem).Name, new object[] { });
        }

        /// <summary>
        /// Handles the PropertyChanged event of the context object.
        /// </summary>
        /// <param name="sender">The source of the event.</param>
        /// <param name="e">The <see cref="System.ComponentModel.PropertyChangedEventArgs"/> instance containing the event data.</param>
        private void DatacontextPropertyChanged(object sender, PropertyChangedEventArgs e)
        {
            // deserialize from name.
            if (e.PropertyName == "Value")
            {
                object value = sender
                    .GetType()
                    .GetProperty("Value", BindingFlags.Public | BindingFlags.Instance | BindingFlags.GetProperty)
                    .GetValue(sender, new object[] { });

                if (value != null)
                {
                    if (value is string)
                    {
                        CultureInfo setCulture = new CultureInfo(value.ToString());
                        _owner.SelectedItem = setCulture;
                    }
                }
            }
        }

        /// <summary>
        /// Called when the context is changed.
        /// </summary>
        /// <param name="sender">The sender.</param>
        /// <param name="e">The <see cref="System.Windows.DependencyPropertyChangedEventArgs"/> instance containing the event data.</param>
        private void CultureDatacontextChanged(object sender, DependencyPropertyChangedEventArgs e)
        {
            INotifyPropertyChanged old = e.OldValue as INotifyPropertyChanged;
            if (old != null)
            {
                old.PropertyChanged -= DatacontextPropertyChanged;
            }
            INotifyPropertyChanged newDataContext = e.NewValue as INotifyPropertyChanged;
            if (newDataContext != null)
            {
                newDataContext.PropertyChanged += DatacontextPropertyChanged;
            }
        }
    }
}

ExpandableObjectConverter

As discussed at the beginning, besides custom property value editors, sometimes you can use appropriate type converter to provide good editing experience and XAML serialization. One example is ColumnSeries.DependentRangeAxis: it is of IRangeAxis type, Blend doesn’t know how to edit it, so it shows DependentRangeAxis as read only in Properties Panel. By associating ExpandableObjectConverter to ColumnSeries.DependentRangeAxis:

b.AddCustomAttributes(
    Extensions.GetMemberName<ColumnSeries>(x => x.DependentRangeAxis),
    new TypeConverterAttribute(typeof(ExpandableObjectConverter)));
b.AddCustomAttributes(
    Extensions.GetMemberName<ColumnSeries>(x => x.IndependentAxis),
    new TypeConverterAttribute(typeof(ExpandableObjectConverter)));

Blend displays a New button next to this property in Properties Panel; when clicked, it pops up the Select Object dialog, filtered with the property’s type IRangeAxis:

Conclusion

Blend and Silverlight together allow designers to create amazing UI against real controls directly, so it is very important that control developers take designer experience as part of overall control design and implementation. Having a custom property editor that provides nice editing UI and generates correct XAML is an important part of the designer experience. Hopefully this post helps you understand how to create custom property editors. Thanks!

This is part of the series on design time implementation changes in Silverlight Toolkit March 2009 Release. This post focuses on the breaking changes in designer extensibility framework introduced in Silverlight 3/Blend 3/Visual Studio 2010, and how to develop Silverlight design time to support all designers: Visual Studio 2008/Blend 2, and Visual Studio 2010/Blend 3.

Silverlight 2 Design Time for Visual Studio 2008 and Blend 2

Visual Studio and Blend share the same designer extensibility framework, and use it for both WPF and Silverlight. WPF Designer Extensibility on MSDN is probably the best reference available for the designer extensibility framework. The December 2008 Release of Silverlight Toolkit is based on Silverlight 2 (aka SL2), and has designer support for Visual Studio 2008 (aka VS9) and Blend 2. It is a good real world example in demonstrating how to develop Silverlight 2 design time features for VS9 and Blend 2. My blog post Design Time Feature Implementation in Silverlight Toolkit explains in detail how it is done, and the implementation framework readers can use in their own design time implementation.

To recap, the Silverlight 2 design time framework for Visual Studio 2008 and Blend 2 in a nutshell:

• MWD: the design time extensibility framework is exposed through a set of assemblies, most notably Microsoft.Windows.Design.dll, Microsoft.Windows.Design.Extensibility.dll, and Microsoft.Windows.Design.Interaction.dll. Collectively those assemblies are called MWD. They are installed under %DevEnvDir%\PublicAssemblies (C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PublicAssemblies in 32bit OS, or  C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\PublicAssemblies in 64bit OS). They are also GAC-ed. Most design time projects need to reference those MWD dlls. Visual Studio 2008 and Blend 2 use MWD version 3.5.
  
• Naming Convention: Visual Studio and Blend load design time assemblies using a naming convention: for control assembly Foo.dll, VS and Blend will find its design time assemblies with the name Foo.Design.dll, Foo.VisualStudio.Design.dll, and Foo.Expression.Design.dll, in the same directory where Foo.dll is, or the Design sub directory. Visual Studio will load Foo.Design.dll and Foo.VisualStudio.Design.dll, while Blend will load Foo.Design.dll and Foo.Expression.Design.dll. So it is advised to put design time features shared across all designers in .Design.dll, and put Visual Studio and Blend specific design time features in .VisualStudio.Design.dll and .Expression.Design.dll respectively.
• Entry Point: when Visual Studio or Blend loads a design time assembly, it uses reflection to find all classes that implement IRegisterMetadata, and calls its only method Register. Silverlight Toolkit December 2008 Release has a design time implementation framework detailed in previous blog post Design Time Feature Implementation in Silverlight Toolkit.

Below screenshots of Silverlight.Controls.Design.sln in Silverlight 2 Toolkit source in March 2009 Release demonstrates implementation of SL2 design time for VS9 and Blend 2 discussed above:

What Changed In Silverlight 3, Blend 3 and Visual Studio 2010

As stated in WPF Designer Extensibility Architecture on MSDN:

The WPF Designer supports the full extensibility framework. Expression Blend supports only property editors, metadata loading, and licensing. Blend does not support menu actions and adorners.

Blend 2 has above limited support for Silverlight design time too, but Visual Studio 2008 has little support for Silverlight design time (just icons, metadata loading for few attributes like ToolboxBrowsableAttribute): it is more a viewer than a designer. To have WPF parity for Silverlight design time support, Blend 3 and Visual Studio 2010 (aka VS10) have to introduce breaking changes to the designer extensibility framework (i.e. MWD), most notably:

• MWD: most of the designer extensibility framework API stay the same, but their physical packaging changes: Microsoft.Windows.Design.dll is gone, and the version of all MWD assemblies changes from 3.5 to 4.0. Before Visual Studio 2010 Beta1, the only way to get the new MWD is via Blend 3 Preview, and its version is 3.7 instead of 4.0 for now:
  
• Entry Point: instead of reflect through IRegisterMetadata implementations, Blend 3 and Visual Studio 2010 use a new assembly attribute ProvideMetadataAttribute, and the metadataProviderType must implement IProvideAttributeTable:
  
• Naming Convention: because of the breaking changes like MWD version and entry point, existing design time assemblies developed against 3.5 MWD will not load in Blend 3 and Visual Studio 2010, you have to write new design time against the new 4.0 MWD for Blend 3 and Visual Studio 2010. While this is OK for Blend (since you can only use Blend 3 with Silverlight 3 and Blend 2 with Silverlight 2), this creates a challenge for Visual Studio, since you can use Visual Studio 2008 for Silverlight 3 development, as well as Visual Studio 2010 for Silverlight 2 development.

Below table lists all supported scenarios and which version of MWD is used to load design time assemblies:

We can’t build one design time assembly against two incompatible MWDs, so we have to create two separate design time assemblies, one against each MWD. Design time assemblies are loaded by name, and we can’t have two assemblies with the same name in the same location, so the design time assembly loading mechanism (i.e., the naming convention) has to change, to allow multiple versions of the same design time assembly coexist.

While waiting for the new naming convention to come out with Blend 3 and Visual Studio 2010 RTM, we can do something clever now to support both VS9 and VS10. Remember current naming convention allows Visual Studio and Blend each to load two design assemblies:

so we can build the two assemblies against different versions of MWD:

• For Silverlight 3, we can have the shared .Design.dll build against MWD 4.0, so it can be loaded by both VS10 and Blend 3. We then have .VisualStudio.Design.dll build against MWD 3.5 and duplicate everything from shared .Design.dll, so it can be loaded by VS9. There is one minor issue though: we don’t have a place to put Visual Studio specific design time features for VS10, like using ToolboxBrowsableAttribute(false) to hide some controls from the increasingly crowded Visual Studio toolbox, since VS10 can’t load the .VisualStudio.Design.dll build against MWD 3.5. This will be solved with the new naming convention once Visual Studio 2010 RTM.

• For Silverlight 2, follow the same approach: have the shared .Design.dll build against MWD 4.0, but have both .VisualStudio.Design.dll and .Expression.Design.dll build against MWD 3.5 and duplicate everything in shared .Design.dll. This way, both VS9 and Blend 2 will work just fine, but with the  same issue that there is no place to put Visual Studio specific features for VS10. Again, that will be solved with the new naming convention in VS10.

Design Time Feature Implementation in Silverlight 3 Toolkit

MWD

The design projects in Silverlight 3 Toolkit in March 2009 Release followed above mentioned scheme to support both Visual Studio 2008 and Visual Studio 2010, as well as Blend 3.

Download the March 2009 Release, unzip the source code, load Silverlight.Controls.Design.sln into Visual Studio 2008. Use the simpler Control.Input.Design project as example:

• Design projects for VS9/Blend3 need to reference the new 4.0 MWD. Here we use pre-build event to invoke CopySystemWindows.bat to locate Blend 3 and copy the two  MWD dlls to Binaries directory.
• Please note the minor changes to CopySystemWindows.bat file: we need to quote “%THIS_DIR%\Binaries\Blend3” (lines in yellow) to handle cases where there is a space in the path to the directory the source code is unzipped to.

If you don’t like the fragile CopySystemWindows.bat file or using build events, you can set Reference Paths to help Visual Studio find where the new MWD is, as shown below. The only caveat is that you need specify both %programfiles% and %programfiles(x86)% to make it build on both x86 and x64 machines.

The reference paths setting is persisted into the .csproj.user file:

<Project xmlns=”http://schemas.microsoft.com/developer/msbuild/2003″>
  <PropertyGroup>
    <ReferencePath>c:\Program Files\Microsoft Expression\Blend 3 Preview\;c:\Program Files (x86)\Microsoft Expression\Blend 3 Preview\</ReferencePath>
  </PropertyGroup>
</Project>

Metadata.cs

I use the same implementation framework as described in Design Time Feature Implementation in Silverlight Toolkit, with some minor changes:

• I moved links to shared files Extensions.cs and MetadataBase.cs from Controls.Design.Common folder to under a solution folder with the same name;
• Metadata.cs in .Design and .Expression.Design projects use the new entry point: use ProvideMetadata assembly attribute, and implement IProvideAttributeTable interface;
• add note that everything in AddAttributes() method needs to be duplicated in corresponding .VisualStudio.Design project.

The .VisualStudio.Design projects still use the old IRegisterMetadata interface in MWD 3.5, but:

• under Controls.Design folder are links to all *Metadata.cs files in corresponding .Design project;
• AddAttributes() method duplicates the content of AddAttributes() method in corresponding .Design project.

Conclusion

While the breaking changes in MWD may cause some inconvenience, it is necessary to implement as rich a design time experience for Silverlight as for WPF. This post describes a way to handle the breaking changes and still support all existing designers: Visual Studio 2008, Blend 2, and Blend 3. Once Visual Studio 2010 is publicly available, I will blog about the new naming convention, and how Toolkit design time work in Visual Studio 2010. Stay tuned!