I needed some quiet time to finish this article so I took some vacations here (Mauritius Island)
Expressions are used to evaluate something. We usually use them in the right side of an affectation or at any place where a value is expected. It can be composed with many other values, with computations or function calls.
When using objects we often retrieve values accessing properties or sub properties, defining property paths. This is what I will work on in this post.
Linq brought the Select method that we all know (one of my favorites).
We often use it to project from an entity to a new expression and many times we just use a property path.
customers.Select(c => c.Company.Address.Country);
Those of you who are familiar to Xaml are very used to property paths in binding expressions:
<TextBlock Text=”{Binding Path=Company.Address.Country}” />
Even if there are some differences, we could easily compare those two features.
One of the difference is WPF and Silverlight binding expressions can be “TwoWay”. This means that the property path expression can be used to both read or write the property value.
In C#, the selector is just pure code, so of course it compiles the natural access to the property (read only). Let’s think about how to make it possible to have a write access…
It’s not very difficult. If the expression only allows a sequence of chained properties, we just need to get the last one (Country in my example). Evaluating the rest of the expression (Company.Address) gives us the instance where we can get or set the last property value from.
To achieve this we need to be able to analyze the code which is not possible if it’s directly compiled into IL. The lambda syntax allows to use the same code to generate an expression instead of IL. Then we get an expression tree representing our property path, so we can analyze and understand it.
Let’s first try to do this in C# 3. Let’s imagine the final code we would like to have.
namespace CSharpRWSelector
{ class Program
{ static void Main(string[] args)
{ var ps = PropertySelector<Customer>.Create(c => c.Address.Country);
var cust = new Customer();
cust.Address.Country = "FRANCE";
Console.WriteLine(ps.GetValue(cust));
ps.SetValue(cust, "FRANCE !");
Console.WriteLine(cust.Address.Country);
}
}
public class Customer
{ public Customer()
{ Address = new Address();
}
public string ID { get; set; } public Address Address { get; set; } }
public class Address
{ public string Country { get; set; } }
}
Let’s imagine a PropertySelector class with a Create() method having the same prototype as the Linq Select().
public static PropertySelector<T, R> Create<R>(Expression<Func<T, R>> source)
{
}
You can notice that the Func<T, R> is surrounded with the Expression<T> class.
The use is exactly the same but we will get an Lambda expression instead of just a delegate reference.
First of all, getting a selector for reading is easy. We just need to compile the expression (source.Compile()) and we retrieve the right selector (Func<T,R>).
All the following is to get a way to write to the property.
Now let’s try to analyze this expression to retrieve the instance just before the last property of our property path.
We will have to implement a custom expression visitor. (see MSDN reference here)
I will quickly comment this part, but all the code is provided at the end of this post.
The expression visitor is massively recursive and is walking along all the expression tree.
We are only looking for properties (ie MemberAccess) and our goal is to catch the last one’s parent ! What I am mainly doing here is finding it and then wait for the next call to get the parent. You can notice that the properties of the path are discovered from right to left (last to first).
protected override Expression VisitMemberAccess(MemberExpression m)
{ if ((m.Member.MemberType == System.Reflection.MemberTypes.Property) &&
(!passed))
{ var lambda = Expression.Lambda(m.Expression, source.Parameters.ToArray());
instanceSelector = lambda.Compile();
propertyName = m.Member.Name;
passed = true;
}
return base.VisitMemberAccess(m);
}
Once we get the parent (Address) we keep this reduced lamba expression (without the last property), we compile it and then we get a selector on the parent.
We can now implement the SetValue() method, using the selector to retrieve the parent instance given the source. Then, using reflection, we can retrieve the PropertyInfo and call the SetValue().
public void SetValue(T source, R value)
{ var parent = instanceSelector.DynamicInvoke(source);
var prop = parent.GetType().GetProperty(propertyName);
prop.SetValue(parent, value, null);
}
As I said previously, the GetValue() is easy to implement. We just need to call the initial selector.
public R GetValue(T source)
{ return selector(source);
}
I will also add some security code to be sure that only property paths are allowed.
code like c => c.SomeMethod().Property; must be rejected.
The expression visitor Visit() method is called for each node whatever its type. So it’s the perfect place to only accept property paths.
protected override Expression Visit(Expression exp)
{ if ((exp.NodeType != ExpressionType.Parameter) &&
(exp.NodeType != ExpressionType.Lambda) &&
((exp.NodeType != ExpressionType.MemberAccess)
&& ((exp as MemberExpression).Member.MemberType
== System.Reflection.MemberTypes.Property)))
throw new ArgumentException("Only Properties are allowed with PropertyPath"); return base.Visit(exp);
}
Unfortunately, we have no way to check this at compile time.
Last but not least, let’s add an interesting improvement using C# 4.
In this first sample, you can notice that the GetValue is efficient because it’s a real ‘compiled’ selector but the SetValue is using reflection.
As explained in this very interesting post, C# 4 has new lambda expression features. Actually, not in the C# language itself but in the lambda expression APIs.
Affectation of a value was impossible to be described in a C# 3 lambda expression and it’s still not in C# 4, but we can build this expression tree bye code as the Expression.Assign() method now exists.
So now the goal is still to provide a Write access to my selector.
The visitor is now more complex as we want to make a real transformation of the tree.
From a selector Func<T, R> we want to infer an Action<T, R>.
The following code is very symbolic as it does not compiles but it gives a good idea of what we will try to generate:
From the analysis of
Func<Customer, string> f = c => c.Address.Country;
We will generate
Action<Customer, string> a = (cust, country) => cust.Address.Country = country;
Let’s modify the visitor:
protected override Expression VisitMemberAccess(MemberExpression m)
{ var result = base.VisitMemberAccess(m);
currentNode = Expression.MakeMemberAccess(currentNode, m.Member);
return result;
}
In this first step, I am building a parallel expression tree copying the property path definition, excepted the lambda root.
We now need to build our Action<T, R>.
public PropertySelector<T, R> Compile(Expression<Func<T, R>> source)
{ this.source = source;
parameters = new List<ParameterExpression>();
Visit(source);
var valueParameter = Expression.Parameter(typeof(R), "value");
parameters.Add(valueParameter);
currentNode = Expression.Assign(currentNode, valueParameter);
var setter = Expression.Lambda(typeof(Action<T, R>), currentNode, parameters);
var result = new PropertySelector<T, R>() { selector = source.Compile(), setter = (Action<T, R>)setter.Compile() };
return result;
}
After running the visitor (Visit() method), I am retrieving the property path from currentNode and I am building the affectation with Expression.Assign().
Compared to the Func<T,R>, I also need to add a new R parameter which is the value to affect. (see parameters.Add(valueParameter); ).
Finally, a lambda expression groups all this stuff to create the Action<T,R>.
We can compile it and get the corresponding delegate (setter) which is real code instead of the reflection we’ve used in the C# 3 version.
We now just need to call it from the SetValue() method.
public void SetValue(T source, R value)
{ setter(source, value);
//var parent = instanceSelector.DynamicInvoke(source);
//var prop = parent.GetType().GetProperty(propertyName);
//prop.SetValue(parent, value, null);
}
The main application remains the same and we of course have the same result but we know use a dynamic solution by compiling code thanks to new C#4 expression tree features !
You can find the two relative solutions here for C# 3/VS2008 and C# 4/VS2010.
Mitsu

