[Please read this post before starting to read this one]

In my previous post I talked about how one can embed code in XAML using the Dynamic Expression API. I was thinking on how to expand this even more. And I figured out… What if I use this for the Filter event of the CollectionViewSource…. Well I tried it out and it ended up working quite well…. What is even better is that you can allow the user to enter a string that is then compiled in a Lambda expression and applied for filtering data

So basically my implementation includes an Attached Property that you can use for a CollectionViewSource. This property is called FilterExpression and is in the class called LambdaCollectionView. All you have to do is to pass a string that is the filter expression that you want to evaluate for filtering. As context for your expression there is a predefined variable called item that is basically the type of object that you have in the collection…. example, if you a list of strings you can treat item as a string (i.e you can use all string functions such as StartsWith etc….)
Let’s do a small example on how you can use this. Imagine you have a list of strings and you want to apply a filter that filters all strings that do not start with the character M. you would do something like this

As you can see here you have to use the $ symbol for strings just like in the LambdaValueConverter. Ok ok… so this is cool but what is even cooler is the fact that you can make the user decide how to filter

In the demo app I created a textbox and a button. The user can enter an expression in the textbox and when the button is clicked I reset the FilterExpression property and bamm the filter changes… In the textbox the user does not need to use the $ symbol for strings since the textbox handles ” unlike the XAML parser….

This is very handy if you want to apply some basic filtering from the UI…. The filter also supports user friendly expressions like Not instead of != and many others.. For a complete list of supported expressions read the Dynamic Expressions.html under the Dynamic Query folder (inside the download)

Hope you like this and give me more feedback on the AvalonLambdas ….

Regards

Download Source Code

Loads of time I needed a converter that does a very small operation such as binding to the Height of an element and subtract 10 from the binded value. Every time you have to create a converter to do so. I must admit, it really makes me angry because I would like to this in XAML.

I found this cool code sample on Dynamic Expression API from msdn and I thought why don’t I use it to be able to embed code in XAML…. Apparently I am not the first one trying this out . While having a chat with WPF Guru, Josh Smith, he pointed out that someone else created something similar. M. Orçun Topdağı did a very great job in creating converters that can be declared in XAML. Great Job dude!!! It is really unfortunate that I found out about this after I created my own

Anyway now that I did it might as well show it to you guys right So basically this is quite simple. I created a Markup Extension called LambdaValueConverter that creates an instance of a converter that accepts a LambdaExpression which is then compiled (using the Dynamic Expression API) and run whenever the binding for the converter changes. In order to use this LambdaValueConverter you have to pass the Lambda Expression that you want to evaluate when the binding changes. Let me give you an example. Imagine you want to bind to the Height property of a Grid and divide it’s height by 2 and subtract 20. You would do something like this in the Binding

As you can see this is quite easy to use… It is important to note that param is a predefined variable that holds the binding value (in the case of this example it will be a Double since we are binding to the height property of a Grid). In the expression you can write anything that is supported in the Dynamic Expression API.

One handy feature I added, is support for strings. Imagine you want to concatenate a string with a binding value. Instead having to create 2 TextBlocks and loads of other things, all you have to do is to enter the text you want + the param that is supplied to you by the converter. You have to surround your string with the $ symbol(don’t ask why I choose this symbol ) in order for the parser to know that the specified text is a string. It would look something like this….

So as you can imagine the output of this binding will be >> The border size is {the value of the binding}.

Cool…. Yet I wanted to go a step further. Basically I asked myself and said, “where can this fit besides for converters” and BAMM… I said what about having such a feature for the CanExecute of commands.. Usually in the can execute of a command all you do is a one line of code yet you have to create an event handler every time (same problem as converters!) So I created a class that inherits from the CommandBinding class and extended it to support a expression string that can be evaluated as the CanExecute event handler. In order to use this all you have to do is, create an instance of the CommandLambdas class and set the CanExecuteExpression property with a string that is your expression. As context of the expression there are two predefined variables that you can use. param that is the parameter that you are passing for the command and e that is the CanExecuteRoutedEventArgs for the CanExecute event. Lets make an example. Imagine that you have a checkbox that determines if the Command for a button can execute or not. The code for the Button would look something like this

Just for the sake of the demo I used the Application.New command so that I don’t have to create my own Ok, so here we are setting the checkbox as our parameter for the command. Now all we have to do is to declare our command binding. We have to declare a CommandLambdas and set the CanExecuteExpression property. Something like this….

So what we are doing is to check if the checkbox (that is our command parameter) is checked and if it is, we set the CanExecute. The assignment of the CanExecute is being done for us implicitly by the CommandLambdas class.

