Using Styles From Different Class Library In Silverlight

For re-use purposes, it is helpful to put Silverlight styles into a separate class library; let’s call it ResourceLibrary in this example.

In the class library which is using the styles from ResourceLibrary, one should declare a Styles.xaml, which only contains a reference to ResourceLibrary:

<ResourceDictionary
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
  <ResourceDictionary.MergedDictionaries>
    <ResourceDictionary 
      Source="/ResourceLibrary;component/Assets/Styles.xaml"/>
  </ResourceDictionary.MergedDictionaries>
</ResourceDictionary>

The using class library is called UsingLibrary here.
To be able to render the controls contained in UsingLibrary in Visual Studio’s designer, the xaml needs to contain the following declaration:

<UserControl.Resources>
  <ResourceDictionary 
    Source="/ResourceLibrary;component/Assets/Styles.xaml"/>
</UserControl.Resources>

For some kind of controls, this code is not valid, e.g. for controls based on Telerik's RadWindow class.
So I took the following approach:

<Control.Resources>
  <ResourceDictionary 
    Source="/ResourceLibrary;component/Assets/Styles.xaml"/>
</Control.Resources>

The designer was happy (styles were resolved in design mode), the compiler was happy too, but the runtime wasn't.

An exception occurred complaining that "Local values are not allowed in resource dictionary with Source set". Whatever that means…

The way out was to replace the resource dictionary declaration with the following code:

<Control.Resources>
  <ResourceDictionary>
    <ResourceDictionary.MergedDictionaries>
      <ResourceDictionary 
        Source="/ResourceLibrary;component/Assets/Styles.xaml"/>
    </ResourceDictionary.MergedDictionaries>
  </ResourceDictionary>
</Control.Resources>

To me, a little bit unexpected. Why does the designer and the compiler like the short version, while the runtime doesn't?!

The environment was VS 2010 SP1 and Silverlight 4.

Why Silverlight Binding’s StringFormat Property Sometimes Isn’t Fully Working

In Silverlight 4, the new Binding property StringFormat was introduced. It’s a nice thing, e.g. if you want to display numeric values with digit grouping and a fix number of decimal places. The syntax is equal to the String.Format: {Binding DataContextProperty StringFormat=’#,##0.00′}. One can, of course, use it for other simple types like DateTime…

I was using this feature in a project in one control, and it worked as expected. Then I created a new UserControl, and the trouble began. When the control showed up, the value was display as set by the StringFormat expression set in the xaml file. But after entering a new value, the formatting was gone.

It took me some time to figure out what the difference was. And it was not found in the xaml!

What I noticed was that the control working correctly as long as it was bound against a property of a class that was generated from a WCF Service Reference. Means, this class was originally declared inside the WCF Service assembly, and because it was part of the operation contract declared by the WCF Service, VS generated that class (or kind of proxy) in the Silverlight project as well.

When I bound the newly created control to an instance of this operation contract class, without changing the xaml, everything worked as expected.

So what is the difference? First of all, I bound the new control to (a property of) an instance of a class that was declared inside the Silverlight project itself.

The class looked like this:

public SilverlightClass
{
public decimal Value { get; set; }
}

Comparing it to the operation contract class, first thing I noticed was that that class not only had properties, but it had also data members (fields) which are encapsulated by corresponding properties.

So I changed the Silverlight class to something like this:

public SilverlightClass
{
private decimal m_Value;

public decimal Value
{
get { return (m_Value; } set { m_Value = value; } }
}

But still, the formatting did not work. So I “copied” the other difference: the operation contract also implemented the INotifyPropertyChanged interface and raised a PropertyChanged event whenever a property was set to a new value. This lead to the final version of the Silverlight class:

public SilverlightClass : INotifyPropertyChanged
{
private decimal m_Value;

public decimal Value
{
get { return (m_Value; }
set
{
if (!m_Value.Equals(value))
{
m_Value = value;
RaisePropertyChanged("Value");
}
}
}

public event PropertyChangedEventHandler PropertyChanged;

private void RaisePropertyChanged
(
string propertyName
)
{
if ((PropertyChanged != null))
{
PropertyChanged(this,
new PropertyChangedEventArgs(propertyName));
}
}
}

And that was it… Since my knowledge of Silverlight and its mechanisms is very little, I was a little bit surprised.

Having the Silverlight class changed like that, also the update of the bound controls worked when the code behind changed the bound property of the DataContext during runtime (e.g. by a LostFocusHandler).

Large Message Size And Bad Request on WCF Service

In an application I built, using Silverlight Client and WCF Service, the application threw an exception when the request data passed by the client to the server exceeded about 64K (might be a little bit less).

Using a TCP tracer, I saw that the client received a “bad request” error.

Looking around a little bit, the solution was quite easy.

When creating a service reference in the Silverlight project using Visual Studio, the ServiceClient.config already contains the maxBufferSize and maxReceivedMessageSize properties.

What is missing are the corresponding settings in the WCF Services’s web.config. So just put a

<bindings>
<basicHttpBinding>
<binding maxBufferSize="2147483647"
maxReceivedMessageSize="2147483647">
</binding>
</basicHttpBinding>
</bindings>

section inside the system.serviceModel node, and you’re done 🙂