Category Archives: C#

One of the new features, a.k.a. syntactic sugars, in C# 3.0 is extension methods. At first, it looks like compiler magic and it is no big deal. But isn’t it the same about class method? When a function argument is hidden, suddenly whole world changes. Clearly, OOP is not just a hidden this pointer, but we can think of extension methods as class methods that will only access the public fields. This may look like a step backwards but we are not living in an ideal world, in fact not even close to ideal. This is more like a side-step that will provide new ways forward. One of these new ways is LINQ, language integrated query. However, it is hard to come up with another as useful as LINQ. Is there a way to utilize extension methods in WPF as we did lambda expressions?

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.

This time, I will skip the introduction and jump right into technical stuff.

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.

1

2

3

4

5

6

7

8

9

10

11

12

13

<StackPanel>

<Sliderx:Name="Red"Value="255"Minimum="0"Maximum="255"/>

<Sliderx:Name="Green"Value="255"Minimum="0"Maximum="255"/>

<Sliderx: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

As a mathematician, I always had a fondness for languages. As a programmer, this fondness became a devotion. Some might think that language is just a part of implementation which follows analysis and modeling. I agree that implementation is the least important one. I agree that it is like a tool for implementation, you can choose one or the other. I agree that a separate article, -which does not contain WPF in its header-, is more appropriate for this kind of topic. However, I also believe that programming languages have a much broader effect which includes modeling and even analysis. Our process of thinking is effected by our ways of communication.

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.

1

2

3

4

5

<!--*.xaml-->

<l:ShortTimeConverterx:Key="ShortTimeConverter"/>

...

<TextBlock Text='{Binding Source={x:Static s:DateTime.Now},

Converter={StaticResource ShortTimeConverter}}'/>

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

// *.xaml.cs

publicclassShortTimeConverter:IValueConverter

{

publicobjectConvert(objectvalue,Type targetType,

objectparameter,CultureInfo culture)

{

DateTime dt=(DateTime)value;

returndt.ToShortTimeString();

}

publicobjectConvertBack(objectvalue,Type targetType,

objectparameter,CultureInfo culture)

{

thrownewNotImplementedException();

}

}

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.Continue reading →