Updated: I found this brilliant Library called Blendables… in Blendables there is a very impressive feature called SimpleBinding and Complex Binding (among others) that enable you to write code in the binding in a very clean way… much more nice + powerful than what I did here….

So you can do something like this in the binding

Width=“{blendables:EvalBinding [{Self}.Height]/2}“

That’s nice isn’t it…. Have a look at their Documentation here. Or even check out their samples over here.

Well that is all… I am looking forward for feedback to see how we can extend even more this to be even more useful for WPF Developers

Looking forward for your feedback.

See also Filterering CollectionViewSource Dynamically

Download Source Code for the AvalonLambdas

So here I am at 1.00 am in the morning everyone is sleeping and finally I can enjoy some peace and quite. My brain is partially not working so I apologize if I say something stupid

Let us start…. Why is LINQ so exciting for me? That’s a good question … Well 99% of the people that know me would probably answer “It is a new .Net feature so definitely Marlon will be more than excited about it!”. Yet my friends, let me give you the answer myself! The BIG thing about LINQ is that in C# you can stop being so imperative and bossy and start being more declarative (aka goal oriented). So basically you express yourself by creating a query and then let the underlying provider to do all the work…. To understand more what I mean have a look at Linq to SQL.

So assuming that you have already seen and tried LINQ, today I will talk about how the underlying systems can read the query that you write and parse it. We will not talk about LINQ but instead we will talk about Lambdas and Expression Trees.

Func<string, bool> test = x => x.Length > 10;
Expression<Func<string, bool>> test2 = x => x.Length > 10;

Ok, so you would be wondering what is the difference between these 2 statements. Well there is quite a lot of difference.
When the compiler grabs the first statement, it will treat this line of code like a normal delegete, producing MSIL that can “run” the specified code. Yet for the second statement the compiler will build an Expression Tree so that who ever receives the “test2″ can parse the expression tree and do some work. To have a better idea of what I am saying I opened my friend Reflector and disassembled the two statements.

1st Statement

CS$<>9__CachedAnonymousMethodDelegate1 = delegate (string x) {
return x.Length > 10;
};
Func<string, bool> test = CS$<>9__CachedAnonymousMethodDelegate1;

2nd Statement

Expression<Func<string, bool>> test2 = Expression.Lambda<Func<string, bool>>(Expression.GreaterThan(Expression.Property(CS$0$0000 = Expression.Parameter(typeof(string), “x”), (MethodInfo) methodof(string.get_Length)), Expression.Constant(10, typeof(int))), new ParameterExpression[] { CS$0$0000 });

Quite a big difference one can notice !

Basically the compiler has building up a set of objects that we can parse in order to do a unit of work. And that is the power of Lambda and Expression Trees

Now that we know that the compiler will give us an Expression tree let’s dive into some code. I will will create a method that accepts an expression and translates that expression into a URL. So for example we will have a user that wants a customer that has a name of ‘Marlon’ and we will give him ‘www.blablabla.com/Customer.aspx?Name=Marlon’

First let’s create the Customer class.

Now that we have the class let’s create a dummy method that will eventually be our URL provider.

So the method above accepts an Expression of type Func that has a Customer generic type and a bool as return type. The method will later parse the expression to form a URL out of it.

Now lets’ call this method to see how the code for the lambda would look like.

Great we have everything set up and now we can start having some fun parsing the Expression Tree (FINALLY). The expression that was passed to us contains a Body property. The body is a BinaryExpression that contains a Left property a right property and a NodeType property.
The Left property will contain the expression on the left of our lambda i.e x.Name
The Right property will contain the expression on the right of our lambda i.e “marlon”
The NodeType will contain the operation that was applied between the 2 expression (this is an ExpressionType enum ex. Equals, GreaterThan etc..)

The tree would look something like this

So what we need to do now is to cast the Left expression as a MemberExpression since we know that we have an expression that is accessing a Property of the object (Please note that we are doing this assumption to simplify the blog post in a Part 2 of this post I will discuss how one should recursivly cast this expression since you can have multiples). By doing so now we can access the name of the property that the lambda is calling i.e Name and we can put it in our URL. We can also cast the Right expression to a ConstantExpression that will give us the value that is on the right side of the expression i.e “Marlon”. Having said all this have a look at the code to get a better idea of what is happening

As you can see all we are doing in this method is to get the data from the expression tree and write a string accordingly. AGAIN I want to make this crystal clear, this implementation is quite Naive. There are infinite number of problems with this…. For example if the user passes an expression like this

x => x.Name == “Marlon” && x.Name == “Raffaele”

