Since the first day I learned about WPF, I almost never used a UI designer tool. Perhaps, that is why I started using XAML everywhere I could, one could say it was love at first sight. They say love lasts roughly 3 years and even though it has been a little bit longer than that for me, I still feel strong about it. Lucky for me, Microsoft does also. Together with the recent release of VS2010 Beta 2, XAML finally has its own assembly, System.Xaml.dll targeting .NET Framework 4 Beta 2. I have now plenty of projects which can loose their dependencies on PresentationCore.dll, PresentationFramework.dll and WindowsBase.dll. I hope to convert them all easily and start making more.

First one to go was my almost forgotten open-source project Geostructor. I was expecting minor problems but I was wrong. I had none except the fact that, I had unconsciously created dependencies on WPF assemblies. After moving those dependent codes to where they really belong, I was ready to go with one little replacement. Replaced all class references of XamlReader and XamlWriter with the new XamlServices class. Not only everything worked as expected, some of my problems were gone too. This is what made me to write about the problem.

Back when I first encountered this problem, I was planning to post my solution here. Then, I heard about a new feature in the upcoming System.Xaml.dll and thought I should wait for it. In other words, I was lazy. So here it goes:

Old Problem

Here is a sample file saved by Geostructor v0.3, which targets .NET Framework 3.5 SP1:

<GObjectCollection xmlns="http://www.fikrimvar.net/lestirelim/?cat=10">
  <FreePoint Position="0,0" Name="A" />
  <RelativePoint RelatedPoint="A" Offset="20,10" Name="B" />
  <RelativePoint RelatedPoint="B" Offset="10,20" Name="C" />
</GObjectCollection>

Here, RelatedPoint property of RelativePoint is of type IGPoint which inherits INotifyPropertyChanged interface. RelatedPoint objects listen to the PropertyChanged events of the referenced objects. In order to keep these references after saving and loading back, I had to prevent XamlWriter from producing such result:

<GObjectCollection xmlns="http://www.fikrimvar.net/lestirelim/?cat=10">
  <FreePoint Position="0,0" Name="A" />
  <RelativePoint Offset="20,10" Name="B">
    </RelativePoint.RelatedPoint>
      <FreePoint Position="0,0" Name="A" />
    </RelativePoint.RelatedPoint>
  </RelativePoint>
  ...
</GObjectCollection>

Old Solution

First, I tried to extend the XamlReader and XamlWriter by providing custom services. However, I remember I was blocked by various finalized classes. The solution I came up with was to mark reference properties with attributes, converting these references to unique strings (by taking their Name property). Later, during XamlReader, again I had to convert these string values into place-holder objects. Remember, converters had no way of knowing the current context. When XamlReader is done and I have the collection, I had to go through the elements and replace the place-holders:

foreach (var item in loaded)
{
    GObjectFactory.RecordName(item, item.Name);
    var refs = (from prop in item.GetType().GetProperties()
                let value = prop.GetValue(item, null) as PlaceHolder
                where value != null
                select new
                {
                    Name = value.ElementName,
                    Setter = new Action<object>(v =>
                    {
                        prop.GetSetMethod().Invoke(item, new object[] { v });
                    })
                });
    foreach (var ph in refs)
    {
        ph.Setter(loaded.Where(o => ph.Name.Equals(o.Name)).First());
    }
    this.Graph.Add(item);
}

No Problem

Here is the new saved file in Geostructor v0.4, which targets .NET Framework 4.0:

<GObjectCollection xmlns="http://www.fikrimvar.net/lestirelim/?cat=10"
                   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
  <FreePoint Name="A" Position="0,0" />
  <RelativePoint RelatedPoint="{x:Reference A}" Name="B" Offset="20,10" />
  <RelativePoint RelatedPoint="{x:Reference B}" Name="C" Offset="10,20" />
</GObjectCollection>

In order to achieve this, you have to do nothing, thanks to Reference Markup Extension which actually utilize the IXamlNameResolver Interface. It has been a long wait since Rob announced this feature. Not that I am complaining, now I have to go through the code and remove the unnecessary attributes and converters. Also I should probably investigate possible usage of this new service in WPFix library.