Just a quick post to share this project with you.
Microsoft France organized a 2 month long internship in Paris to develop a Surface Toolkit.
We have provided a bunch of controls, including a Card Game Surface Starter kit that you can see here:
The project on Codeplex: http://surfaceacademy2009.codeplex.com/
For the last Paris mobility briefing, my colleague Pierre Cauchois asked me to co-animate the Coding4Fun session…hard to refuse.
Even if mobile dev is not my every day work, thanks to the .Net Compact Framework, it’s still .Net programming.
Here is the scenario:
You come back home, you have a windows mobile phone wifi capable and you want to quickly get access to your phone pictures from your home network.
You just activate the Wifi, run my app and then browse to the provided link from any computer on the network.
Then a silverlight application is loaded from the phone and you can see any of your pictures.
Here is how it works:
I decided to use windows mobile to host a Silverlight application.
I had just needed a Mobile Web Server that I found here (thanks to Pavel Bánský). The code is full C# and really small and easy to use. I just had to add cookie support but I will talk about it later.
Now I have a basic web server hosted on my phone, I will publish some stuff.
- the main html page containing the silverlight application. I renamed the one provided by Visual Studio to “Default.html” to make it the default page of my web site.
- the xap file which is the Silverlight application itself.
- a web service to expose the list of pictures available on my phone. As I had no web service infrastructure available on my very small web server, I have decided to expose a rss feed which is made with just a few lines of Linq to Xml. Exposing pictures on http gives a lot of advantages like getting the benefits of the browser local cache. In this project it’s very useful because the mobile phone does not have a large and powerful bandwidth, so we appreciate not to reload pictures ever time. Now we just need to link some Silverlight Image controls to the pictures urls and the Silverlight image loader will work for us.
- make the pictures visible. The web server contains a virtual folder feature. I just had to make it point to the local pictures path.
Linq to Xml rss content creation on server side (Compact Framework):
var files = Directory.GetFiles(picturesPath, "*.jpg");
XElement response = new XElement("rss",
new XAttribute("version", "2.0"),
new XElement("channel",
new XElement("title", "Mobile pictures"),
new XElement("description", "Mobile pictures from my phone"),
new XElement("link", ""),
(from file in files.Select(f => Path.GetFileName(f))
select
new XElement("item",
new XElement("title", file),
new XElement("description", file),
new XElement("link", string.Format("http://{0}/photos/{1}",ipAddress,file))
)
).ToArray()
)
);
Regarding the client development, I have created a simple Silverlight 3 application (yes I also wanted to play with those new features like 3D and non linear animations).
The Silverlight application calls the web service, reads the rss content (using Linq to Xml again !) and binds the pictures paths to a listbox. The selected picture is displayed in the biggest part of the window. When you change the selected picture, an animation wipes out the existing one and another is bringing the new one with a 3D effect.
Analysing rss content with Linq to Xml on client side (Silverlight):
var root = XElement.Parse(e.Result);
var items = root.Element("channel").Elements("item").Select(i => i.Element("link").Value);
lb.ItemsSource = items;
And that’s it !
Now let’s talk about security. Once again, it’s just a little demo but we can not talk about opening a web server on your phone without talking about security.
The web server is made to respond to the user for a short time. https is complex and even basic authentication needs credentials on the server side. I have chosen another solution that I found to be more appropriate. In my scenario, the web server is requested by a single user who’s got the phone in his hands. So when a first request comes (no cookie), I am asking for a human validation (MessageBox). Of course during this time the server is stopped. The user just has to validate on the phone and then the server answers and provides an authentication cookie. Next requests will carry the cookie and the user will not have to validate again.
This remains a really really small demo. We could of course imagine having a more robust web server and some optimizations like thumbnails creation on server side but this was just a test and I hope it gave some interesting ideas to some of you.
In addition to hosting a Silverlight application on my mobile phone, the funniest was to be able to use .Net both on server and client side (Compact Framework and Silverlight) without using the Windows .Net Framework !
The source code is attached to this post.
Before going into Linq, here is again one of my pictures: Le Louvre by night, Paris
When using Linq to objects, you will quickly feel the need to pass some parameters from a method to another but it’s not so easy because each Linq method is not calling the following one. In a Linq sequence, each method is using the result computed by the previous one. So, local contexts are not visible from one method to another.
The compiler is using two technical different ways to let parameters go out of a method.
As an example, let’s first see how the .SelectMany() method is working.
var values1 = new string[] { "1", "2" };
var values2 = new string[] { "A", "B", "C" };
var q =
from s1 in values1
from s2 in values2
select s1 + s2;
This very little example shows that s1 and s2 are both accessible in the select. It’s nice, but how does this work ?
You must know that the ‘from’ statement of the Linq sugar syntax does not match any existing Linq method. Let’s see how we would have written this using the classical C# syntax.
var values1 = new string[] { "1", "2" };
var values2 = new string[] { "A", "B", "C" };
var q =
values1.SelectMany(s1 => values2.Select(s2 => s1 + s2));
Let’s focus on the SelectMany parameter:
SelectMany(Func<TSource, IEnumerable<TResult>> selector).
The method must return an IEnumerable<TResult>. In our example, we get it using values2.Select(). We are now touching the interesting point. The parameter of the .Select() is also a lambda “s2 => s1 + s2”. In Linq to object a lamda generates an anonymous method and anonymous methods can access their host scope. Here, s1 is visible inside values2.Select().
So the first solution to share parameters between methods is to nest them
like “.SelectMany(s => s.Select(s2 =>’s in accesible here’ ))”
instead of creating a sequence “source.Skip(‘scope1’).Take(‘scope2’)”
Now what if we would like to share a parameter between two following methods like Skip() and Take() ?
Let’s see how the “let” keyword works.
In the next example, I will start from a list of numbers stored as strings.
I would like to get only numbers greater than 10 and order them by their value but keeping the result as an enumeration of string.
We can write it quickly this way:
var values = new string[] { "12", "4", "7", "18", "32" };
var q =
from s in values
where Convert.ToInt32(s) > 10
orderby Convert.ToInt32(s)
select s;
This works fine but we all notice the ugly “Convert.ToInt32(s)” used twice on the same value. Thanks to the “let” keyword we can create a new parameter that will be accessible in all the query.
var values = new string[] { "12", "4", "7", "18", "32" };
var q =
from s in values
let i = Convert.ToInt32(s)
where i > 10
orderby i
select s;
We can see that the “let” keyword solves this problem extremely easily. But once again the sugar syntax of Linq is really magic. As we always want to know the secrets of magic tricks, let’s try to get the same result without using the “let” keyword and we will find out what the C# compiler is really doing.
Let’s start by decomposing all the steps using the regular C# syntax.
var step1 = values.Where(s => Convert.ToInt32(s) > 10);
var step2 = step1.OrderBy(s => Convert.ToInt32(s));
I have chosen to decompose this way to show that the only place to share something between the Where() and the OrderBy() is the result.
Now we have to make a new parameter travel across the sequence in addition to the current result. The idea is to create a new type to group the current result and the new value. To achieve this easily we can just use a anonymous type.
//step0: Create an anonymous type grouping the original string and the new value in a single element
//step1, step2: 'i' is now accessible as a property of each element
//step3: Get back to an enumeration of string by removing the temporary anonymous element
var step0 = values.Select(s => new { s = s, i = Convert.ToInt32(s) });
var step1 = step0.Where(tmp => tmp.i > 10);
var step2 = step1.OrderBy(tmp => tmp.i);
var step3 = step2.Select(tmp => tmp.s);
We can of course write this in a single Linq query
var q =
from tmp in
(from s in values
select new { S = s, I = Convert.ToInt32(s) })
where tmp.I > 10
orderby tmp.I
select tmp.S;
which is the exact equivalent of what is compiled when using the ‘let’ keyword
var q =
from s in values
let i = Convert.ToInt32(s)
where i > 10
orderby i
select s;
Of course the Linq syntax is extremely short but it’s always nice to know what’s happening behind the scene.
I hope this sample can also help you to solve some other problems when playing with Linq.
Contrarily to the title, this is a serious article !
From 10th to 12th of February Microsoft France have organized the Paris Techdays event.
During the developer keynote, I have presented some Surface development features with a funny demo.
Here is a video of this demo but in french.
Now let me explain what happened.
Here is the idea:
Get a Surface table, setup a windows extended desktop using the VGA output of the table and an external display. The Surface application is very simple and similar to the very classical application where many people can move, rotate and resize pictures. In our case, pictures were slides exported from Powerpoint. When the applications runs, it creates a classical WPF window (not Surface specific) and put it on the secondary display, in a maximized state.
The goal is to output a defined part of what we have on the table on the external display. I have choose to use Tag to define this part (a rectangle) on the table. Placing the tag will define the center of this output rectangle. Then you can change the position of the output rectangle by moving the tag. As the Surface also recognizes the orientation, I have used the delta orientation value to increase or decrease the output rectangle size depending on the direction you are turning the tag (clockwise/counter clockwise).
As many people (including me :-) ) can't test this application at home, I have simulated feature in a WPF application using mouse move and mouse wheel events.
How to implement it:
It's quite fast to implement but let's see the interesting points.
First, how to capture the targeted visual part ? We will use a WPF VisualBrush.
This component is a Brush, comparable to a image brush, a plain color or a gradient brush but will use another WPF Visual as for painting. What you can notice is that the VisualBrush is not based on a kind of bitmap capture but is redrawing the visual using the wpf vector information. This means that if the VisualBrush is growing the original size, you will still keep a sharp rendered image keeping the benefits of the vector based drawing.
So the output window is simply defined this way:
<Window x:Class="SurfaceMedia.OutputWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="OutputWindow" Height="300" Width="300">
<Window.Background>
<VisualBrush x:Name="vb" />
</Window.Background>
</Window>
Now we need to define which part of the main window we want to output.
We will surround our main content with a grid and then put a Canvas over it. Then we can define a Rectangle in our canvas to visually define our output region.
No the problem is we have our Rectangle over the main content but we want our main content to still receive inputs (mouse, keyboard) and we want the Rectangle to respond to some mouse events.
To achieve this, we will define the Canvas IsHitTestVisible attribute to "False". Easy to do but now the Rectangle will no longer receive mouse events.
In our surrounding grid, we will catch the needed mouse events. As the main content can potentially stop the bubble events from going up to their parents, we will prefer using PreviewMouseMove and PreviewMouseWheel.
<Grid PreviewMouseMove="Canvas_MouseMove" PreviewMouseWheel="Grid_MouseWheel">
<Grid>
...main content
</Grid>
<Canvas x:Name="canvas" IsHitTestVisible="False">
<Rectangle x:Name="outputRect" Width="100" Height="100" Stroke="Black"
StrokeThickness="1" Opacity="0.5" Canvas.Left="6" Canvas.Top="72" />
</Canvas>
</Grid>
Now we get what we wanted. We just need to adjust the VisualBrush playing on its Viewbox property to define exactly which part of the source we want to display.
private void Canvas_MouseMove(object sender, MouseEventArgs e)
{ RefreshOutputWindow(e);
}
private void Grid_MouseWheel(object sender, MouseWheelEventArgs e)
{ if ((outputRect.Width < 40) && (e.Delta < 0))
return;
outputRect.Width += e.Delta / 10;
outputRect.Height += e.Delta / 10;
RefreshOutputWindow(e);
}
private void RefreshOutputWindow(MouseEventArgs e)
{ var pos = e.GetPosition(canvas);
pos.Offset(-outputRect.Width / 2, -outputRect.Height / 2);
Canvas.SetTop(outputRect, pos.Y);
Canvas.SetLeft(outputRect, pos.X);
outputWindow.vb.Viewbox = new Rect(pos, new Size(outputRect.Width, outputRect.Height));
outputWindow.vb.ViewboxUnits = BrushMappingMode.Absolute;
}
How to programmatically place a WPF window on a secondary display ?
This one is not really related to WPF but is a little bit tricky.
We will need to make some interop with Window Forms because Screens information is not accessible from WPF APIs.
For this demo, if an extended desktop is available, we will place our output window on it in full screen. If not, we will just put it as a regular window on the main screen.
private void ShowOutputWindow()
{ outputWindow = new OutputWindow();
if (System.Windows.Forms.Screen.AllScreens.Length > 1)
{ outputWindow.WindowStartupLocation = WindowStartupLocation.Manual;
System.Drawing.Rectangle workingArea
= System.Windows.Forms.Screen.AllScreens[1].WorkingArea;
outputWindow.Left = workingArea.Left;
outputWindow.Top = workingArea.Top;
outputWindow.Width = workingArea.Width;
outputWindow.Height = workingArea.Height;
outputWindow.WindowStyle = WindowStyle.None;
outputWindow.Topmost = true;
}
outputWindow.Show();
outputWindow.vb.Visual = mainGrid;
}
Why using the popfly duck ?!
I was just looking for something to stick the tag on and when looking around me I have found this funny duck that we had received when organizing the Paris ReMix a few years ago. It's hard to stick the tag under the duck but once it's done the duck shape is quite handy !
The source code is attached to this post.
We have just finished the french Paris Techdays today. I had organized a Coding4Fun session and here is on of the demo which is...let's say special :p.
You can find the code attached to this post.
Before we go deep into Linq to Sql, I wanted to share with you one of my pictures made last week at Chamonix Mont Blanc from "L'aiguille du midi" during some days off.
Ok now let's go. Here is just a little trick but with some interesting patterns that could be useful in some other contexts not connected to Linq to Sql.
When using Linq expressions, like with Linq to Sql, translating the expression into something else (sql for example) is taking time and resources. Sometimes it's negligible, sometimes not...
Regarding Linq to Sql, let's say that if your query is called more that once, it's always a good thing to use CompiledQueries.
The idea is simple: translating the query at first call then keeping the generated sql for next calls. This logic is deferred in a delegate provided by the Compile() method.
In the following example, the second query execution (with "London") is extremely efficient because the sql query is cached after the first call occurred.
void Load()
{
var db = new NorthwindDataContext();
db.Log = Console.Out;
var q =
CompiledQuery.Compile((NorthwindDataContext context, string city) =>
from c in context.Customers
where c.CustomerID == city
select c);
var result = q(db, "Paris").ToList();
var result2 = q(db, "London").ToList();
}
But I often hear developers saying the syntax is too complex. The Compile() method is waiting for an "Expression<Func<TArg0, TArgX..., TResult>> where TArg0 : DataContext". What your must understand here is that you must provide a function taking a Linq to Sql argument as first parameter and the your are free to provide up to 4 more arguments if your query needs it.
In my first example we understand easily the use of the CompiledQuery but we may want more ! "q" is a local variable so at each call of the Load() method the compiled query is recreated. We could keep the compiled query in a larger scope or even statically if it's worth doing it. But another problem appears. If we want to store the compiled query in a class field, static or not, we have to fully define its type without using type inference (var). The compiled query return value type is not easy to know. Let's see why.
The returning type if Func<TArg0, TArgX..., TResult> which does not seem to be so complex but TResult is inferred from the Linq to Sql query itself.
For example, in our very simple code the real type of "q" is :
Func<NorthwindDataContext, IQueryable<Customer>>
But depending on your query, it could easily become:
Func<NorthwindDataContext, IOrderedQueryable<IGrouping<Customer>>>
It's not easy to write and worst, you may have to update your declaration if you rewrite your query...
So what I propose here is a solution to keep a global fully typed reference on a compiled query with still taking advantages of the type inference.
The first idea is to store a dictionary of compiled queries statically somewhere. Here, I will use keys of type string but you could easily change it to any other type. Compiled queries are delegates, so for the moment let's just define our dictionary as Dictionary<string, Delegate>.
public static class MyQueries
{
private static Dictionary<string, Delegate> compiledQueries =
new Dictionary<string, Delegate>();
}
Adding a compiled query to this dictionary is easy but we will loose static type information. Of course the compiled queries instances will still be typed but we want to have this information at compile time to have intellisense.
So my idea here is to resolve everything in a single method call :
public static class MyQueries
{
private static Dictionary<string, Delegate> compiledQueries =
new Dictionary<string, Delegate>();
public static Func<TArg0, TResult> Get<TArg0, TResult>(string key,
Expression<Func<TArg0, TResult>> query) where TArg0 : DataContext)
{
Delegate d = null;
if (compiledQueries.TryGetValue(key, out d))
return (Func<TArg0, TResult>)d;
else
{
var result = CompiledQuery.Compile(query);
compiledQueries.Add(key, result);
return result;
}
}
}
Let's use it:
public void Load()
{
var db = new NorthwindDataContext();
db.Log = Console.Out;
var q =
MyQueries.Get("cust", (NorthwindDataContext context, string city) =>
from c in context.Customers
where c.CustomerID == city
select c);
var result = q(db, "Paris").ToList();
var result2 = q(db, "London").ToList();
}
What's happening here ? I have prototyped the MyQueries.Get() method with two parameters. The key identifying the query and then the query itself.
At first call (key not found), we just add the query to the our dictionary.
On next calls (key found), we just cast the query back to its original reference type.
The interesting stuff is here. As we resolve everything in this single method, we always have the generic context resolved. If you look more what's happening when the key is found, you will realize that the query passed as parameter is not used by the our code but is essential because it's used by the compiler type inference to resolve the generic parameters !
So "q" is fully typed and we can use 'q(db, "Paris")' the same way we did previously.
Now let's see some options :
The CompiledQuery.Compile() method has a lot of overloaded versions. This allows you to pass from 1 to 4 parameters.
Compile<TArg0, TResult>();
Compile<TArg0, TArg1, TResult>();
Compile<TArg0, TArg1, TArg2, TResult>();
Compile<TArg0, TArg1, TArg2, TArg3, TResult>();
So I have reflected this possibility into my MyQueries.Get<>() method to offer the same advantages.Then when I came to implementation, I had quite a very hard problem to solve.
What I could have done is to make an ugly copy & paste 4 times of my method, just adding TArg1 then TArg2, etc.
Of course I wanted to factorize this code in a single method that I would have call from all the overloaded versions of MyQueries.Get<>(). Just try to solve this and you will see it's quite complicated...
Let's see exactly in the code where the generic parameters are used. In fact they are used twice. First to cast the delegate when it is found, this one is explicit, then by the CompileQuery.Compile() to resolve its generic parameters using type inference, this one is implicit.
...
if (compiledQueries.TryGetValue(key, out d))
return (Func<TArg0, TResult>)d;
else
{
var result = CompiledQuery.Compile(query);
compiledQueries.Add(key, result);
return result;
}
...
The first one could be factorized by creating a new level of genericness, replacing Func<TArg0, TResult> by a TDelegate. But we have a some issues. We have a constraint on TArg0 (where TArg0 : DataContext) that we won't be able to define any more.
Worst, the type inference that solves the generic parameters of the CompiledQuery.Compile() method won't work any more.
A first possible solution is to use reflection intensively to do dynamically what type inference is doing at compile time: find the right version of the CompiledQuery.Compile() method.
But I wanted to find a solution without calling reflection API. So here is what a propose.
Here is an internal version of the Get() method that will factorize our main features. As you can see, I have removed all kind of genericness from the InternalGet() signature.
private static Delegate InternalGet(string key,
Func<Delegate> queryProvider)
{
Delegate d = null;
if (compiledQueries.TryGetValue(key, out d))
return d;
else
{
var result = queryProvider();
compiledQueries.Add(key, result);
return result;
}
}
I have also remove what was painful: the creation the CompiledQuery, that I have deferred in a Func<Delegate> called queryProvider. Doing this, I will keep the code that is creating the CompiledQuery at the caller level where the compiler has all the generic context available. The final cast, back to Func<TArgxxx, ..., TResult> will also be applied by each calling method.
Now we can write:
public static Func<TArg0, TResult> Get<TArg0, TResult>(
string key, Expression<Func<TArg0, TResult>> query)
where TArg0 : DataContext
{
return (Func<TArg0, TResult>) InternalGet(
key,
() => CompiledQuery.Compile(query));
}
and just repeat the same for Get<TArg0, TArg1, TResult>() and so on...
Just to finish, let's make the code more secure:
- make sure the key is not null.
- make the access to the static dictionary thread safe.
I am only adding this now because I did not want to make previous code too heavy.
The whole solution is very short so I did not attached any test solution. Here is the whole code that you can just copy & paste:
public static class MyQueries
{
private static Dictionary<string, Delegate> compiledQueries =
new Dictionary<string, Delegate>();
public static Func<TArg0, TResult> Get<TArg0, TResult>(string key, Expression<Func<TArg0, TResult>> query) where TArg0 : DataContext
{
return (Func<TArg0, TResult>) InternalGet(key, () => CompiledQuery.Compile(query));
}
public static Func<TArg0, TArg1, TResult> Get<TArg0, TArg1, TResult>(string key, Expression<Func<TArg0, TArg1, TResult>> query) where TArg0 : DataContext
{
return (Func<TArg0, TArg1, TResult>)InternalGet(key, () => CompiledQuery.Compile(query));
}
public static Func<TArg0, TArg1, TArg2, TResult> Get<TArg0, TArg1, TArg2, TResult>(string key, Expression<Func<TArg0, TArg1, TArg2, TResult>> query) where TArg0 : DataContext
{
return (Func<TArg0, TArg1, TArg2, TResult>)InternalGet(key, () => CompiledQuery.Compile(query));
}
public static Func<TArg0, TArg1, TArg2, TArg3, TResult> Get<TArg0, TArg1, TArg2, TArg3, TResult>(string key, Expression<Func<TArg0, TArg1, TArg2, TArg3, TResult>> query) where TArg0 : DataContext
{
return (Func<TArg0, TArg1, TArg2, TArg3, TResult>)InternalGet(key, () => CompiledQuery.Compile(query));
}
private static Delegate InternalGet(string key, Func<Delegate> queryProvider)
{
if (string.IsNullOrEmpty(key))
throw new ArgumentNullException("key");
lock ((compiledQueries.Keys as ICollection).SyncRoot)
{
Delegate d = null;
if (compiledQueries.TryGetValue(key, out d))
return d;
else
{
var result = queryProvider();
compiledQueries.Add(key, result);
return result;
}
}
}
}
This piece of code is part of a personal bigger project that I am working on and I think there are interesting thing in it and I wanted to share it with you.
I am trying to use generics and type inference to imagine new kind of method prototype.
With all the stuff around Linq like lambda expressions, simple method calls have become extremely powerful.
What I have been trying here is to create a generic way to define a selection starting from a tree of objects, the most simpler way as possible.
Let's start with the beginning...
Here is a very simple little interface defining a node of the tree, basically, a value and the references to the child nodes.
public interface INodeSelector
{
object Value { get; }
List<INodeSelector> Children { get; }
}
You can notice that the Value is just typed as 'object'. To store any kind of value we will keep this definition, but to have an easy to use initialization, we will create generic methods and have all the benefits of the type inference and intellisense.
Now I will create an generic type to implement INodeSelector: NodeSelector<T>.
new NodeSelector<Customer>(customer);
As constructors can not infer their generic parameters from the parameters, I prefered to use a static method for creating NodeSelector<T> instances. For different reasons that I will explain later the name of the hosting class is not NodeSelector but TreeSelector.
public static class TreeSelector
{
public static NodeSelector<T> Create<T>(T source)
{
return new NodeSelector<T>(source);
}
}
...
var ts = TreeSelector.Create(customer)
For the moment we just have NodeSelector<T> class that keeps the root value of our tree.
Now from this root, I would like to define paths to some other values. Each of those paths will provide a new child node attached to the root node (and to its parent node for the following levels).
Let's start thinking about just a single child.
We can achieve this easily using a simple selector expression, starting from the value of the current node and returning the child value.
public class NodeSelector<T> : INodeSelector
{
...
public void Add<TResult>(Func<T, TResult> selector)
{
Children.Add(TreeSelector.Create(selector(source)));
}
}
Then we can write:
var ts = TreeSelector.Create(customer);
ts.Children.Add(c => c.CustomerID);
Now I would like to add two features:
adding new nodes at the same level.
- adding new child nodes to an existing node.
Let's remind some generic rules. When calling 'ts.Children.Add(c => c.CustomerID)', we do not need to define the TResult generic parameter of Add<TResult> because it is infered by the expression 'c => c.CustomerID'. Without type inference we would have need to define Add<string>() explicitly.
I could return the new created node in the Add() method instead of returning void and then chain Add() calls:
ts.Children.Add(c => c.Address).Children.Add(ad => ad.City);
But if I want to add nodes at the same level (sibling), I will have to create a temporary reference and break this chain.
On the other hand, I could allow to pass an array of selectors to the Add method to add sibling nodes in just a call.
ts.Children.Add(c => c.CustomerID, c => c.Address);
Using this syntax, I can add as many sibling nodes as I want but returning a value from Add() has no sense so I am losing the previous syntax for chaining children creation.
So I have imagined something else that is not very usual: returning the current node instance from the Add() method (not the added one !).
public class NodeSelector<T> : INodeSelector
{
...
public NodeSelector<T> Add<TResult>(Func<T, TResult> selector)
{
Children.Add(TreeSelector.Create(selector(source)));
return this;
}
}
Now we can write:
var ts = TreeSelector.Create(customer)
.Add(c => c.CustomerID)
.Add(c => c.Address);
So we now use chained Add() calls to add sibling nodes. We still need to add child nodes.
There is something very interesting in type inference: if a generic parameter is resolved by the first parameter of a method, then the following parameters can use it.
In my example, '.Add(c => c.Address, ...)', the TResult parameter is resolved as an Address type thanks to the first parameter 'c => c.Address'. So we can use it in the following parameters.
Inside the Add() method we are wrapping the resulting value of the projection in a new NodeSelector<TResult>. We would need to get it out so the second parameter could use it to add child nodes. To achieve this I will add a new delegate parameter providing the added NodeSelector<T> and waiting for it to be returned. In theory we don't need any return value but lambda expressions must return a value. As now, all Add() calls are returning the NodeSelector<T> itself, I will define my delegate that way:
public NodeSelector<T> Add<TResult>(Func<T, TResult> selector,
Func<NodeSelector<TResult>, NodeSelector<TResult>> childrenSelectors)
{
var n = TreeSelector.Create(selector(source));
childrenSelectors(n);
Children.Add(n);
return this;
}
Now we can write:
var ts = TreeSelector.Create(customer)
.Add(c => c.CustomerID)
.Add(c => c.Address,
ad => ad
.Add(a => a.City)
.Add(a => a.Country)
);
Now it becomes quite interesting. We have a single expression allowing us to add both siblings and child nodes without creating any temporary reference to any node.
Playing with indentation we can even 'see' the resulting tree.
Let's try to display it in a TreeView control.
The code is recursive but quite simple:
private void FillTreeView(TreeNodeCollection nodes, INodeSelector ns)
{
var node = nodes.Add(ns.Value.ToString());
foreach (var child in ns.Children)
FillTreeView(node.Nodes, child);
}
...
FillTreeView(treeView1.Nodes, ts);
Now we have a good basic solution, let's add some more features !
In the current example, we have built a tree using simple selectors, jumping to one value to another one. (one-to-one relationship)
What if the relationship is one-to-many like 'c => c.Orders' ?
Then we could create a method to add all the children into as many sibling nodes.
So we will need a selector to retrieve the collection (c => c.Orders). Then another selector to apply on each item of the collection. It the itemSelector is not provided (null) we will add the item itself (the Order in our example).
public NodeSelector<T> AddRange<TResult>(
Func<T, IEnumerable<TResult>> collectionSelector,
Func<TResult, object> itemSelector)
{
foreach (var item in collectionSelector(source))
if (itemSelector != null)
Children.Add(TreeSelector.Create(itemSelector(item)));
else
Children.Add(TreeSelector.Create(item));
return this;
}
public NodeSelector<T> AddRange<TResult>(
Func<T, IEnumerable<TResult>> collectionSelector)
{
return AddRange(collectionSelector, null);
}
Now we can write :
var ts = TreeSelector.Create(customer)
.Add("CustomerID", c => c.CustomerID)
.Add(c => c.Address,
ad => ad
.Add(a => a.City)
.Add(a => a.Country)
)
.AddRange(c => c.Orders, o => o.OrderDate);
We can see that the AddRange() method has added 3 new nodes. So the AddRange() is just the repeat of what we can do with Add().
Maybe would like to group all these nodes under a common one whose value would be the collection.
Let's create the AddCollection() method.
public NodeSelector<T> AddCollection<TResult>(
Func<T, IEnumerable<TResult>> collectionSelector,
Func<TResult, object> itemSelector)
{
var selector = collectionSelector(source);
var node = TreeSelector.Create(selector);
Children.Add(node);
foreach (var item in selector)
if (itemSelector != null)
node.Children.Add(TreeSelector.Create(itemSelector(item)));
else
node.Children.Add(TreeSelector.Create(item));
return this;
}
public NodeSelector<T> AddCollection<TResult>(
Func<T, IEnumerable<TResult>> collectionSelector)
{
return AddCollection(collectionSelector, null);
}
Now we can write:
var ts = TreeSelector.Create(customer)
.Add(c => c.CustomerID)
.Add(c => c.Address, ad => ad
.Add(a => a.City)
.Add(a => a.Country))
.AddCollection(c => c.Orders, o => o.OrderDate);
Ok, one last feature, but a useful one.
As you can see in all the screen captures, I am just displaying the Values because it's the only thing I have !! :-)
But ! Maybe you would like to add a label or any kind of other object to your nodes.
In the Winforms TreeNode for example, there is a very useful Tag property that allows you to attach what you want to your nodes.
Let's add such a feature to our code.
Let's start with the NodeSelector definition itself:
an extended interface :
public interface INodeSelectorWithTag : INodeSelector
{
object Tag { get; }
}
an extended implementation :
public class NodeSelector<T, TTag> : NodeSelector<T>, INodeSelector<T, TTag>
{
public NodeSelector(TTag tag, T source) : base(source) { Tag = tag; }
public TTag Tag { get; private set; }
object INodeSelectorWithTag.Tag
{
get { return this.Tag; }
}
public NodeSelector<T, TTag> Add<TResult>(
TTag tag, Func<T, TResult> selector)
{
Children.Add(TreeSelector<TTag>.Create(tag, selector(source)));
return this;
}
and all the AddXXX() methods
...
and an extended creator class :
public static class TreeSelector<TTag>
{
public static NodeSelector<T, TTag> Create<T>(TTag tag, T source)
{
return new NodeSelector<T, TTag>(tag, source);
}
public static NodeSelector<T, TTag> Create<T>(T source)
{
return TreeSelector<TTag>.Create(default(TTag), source);
}
}
Now we can write :
var ts = TreeSelector<string>.Create("Customer", customer)
.Add("CustomerID", c => c.CustomerID)
.Add("Address", c => c.Address,
ad => ad
.Add("City", a => a.City)
.Add("Country", a => a.Country)
);
Let's modify our TreeView code.
private void FillTreeView(TreeNodeCollection nodes, INodeSelectorWithTag ns)
{
var node = nodes.Add((ns.Tag ?? "") + " > " + ns.Value.ToString());
foreach (var child in ns.Children)
FillTreeView(node.Nodes, child);
}
This post is already too long so I will stop here.
What's next ?
- I will use this TreeSelector to project an Xml structure.
- I will rewrite it to support deferred loading. Actually it's already done but I am not really happy with my code. I will wait for CLR4 generics covariance to propose a clean solution.
The whole solution is attached to this post.
I recently had to write a small Flickr API. I know many .Net API for Flickr already exist but I needed one for a Silverlight application. Whatever, it's only about building some querystrings so I did it by myself. It's been an opportunity to think again about a classical question: how to pass parameters to a method ?
Imagine you have a generic method to call some Flickr functions.
public void CallFlickrMethod(string methodName, ? parameters,
DownloadStringCompletedEventHandler asyncResult)
The goal here is to finally build a querystring like:
http://api.flickr.com/services/rest/?method=mymethod¶m1=value1¶m2=value2...
In that case, I would like to pass a collection of parameters, each parameter being a key+value structure.
The .Net framework (Silverlight too) offers a KeyValuePair<TKey, TValue> structure that we could use here.
We could imagine a method like:
public void CallFlickrMethod(string methodName, KeyValuePair<string, string>[] parameters,
DownloadStringCompletedEventHandler asyncResult)
Call:
CallFlickrMethod("mymethod",
new KeyValuePair[] {
new KeyValuePair<string, string>("param1", "value1"),
new KeyValuePair<string, string>("param2", "value2")
},
completedHandler);
You may also know the 'params' keyword that allows you to pass parameters separated by commas instead of having to build an array:
public void CallFlickrMethod(string methodName, DownloadStringCompletedEventHandler asyncResult,
params KeyValuePair<string, string>[] parameters)
Call:
CallFlickrMethod("mymethod", completedHandler,
new KeyValuePair<string, string>("param1", "value1"),
new KeyValuePair<string, string>("param2", "value2"));
You can notice that the params parameter must be the last one of the method prototype. This syntax is shorter but still a little bit heavy to write because we have to create many KeyValuePair structures.
In that case, parameters names are unique so we are very close to have a dictionary.
We could imagine:
public void CallFlickrMethod(string methodName, DownloadStringCompletedEventHandler asyncResult,
Dictionary<string, string> parameters)
Call:
var parameters = new Dictionary<string, string>();
parameters.Add("param1", "value1");
parameters.Add("param2", "value2");
CallFlickrMethod("mymethod", completedHandler, parameters);
The method is simpler but the call is still heavy because of the dictionary creation.
Then I thought about using anonymous methods. This is only working because keys are strings. In a class, properties names are unique. Properties definitions are stored in the type definition itself and the properties values are stored in the instance of the class. So we could imagine using an object as a kind of readonly dictionary (keys are fixed).
Imagine we change our method to just:
public void CallFlickrMethod(string methodName, DownloadStringCompletedEventHandler asyncResult,
object parameters)
Then we could use new C#3 anonymous types to write:
CallFlickrMethod("mymethod", completedHandler, new { param1 = "value1", param2 = "value2"});
This syntax is of course very short and also very easy to use.
The following code is analyzing the 'parameters' object using reflection to retrieve the equivalent of a collection of KeyValuePairs.
public void CallFlickrMethod(string methodName, object parameters,
DownloadStringCompletedEventHandler asyncResult)
{
string url =
string.Format("http://api.flickr.com/services/rest/?method={0}&api_key={1}",
methodName, apiKey);
var q =
from prop in parameters.GetType().GetProperties(BindingFlags.Public | BindingFlags.Instance)
select string.Format("&{0}={1}", prop.Name, prop.GetValue(parameters, null).ToString());
url += string.Join("", q.ToArray());
// Or for linq addicts :p
// url += q.Aggregate(new StringBuilder(), (sb, value) => sb.Append(value)).ToString();
WebClient webClient = new WebClient();
webClient.DownloadStringCompleted += asyncResult;
webClient.DownloadStringAsync(new Uri(url));
}
Let's say this is the end of part I.
We could now think about generalizing the use of an object as a readonly dictionary.
What I propose is to offer a way to wrap an object in a generic class implementing IDictionary<TKey, TValue>. IDictionary is quite long to implement but here is an abstract of the important methods.
public class ObjectDictionary<T> : IDictionary<string, object>
{
public ObjectDictionary(T instance)
{
this.instance = instance;
}
private T instance;
#region IDictionary<string,object> Members
public bool ContainsKey(string key)
{
return typeof(T).GetProperty(key) != null;
}
public ICollection<string> Keys
{
get
{
return typeof(T).GetProperties()
.Select(p => p.Name).ToArray();
}
}
public bool TryGetValue(string key, out object value)
{
var p = typeof(T).GetProperty(key);
if (p == null)
{
value = null;
return false;
}
else
{
value = p.GetValue(instance, null);
return true;
}
}
public ICollection<object> Values
{
get
{
return typeof(T).GetProperties()
.Select(p => p.GetValue(instance, null)).ToArray();
}
}
public object this[string key]
{
get
{
object result = null;
if (TryGetValue(key, out result))
return result;
else
throw new Exception("Key not found");
}
set
{
object result = null;
if (TryGetValue(key, out result))
result = value;
else
throw new Exception("Key not found");
}
}
...
#endregion
#region ICollection<KeyValuePair<string,object>> Members
public int Count
{
get { return typeof(T).GetProperties().Length; }
}
public bool IsReadOnly
{
get { return true; }
}
...
#endregion
#region IEnumerable<KeyValuePair<string,object>> Members
public IEnumerator<KeyValuePair<string, object>> GetEnumerator()
{
var q =
from p in typeof(T).GetProperties()
select new KeyValuePair<string, object>(p.Name, p.GetValue(instance, null));
return q.GetEnumerator();
}
#endregion
#region IEnumerable Members
IEnumerator IEnumerable.GetEnumerator()
{
return GetEnumerator();
}
#endregion
}
Then you can write things like:
ObjectDictionary<Customer> c =
new ObjectDictionary<Customer>(
new Customer { ID = "1", CompanyName = "Microsoft", ContactName = "Mitsu" });
Console.WriteLine(c["CompanyName"]);
With an extension method ?
public static class ObjectDictionaryExtensions
{
public static ObjectDictionary<T> AsDictionary<T>(this T instance)
{
return new ObjectDictionary<T>(instance);
}
}
Use:
var cust = new Customer { ID = "1", CompanyName = "Microsoft", ContactName = "Mitsu" };
var c = cust.AsDictionary();
Console.WriteLine(c["CompanyName"]);
With an implicit conversion ?
public class ObjectDictionary<T> : IDictionary<string, object>
{
public ObjectDictionary(T instance)
{
this.instance = instance;
}
public static implicit operator T (ObjectDictionary<T> source)
{
return source.instance;
}
public static implicit operator ObjectDictionary<T> (T source)
{
return source.AsDictionary();
}
...
}
Use:
ObjectDictionary<Customer> c =
new Customer { ID = "1", CompanyName = "Microsoft", ContactName = "Mitsu"};
Of course all these features are more funny to use with anonymous types:
var cust = new { ID="1", CompanyName="Microsoft"};
var c = c.AsDictionary();
var id = c["ID"];
Let's see one last point. In the case of an anonymous type, we can't use the following syntax:
var c =
new ObjectDictionary<?>(new { ID = "1", CompanyName = "Microsoft", ContactName = "Mitsu"});
This is a classical problem where a regular constructor can not infer T from the parameters. If you want to do it, you have to create a static generic method to create your instance. Then the inference will work fine and make the use of an anonymous type possible.
public class ObjectDictionary
{
public static ObjectDictionary<T> Create<T>(T instance)
{
return new ObjectDictionary<T>(instance);
}
}
Use:
var c = ObjectDictionary.Create(new { ID = "1", CompanyName = "Microsoft", ContactName = "Mitsu" });
foreach (var prop in c.Keys)
Console.WriteLine(c[prop]);
You can find the source code for VS2008 attached to this post.
I have just finished converting the control to silverlight one week away from Silverlight 2 beta 2 release date, so I have been waiting for it !
For people to be able to compare code (quite similar) and behavior between the WPF and the Silverlight control, I have kept the same codeplex project to host the whole solution.
So the address is still the same: http://www.codeplex.com/wpfbookcontrol and the project title has been renamed to 'WPF and Silverlight BookControls'.
The silverlight control is a bit different:
- it's a UserControl.
- the data connection natively proposes data virtualization.
The ItemsControl control does not allow data virtualization today. As I absolutely wanted it for this silverlight version, I voluntarily did not respect the ItemsSource behavior.
As a datasource, you have to provide a very simple interface:
public interface IDataProvider
{
object GetItem(int index);
int GetCount();
}
The control will ask you on the fly for those two methods to dynamically retrieve needed pages.
In your application, just add a reference to SLMitsuControls.
Then use it in your xaml page: in this sample, I am using a static content to defines pages.
<UserControl x:Class="SLBookDemoApp.Page"
xmlns="http://schemas.microsoft.com/client/2007"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:local="clr-namespace:SLMitsuControls;assembly=SLMitsuControls"
Width="400" Height="300" Loaded="UserControl_Loaded">
<UserControl.Resources>
<ItemsControl x:Name="pages">
<Button Content="Page 0" Click="Button_Click" />
<Button Content="Page 1" Background="Green" Click="Button_Click_1" />
<Button Content="Page 2" Background="Yellow" Click="Button_Click" />
<Button Content="Page 3" Background="Red" Click="Button_Click_1" />
</ItemsControl>
</UserControl.Resources>
<Grid>
<local:UCBook x:Name="book" Margin="50" />
</Grid>
</UserControl>
Then you must implement IDataProvider and call the SetData() method.
public partial class Page : UserControl, IDataProvider
{
public Page()
{
InitializeComponent();
}
private void UserControl_Loaded(object sender, RoutedEventArgs e)
{
book.SetData(this);
}
#region IDataProvider Members
public object GetItem(int index)
{
return pages.Items[index];
}
public int GetCount()
{
return pages.Items.Count;
}
#endregion
private void Button_Click(object sender, RoutedEventArgs e)
{
book.AnimateToNextPage(500);
}
private void Button_Click_1(object sender, RoutedEventArgs e)
{
book.AnimateToPreviousPage(500);
}
}
Let me remind you that you can find a good dynamic sample in this flickr application:
Here is a control that everybody can easily use. This allow you to display Flickr pictures in a blog post or in any web page.
For example this set of pictures (http://www.flickr.com/photos/benjamingauthey/sets/72157604570177365/), taken by my friend Benjamin during Paris Remix 08 can be browsed just here in this post.
Now, how to get this on your own web page/blog ? There is just a few steps to follow and here is a video that explains how to do it :
Go to this page to configure your own control: http://blogs.msdn.com/mitsu/archive/2008/05/14/create-a-virtual-book-with-your-flickr-pictures.aspx
Full code source will be released very soon.
I was getting really bored with testing .ContainsKey() at each time I wanted to read a value from a dictionary.
Dictionary<string, string> dico;
if (dico.ContainsKey("key"))
value = dico["key"];
else
value = "default";
A incredibly simple extension method solves this so easily:
public static class MyExtensions
{
public static TValue GetValue<TKey, TValue>(
this IDictionary<TKey, TValue> source,
TKey key, TValue defaultValue)
{
if (source.ContainsKey(key))
return source[key];
else
return defaultValue;
}
}
The call from any dictionary now becomes:
value = dico.GetValue("key", "default");
...sometimes I just wonder how I did not think about such solutions earlier ! :-)
Enjoy,
Code is coming very soon..
[Update]: code is now available here !
Mitsu
Move the mouse cursor around the corners