IdentityMine

| Tags: WPF

originally posted by Josh Smith: (link) - please comment at original post

One of the most interesting (and potentially dangerous) new features in C# 4.0 is support for the dynamic type.  It allows certain pieces of your code to bypass the normal compile-time type checking features that we have grown to know and love.  You can use a dynamic object however you want to, and the C# compiler will ignore the members you use on it.  At runtime, if the methods/properties/etc. your code tries to use are not actually present on the object, an exception is thrown.  If they do exist, they will be linked to and invoked dynamically.   This technique is called dynamic dispatch.  What you lose in safety, you gain in flexibility.

In addition to the dynamic keyword there is also support in the .NET Framework 4.0 for creating types that support dynamic dispatch. The System.Dynamic.DynamicObject class allows you to specify how an object performs dynamic dispatch.  You can subclass DynamicObject and override some of its methods, such as TrySetMember and TryGetMember, to perform whatever logic you need to link a dynamic property set or get to a backing store.

Sound pretty cool, right?  That’s what I thought when I first heard about this functionality.  Then I thought, “Why would I ever need to use this?”  I didn’t have an answer to that question, until tonight.  It dawned on me, while trying to read something not related to programming (damn OCD!), that this could be leveraged to implement a simple, reusable means of marshaling property changes to the UI thread.

As you probably know, you cannot get or set a visual element’s properties from any thread except the thread on which it was created.  When the UI thread creates an element, that element thereafter has an affinity to the UI thread’s Dispatcher object.  The only property on an element that you can access from another thread is its Dispatcher property.  Once you have a reference to an element’s Dispatcher, you can use it to dispatch method calls that manipulate the element on the UI thread.

If you work on a lot of UI-level components and controls, like I do, you probably find yourself writing a lot of code that works with Dispatchers just to do something simple like get or set an element’s property.  What a pain!  It turns out that this pain can be somewhat eliminated by making use of DynamicObject and the dynamic keyword.  Here’s a contrived example that shows how…

The code snippet above shows how to use my DynamicElement class.  It acts as a proxy to an element, which intercepts all access to an element’s properties.  This interception allows the DynamicElement to make use of the visual element’s Dispatcher, if necessary.  Here is how the interception works for setting a property:

The TryGetMember implementation is similar to the code seen above.

You can download the source code here.  NOTE: Rename the file extension from .DOC to .ZIP and then decompress it.

Remember to please comment at original post: (link)

Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInPin on PinterestShare on RedditShare on TumblrEmail this to someoneDigg thisFlattr the authorShare on StumbleUpon

Comments are closed.