Hopefully, I will keep on posting more about what I have to remove from my code instead of adding. BTW, to most, this is probably one of the least awaited feature in VS2010, and they are right. Go check out the Beta 2, it is much better than Beta 1.

Power is nothing without control

Problem:

Visual editor’s job is to display the workflow in a tree view fashion. I chose displaying listboxes inside listboxes instead of a treeview. Each last node has an expander inside the listboxitem container. When user expands an item, containing listbox grows to display all of the items. I have no problem with that, in fact, that is exactly what I am grateful for. There is one catch, though. Expander controls not only expand but also shrink. When it does, listbox sits back and enjoys the void. A small sample to play with:

  <StackPanel>
    <ListBox x:Name='xNoFlower'
             Background='Fuchsia'
             ScrollViewer.CanContentScroll='{Binding ElementName=xAgreed, Path=IsChecked}'>
      <ListBoxItem Background='White'>
        <Expander Header='Click me'>
          Again please
        </Expander>
      </ListBoxItem>
    </ListBox>
    <TextBlock Text='Check if you object' />
    <CheckBox x:Name='xAgreed' IsChecked='True'>
      On a flower, every color is nice.
    </CheckBox>
  </StackPanel>

Solution:

You probably did know this. I did also, however when things are under multiple levels of ControlTemplates, DataTemplates and Styles, I was reluctant to go deep and investigate. Actually, I was reluctant to do anything at all. I had a great new years eve party and a greater headache. Luckily, WPF also provides an easy solution. Although, I spent a lot time to guess the problem.

    <Style TargetType='{x:Type ListBox}'>
      <Setter Property='ScrollViewer.CanContentScroll'
              Value='False' />
    </Style>

Am I wrong to think that this was the default behavior when a control with a scrollviewer is not bounded? If I am, I can easily blame it on countless shots or hitting the floor so many times. Who else did work Friday, just to see “s?he” could not?

I was at the riatalks, a two day event at two separate conference halls. I worked out a plan and was going to be able to attend all talks that interested me. However, I forgot one small thing, timing is not an additive function around here. At the first day, even though some presenters couldn’t make it, talks was not over when I had to leave.

At that time, my body had a few reservations already. Some of you might know, snooker is a demanding game, physically and mentally. So I had to shutdown the message queue completely. In contrast, I had my personal best after 5 hours and just before my last sip at 2 A.M. Snooker is sometimes called chess with balls, however chess is a rather simple game. Snooker is pretty much Go with sticks to me.

Second day things got worse, time wise. I kept running between the halls, to see if any starts on time. Still I had the chance to chat with yesterdays last presenter, Daron Yondem. Daron and Ferruh Mavituna (in Turkish) had the best presentation skills at the talks. I am certainly not an authority but I can at least suggest everyone to read scott’s tips. Needless to say, I had to leave early for another round of snooker.

I closed the weekend with another physical challenge. We went to “The Dark Knight” at an IMAX theater, together with my snooker body. I heard the most stupid excuse to not giving a break, “… since this is an IMAX …”. Rest should be ” and as technology advance, we go backwards …”. I know intermissions are not common in most of the countries, but this movie’s length is not common either. I was cool with it but I saw people suffer.

Everyone suggests watching the movie in an IMAX theater however even 4K resolution is not enough at a big enough screen. Simple division that is, however if you had seen the movie, you might wanna check out how other math guys watched it, beware of the spoilers.

Today, I can tell by the mirror that breaks are necessary, so here is one.

Anyway, I started to use C# and I was happy until 3.0. Wait, wait, I know what is going to happen if I don’t make myself clear. C# is my language of choice when I need UI; but, you can never stop programming in C++. If I happen to use both of them for a project, I constantly switch between C++, C++\CLI and C#. This is where the trouble begins. Before C# 3.0, I could say that my productivity was pretty much the same in each one of them. After 3.0, I caught myself trying to accomplish everything in C# as much as I could. Easiest way is not always the right way. Again, I have got to skip this if I want to finish this post. The point is, I use C# more and more everyday.