Then we would get a nice Exception because the Left Expression would not be a Member expression anymore but it would be a BinaryExpression that contains the x.Name == “Marlon” and the Right expression would be the x.Name = “Raffaele”. Something like this.

This can go on infinitly (or maybe until the developer gets tired writing the lambda ) and that is why recursion is needed for parsing an expression tree. I will dive into this on my next post on Expression Trees, right now I will dive into my bed because I cannot make my eyes stay opened any longer….

So guys I hope you liked the article I will be posting Part 2 where we will implement a much more complex expression parser using some recursion and god knows what not.

Download Sample Application >>

I found another cool feature in LINQ (yes another one). Basically LINQ introduces a new keyword, let.

This keyword lets you declare “variables” in your query that you can use throughout the query itself and even to project data out of the query… It would look something like this…

and as expected the result would be

Quite cool….

Regards

In my previous post I talked about LINQ and Deferred Execution … I decided to continue expanding on this topic by showing how with LINQ to Objects it’s not only the query that is not executed immediately. Lets start from the basics… When you have a query such as this one

you can also write the above query in this way…

Yet you still did not execute that query… i.e the query2 that we have in the above code still has no values in it, it only holds an object that can give the values that you would want to have (It’s just a plan of execution). This might sound strange yet true… WHY? It’s because of Iterators. This is very important!!! For a better understanding of how iterators work have a look at this post.
So basically the iterator (which is an object returned by the Where method) will give you one value from a list at a time ONLY when you request it. Once you request the value, then you can go ahead and process that value and request the next value from that list. We use this a lot for example when we create a foreach statement.

When you have a LINQ query the same thing would happen as if we are in a foreach statement. When you project a value from your query you did not process the whole list you only got one value at a time!!! For a better understanding of how this works I created a small demo app where I developed my own Where Iterator that prints in a console. Here is the code for this demo app.

Basically I am creating an extension method for IEnumerable<int> and called it MyOwnWhere that in essence does the same job of the Where extension method of .Net 3.5 with the difference that this one prints to console. The interesting part of all this, is the output in the console…

As you can see when you have a where query you will be going through the list only once. The MyOwnWhere method (by using the yield keyword which is the keyword for creating iterators) is emitting an integer at a time. Lets us try to write down the flow of execution…

- The foreach statement requests a value from the query
- The query will start by asking the MyOwnWhere for a value
- MyOwnWhere will start filtering the source list
- Once an item matching the lambda function passed is found we yield that value
- The body of the foreach can process that value
- Once the value is processed the foreach will request the next value and this will go back to step 1 until the MyOwnWhere will stop yield values.

So basically everything is happening “Just in time” when you request it. To summarize all this we can even say

- You request a value
- The Iterator yields that value
- You process the value and request another one

The only instances where this does not apply is when you have things like OrderBy, Group or Joins…. When you use such methods you will need to get all values before executing the order by for example. So the Where would have to be processed fully before the order by can continue…. So if we change our code to this

than the result would be this

So here we had to process the whole list before we can order the result… No more just in time over here

I hope that this post helps a bit more you guys to understand how LINQ to Objects actually works below the covers

Happy new year to everyone

Regards

Hello WPF Disciples,

LINQ is really really cool, I am in love … Today I discovered something about LINQ that made me think i was crazy for a while … Yet then I found out what is really happening and I felt really stupid …

When you create a query with LINQ the query is not executed until it’s really needed. For example

int[] list = new int[]{ 1,2,3,4,5,6,7,8,9,10 };
int max = 5;
var query = from x in list
where x <= max
select x;

foreach (var item in query)
Console.WriteLine(item);Console.ReadKey(true);

The Result of this query is a print from 1 – 5.

The query is not executed until you reach the foreach statement. Basically LINQ will delay the execution of the query till it is really needed… This makes a lot of sense and I like the idea… BUT if you are not aware of this it can make you go crazy. For example let’s take this query and put some code that changes the state an object that is used in the query

int[] list = new int[]{ 1,2,3,4,5,6,7,8,9,10 };
int max = 5;
var query = from x in list
where x <= max
select x;
max += 2;
foreach (var item in query)
Console.WriteLine(item);
Console.ReadKey(true);

The Result of this query is a print from 1 – 7

As you can see the result for this query is different because the max variable was changed before the query was executed… This can really make you go crazy if you are not aware of what is actually happening…Have a good LINQ time…. Regards

Hello Disciples,

I have written a new post on C# 3.0 new features on CodeProject. The article lists all new features of C# 3.0 and gives a brief description on each one of them. Please have a look at it and send me your feedback.
http://www.codeproject.com/KB/cs/csharp3.aspx

Regards