I have always had complaints about C# but a few days ago, I realized that some differences in programming languages are harder to overcome than I thought. I usually make a mistake, caused by experiences in another language, once or twice. What I have found out is that, if I can’t rationalize the difference, I make it all the time.

Suppose you wrote an interface which has a property with no setter. You also wrote lots of classes, implementing this interface. As long as these classes implement a public getter for the property, there is no problem, right? One day, you realize that number of these classes will increase and all will benefit from an abstract base class. (As a side note; there are no distinctions as interfaces or abstract classes in C++. There are classes without any implementation and partially implemented classes which could stand as counter-parts respectively. So, the following problems have no counter-part in C++) First of all, your new base class must declare (copy) all members of the interface as abstract members if there is no implementation. Is this really necessary? Secondly, you have to mark all of your previous implementations with override. I hear you saying, I can do all of these with a couple keyboard shortcuts, thanks to my refactoring tool. Last but not least, you can not do this all the time without changing your design of previously written classes. That’s right! Suppose one of your implementations also provide a public setter for our non-problematic-looking property, and another one with a private setter. Can you tell the problem?

Do you think in or out of your language?

P.S. This post is a side product of a project, I promised earlier, GeoStructor. Its code does not contain a solution to the problem above, so has lots of repetition. Actually, code requires lots of changes. When that happens, I will probably write another WPF related article which will include some techniques (regarding XamlReader/XamlWriter, Dragging, etc.) I used.

P.P.S. Initially, I tried to explain a problem without codes in order to provoke thinking. However, discussions will be healthier with a sample. Please expand to see the code. Sorry about the naming.

namespace abstractobstruction

{

interface IInterface

{

int GetMe { get; }

}

class Class1 : IInterface

{

public int GetMe

{

get;

private set;

}

}

class Class2 : IInterface

{

public int GetMe

{

get;

set;

}

}

}

Now, I realize that I felt obliged to keep the style. I didn’t want to steal readers’ time with my personal ramblings. Each time I started writing a new post, I found a different reason not to. Sometimes, I wasn’t happy with the quality. Some were a lot more time consuming than it should be, especially C++ ones. I wanted to write articles which were original if not extra-ordinary. Well, I couldn’t be more wrong. I have got to make mistakes and make them soon. Not only that, I know why I want to make mistakes. Here is the story.

Last month, I made a few important decisions about my life. Maybe the most important of all was to quit my job. It was a sudden decision. After a couple of though weeks, I managed to clean up my ongoing tasks and proved my sketches to my ex-co-workers. I had no plans, whatsoever. Initial reactions were like “- Where is your new workplace ? — There isn’t any “. Only a few close friends did not act as if I had lost my mind. Without a regret, I gave myself a few weeks of rest. A sabbatical year is not common among programmers, I suppose. I don’t want to be an exception either. Still, I couldn’t decide what to do. I’ve had times, considering opportunities abroad. Although, most suitable jobs for me are located in the States, family stuff keeps me in İstanbul. To keep a long story short, I want to target software developers and the reason of this alone requires a new post.

Yesterday, when I started my computer, I had over 500 unread posts on my reader. I read reluctantly until an inspiring post by Jeff Atwood. In my case, I feel like closing without a bookmark and going to open a random page. I want to keep reading this programming book and wish, I could read it all. It’s just that, I suspect a lifetime is not enough. There were still over 500 posts, waiting for me to read, but I decided to add one for you. For now, it looks like my adventures on inventing new ways to program will continue on this blog. I can wait a couple of more years. In the mean time, I hope this blog will gain weight and help me along. By the way, for a retirement plan, I imagine myself as a benevolent dictator of a new programming language ( a country would also do ) and bashing the young guys, who never stops coming with all kinds of strange ideas!

P.S. If you were expecting a WPF related article, soon I will write another post about an open source project of mine.

While introducing the lambda converters, I said that implementing IValueConverter or IMultiValueConverter is not a complete waste of time. There were two reasons behind this statement and hence two problems ahead of lambda converter with dreams of being the ultimate binding converter.

Problem 1

One of them was code maintainability in large projects, where a converter can be used more than once. Typing the same expression again and again is not an option.

Solution 1

Idea occurred to me, while reading Kent Bogaart’s article on WPF converters and Josh Smith’s article on piping value converters. They have both suggested a way to reuse and combine converters. Then, I had one of those, wait a minute, moments. This is where extension methods kick in. We could write our Convert method in an extension method and use them inside the expressions. Not only, maintaining these converters will be easier, but also they will be combinable by nature.

<TextBlock Text='{Binding Source={x:Static s:DateTime.Now},
	Converter={fix:Lambda "dt=>dt.ToOurFormat().ToUpper().InsideParenthesis()"}}'/>

Again, we had to make a few changes to the Dynamic Expression API. Looking for extension methods will be a last resort in a function call. We have the type of the instance, but unfortunately extension methods won’t show up in the type’s methods. These methods are defined in a seperate static class, but they are instance methods. Is there a contradiction here? No, static keyword’s original meaning is that the following function’s address will be constant. It does not mean that function belongs to a class rather than an instance. Here, static denotes that all elements inside the class will be static methods. Extension method calls does not provide the these extension types, so we have to find out all of the static classes before making a decision.

You can skip this paragraph if you are not interested in the details. If you take a look at these classes by reflection, you will notice that they are nothing but abstract sealed classes. At the first call to our new GetExtensionMethod method, we will query these kind of types and put their suitable public static methods in to a lookup table. These methods must have a return value and at least one parameter. If two extension methods with same name and suitable parameters are ambiguous according to the current implementation. Implementation is not hard but I had to take a look into the standards. Please, feel free to ask for an implementation if you ever need one, or better you could provide your suggestion if you are not lazy as I am right now. Thanks to LINQ, this addition took less than half an hour. I am thinking of a series dedicated to LINQ. Again, I surrounded the necessary changes to dynamic.cs by WPFix regions.

Problem 2

The other one was the ConvertBack method, which had no counter-part in a lambda converter. Now that lambda converters are suitable for multiple uses, the need for a backward conversion is higher.

Solution 2

We will simply provide a second expression as a parameter to our markup extension class, LambdaExtension. I was going to simply use another constructor with two parameters, but I guess things are different now that the VS 2008 is released. We have to use the name/value syntax to support backward conversion.

<TextBox Text='{Binding ElementName=panel, Path=Background,
		UpdateSourceTrigger=PropertyChanged,
		Converter={fix:Lambda
			Forward="c=>c.ToColor().ToFriendlyName()",
			Backward="t=>t.ToColor().ToBrush()"}}'/>

I’m still not sure about multibinding and backward conversion. I did write the required changes, however I didn’t even test it once. I will if I have such a need. Can you point out such a case?

Conclusion

Although it is not production quality code, you can download WPFix3 Solution (VS 2008) and take a look. Don’t you wish your RTM had something like hot this? Now, if only intelli-sense was extensible enough.

With this post, I am putting a break on WPFix series. In the future, I will continue the series, with hopefully something different than binding and converting. Until then, I will continue updating codes according to your feed-backs.

In the previous post, I tried to reduce XAML’s dependency to code files for even the simplest operations. There were a lot of ways other than my lambda converter. We could write a custom binding which could save a lot more of typing. However, my intention is not to type less, but to keep relevant parts together. Still typing less does not hurt, as long as it is clear. We will come back to this, but before that …

Problem 1

Suppose we have an adjustable background color. Don’t worry, I am not going to write another custom color picker for WPF. I will try to use the lambda converter.

<StackPanel>
	<Slider x:Name="Red" Value="255"  Minimum="0" Maximum="255"/>
	<Slider x:Name="Green" Value="255" Minimum="0" Maximum="255"/>
	<Slider x:Name="Blue" Value="255" Minimum="0" Maximum="255"/>
	<StackPanel.Background>
		<MultiBinding Converter='{fix:Lambda
			"r,g,b=>SolidColorBrush(Color.FromScRgb(1,r/255,g/255,b/255))"}'>
			<Binding ElementName="Red" Path="Value"/>
			<Binding ElementName="Green" Path="Value"/>
			<Binding ElementName="Blue" Path="Value"/>
		</MultiBinding>
	</StackPanel.Background>
</StackPanel>

Parsing this lambda expression looks a bit harder. Multiple parameters are not a problem but SolidColorBrush and Color classes are.

Solution 1

Without any modification, Dynamic Expression API will throw an exception in this case. Luckily it is possible to construct predefined System types ( such as DateTime) with the API, and we already have a way to convert strings to types. IXamlTypeResolver is one of the two services provided by WPF at the ProvideValue method of any Markup Extension. All I had to do was to use this service and act as a last resort to the parser. You will be able to find the required changes to dynamic.cs at the new zipped solution. I surrounded the changes with regions named WPFix.

Now, the above code is working smoothly. If you had the opportunity to look into the dynamic.cs, you know that there are a lot ways to improve it. First thing that pops up is that the above expression is not even a valid lambda expression. There should be a new keyword before SolidColorBrush, but such conformance required more changes and does not bother me at all.

Problem 2

The amount of typing increased by a considerable margin (let me repeat that my intention is not to type less). This increase does not come along with clarity, also. In fact, we now have to keep bindings and parameters ordered.

Solution 2

Lets also provide an alternative to MultiBinding class which does not have a corresponding Markup Extension.

...
<TextBlock Text='Negative' Foreground='{fix:Binding
	r={fix:Element Red.Value}, g={fix:Element Green.Value}, b={fix:Element Blue.Value},
	Expression="SolidColorBrush(Color.FromScRgb(1,1-r/255,1-g/255,1-b/255))"}'/>

There are a few points to remark in the above code. The least interesting part is the Element Markup Extension. Please note that, this is not a complete alternative to a normal Binding with an ElementName. Path property of a Binding is not a simple string, and the code below does not treat it the way it should. Code speaks better sometimes.

public class ElementExtension : MarkupExtension
{
	public ElementExtension(string nameAndSimplePath)
        {
		this.Binding = new Binding();
		int pi = nameAndSimplePath.IndexOf('.');
		this.Binding.ElementName = nameAndSimplePath.Substring(0, pi);
		this.Binding.Path = new System.Windows.PropertyPath(
			nameAndSimplePath.Substring(pi + 1, nameAndSimplePath.Length - pi - 1));
	}

	public override object ProvideValue(IServiceProvider serviceProvider)
	{
		return this.Binding.ProvideValue(serviceProvider);
	}

	private Binding Binding;
}

Notice that I do not expect a IMultiValueConverter as a converter. The rationale is that, specified bindings are associated with parameter names and they belong to a lambda expression.

What gives us the ability to set r, g and b as properties, is that they really are properties of BindingExtension! Eventually, so are the other characters in the alphabet. Even the possibility of this idea was intriguing at first, but when I think about it, it looks like a natural way. We just want to associate a binding with a short literal that we can use in an expression, possibly many times.

Suggestions are welcome. Tell me what do you think about this approach?
WPFix2 Solution (VS2008 Beta 2)
Solution file is updated, thanks to the feed-back. I have to admit, I am surprised by the interest shown, at the very beginning at least .

Eventually, I will connect this to WPF, somehow in the future. In the last few years, I suppose the number of new programming languages has an exponential growth if we also include the new versions. Some believe that domain specific languages will reproduce asexually, some believe that languages converge to one as they copy their best parts. Even if there is a convergence, there is long way on which we speed up. My guess is that the hypothetical unified programming language, which will be the base of many domain specific languages and will act as a connection between them, will be the way to go. While waiting, I suggest we learn a few of these doomed languages. I hope, we will together witness how less these paths are traveled. I promise that following this post, my technical and theoretical musings will also travel separately. But now, lets start by a few technical ones. C# 3.0 and XAML are two new languages in two different paths. Lets get them together!

I always try to defend WPF in discussions with my colleagues. However, I will try to criticize WPF in this series of articles, namely WPFix. Visual Studio 2008 is to be released by the end of this month but I think, WPF and XAML still have a long way to go. Don’t get me wrong, I am just as glad as you are. I only wish, there was a better way than lengthening the evaluation period to spread the ideas. I will try to keep my critiques precise and search for practical solutions. Hopefully, I will also provide introductory links.

Problem

Data binding is pretty much the heart of WPF. We can think of WPF as a pretty complicated converter which consists of little converters for simple data types. However, these converters in the XAML may appear smaller than they are.

<!-- *.xaml-->
<l:ShortTimeConverter x:Key="ShortTimeConverter"/>
...
<TextBlock Text='{Binding Source={x:Static s:DateTime.Now},
	Converter={StaticResource ShortTimeConverter}}'/>

// *.xaml.cs
public class ShortTimeConverter : IValueConverter
{
	public object Convert(object value, Type targetType,
		object parameter, CultureInfo culture)
	{
		DateTime dt = (DateTime)value;
		return dt.ToShortTimeString();
	}

	public object ConvertBack(object value, Type targetType,
		object parameter, CultureInfo culture)
	{
		throw new NotImplementedException();
	}
}

This may not be a complete waste of time from code maintenance perspective. But we, mortals, sometimes need a more practical method.

Solution

A similar problem in C# has been resolved lately by lambdas. You are no longer have to declare your method which won’t be used anywhere else. Here comes another future article name to my mind, maintenance is overrated. Personal Note: Use more controversial article names than WPFix Part 1. Back to our problem, we need a way to express ourselves in XAML. By express, I mean code. Hence lambda expressions.

<TextBlock Text='{Binding Source={x:Static s:DateTime.Now},
	Converter={fix:Lambda "dt=>dt.ToShortTimeString()"}}'>

Is this too much to ask? Well, this article already took more time than to make the above code work. All I had to do was to put together some existing parts. First of all, we need a markup extension that will construct the converter.

public class LambdaExtension : MarkupExtension
{
	public string Code { get; private set; }

	public LambdaExtension(string _code)
	{
		this.Code = _code;
	}

	public override object ProvideValue(IServiceProvider isp)
	{
		IProvideValueTarget tp = isp.GetService(
			typeof(IProvideValueTarget)) as IProvideValueTarget;
		if (tp.TargetObject is Binding)
			return new SingleConverter(this.Code);
		if (tp.TargetObject is MultiBindingExtension)
			return new MultiConverter(this.Code);
		return null;
	}
}

Now, we have a string to parse. Don’t worry, we also have a parser, provided by microsoft. I guess, WPF team and LINQ team do not see each other very much. Take a look at the Dynamic Expression API, which can be found under the samples directory of your VS2008 Beta2 installation. You can also download these samples from this msdn page by following the LINQ samples link. The treasure is inside dynamic.cs source file which also has a nice documentation. Serendipity never leaves me alone.

class SingleConverter : IValueConverter
{
	public Delegate Operation { get; private set; }
	public string Code { get; private set; }

	public SingleConverter(string _code)
	{
		this.Code = _code;
	}

	public object Convert(object value, Type targetType,
		object parameter, System.Globalization.CultureInfo culture)
	{
		if (this.Operation == null)
		{
			ConstructOperation(value, targetType);
		}
		return this.Operation.DynamicInvoke(value);
	}

	public object ConvertBack(object value, Type targetType,
		object parameter, System.Globalization.CultureInfo culture)
	{
		throw new NotImplementedException();
	}

	private void ConstructOperation(object value, Type targetType)
	{
		int opi = this.Code.IndexOf("=>");
		if (opi < 0) throw new Exception("No lambda operator =>");
		string param = this.Code.Substring(0, opi);
		string body = this.Code.Substring(opi + 2);
		ParameterExpression p = Expression.Parameter(
			value.GetType(), param);
		LambdaExpression lambda = DynamicExpression.ParseLambda(
			new ParameterExpression[] {p}, targetType, body, value);
		this.Operation = lambda.Compile();
	}
}

You can download WPFix1 Solution (VS2008 Beta 2) and start playing. How much longer would you wait, if you knew a similar but standardized way of writing code in XAML will be available with the release? By the way, welcome to my web log.
This download is now outdated. Solution files are updated on the following parts of this series. I know you want to get your hands dirty, but please keep reading. Thanks to chaiguy1337 for reminding.