Knowledgecast https://docs.microsoft.com/archive/blogs/knowledgecast/feed.xml Interesting solutions to interesting problems Wed, 17 Apr 2019 03:21:59 GMT en-US hourly 1 Proxying Cross-domain Web Requests in Silverlight https://docs.microsoft.com/archive/blogs/knowledgecast/proxying-cross-domain-web-requests-in-silverlight Wed, 15 Sep 2010 13:06:00 GMT https://blogs.msdn.microsoft.com/knowledgecast/2010/09/15/proxying-cross-domain-web-requests-in-silverlight/ If you want to get straight to the code, you can find it here:

I was going to think of a clever title for this post, but then I realized that I’d really rather prefer that people be able to find this post when they’re looking for a solution to this problem. All Silverlight application developers (and I’m sure a few Flash developers as well) have come across this problem sooner or later. You see a great web service, you realize it could really use a nice RIA frontend. You set out to build it, only to realize that the builders of the web service didn’t put up a crossdomain.xml or clientaccesspolicy.xml file that lets your Silverlight application make requests to their web service. Now you have one of three choices:

  1. Convince the web site owners to put your application on their server. Cheeky? Yes. And it could be a looong time before that happens :)
  2. Try selling them on the idea of putting up a cross-domain policy file. In my experience most web sites are amenable to the idea. In this case, you’re stuck waiting for them to put the file on the server
  3. Write some code on your web server that can proxy your requests to this web service for you. This gets you off running quick, but then you’ve coded up a frontend that relies on this proxy web service

Option 3 gets you up and running fastest, but it also sticks you with the task of migrating your code when the web service eventually adds a cross-domain policy file. Wouldn’t it be nice if there we a way for you to write code very similar to one you’d eventually use? So that you could just flip a switch (or change the fewest lines of code) when the real thing came along? Well I’m glad you asked :) Because of course there is.

First things first, this is NOT a replacement for the built in HttpWebRequest class. In fact, the code here is pure demoware, you have been warned. With that out of the way, let us first begin by looking at our proxy web service. All the code for the service is located in the Knowledgecast.HttpProxy.Server project. The ServiceContract is simple:

   1: /// <summary>
   2:     /// The service contract for a our proxy web request service
   3:     /// </summary>
   4:     [ServiceContract(Namespace = "http://Knowledgecast.HttpProxy.Server.IMakeWebRequest")]
   5:     interface IMakeWebRequest
   6:     {
   7:         /// <summary>
   8:         /// Make an HttpWebRequest on the client's behalf
   9:         /// </summary>
  10:         /// <param name="url">The url for the request</param>
  11:         /// <param name="method">The method, GET/POST/PUT/DELETE</param>
  12:         /// <param name="requestBody">The request body (if applicable)</param>
  13:         /// <param name="contentType">The content type of the request</param>
  14:         /// <param name="headers">Any headers that need sending out as part of the request</param>
  15:         /// <returns>The response for the web request formatted as a 
  16:         /// custom data contract called ProxyWebResponse. We can't use HttpWebResponse
  17:         /// because it can't be serialized. Also, its a framework class.</returns>
  18:         [OperationContract]
  19:         ProxyWebResponse MakeHttpWebRequest(string url, string method, byte[] requestBody, string contentType, Dictionary<string, string> headers);
  20:     }

The contract has only one method called MakeHttpWebRequest. I’m not going to show off the method code here (link to the code is at the bottom of this post) because all it does is create a new HttpWebRequest based on the paramters in the MakeHttpWebRequest operation. There’s some special handling for headers such as “accept” and “useragent” because HttpWebRequest expects them to be set as properties on the HttpWebRequest instance rather than as additions to the Headers collection.

The other interesting that’s worth noting is the return type. You might have expected to see HttpWebRequest here but there’s a couple of reasons I don’t use it. For one thing, HttpWebRequest is a class that belongs to the .NET framework so it’s not a good idea to use it in our service contract. The other problem is that HttpWebRequest isn’t marked with the DataContract attribute. This is the same reason the ProxyWebRequest class used here does not inherit the WebResponse class like you’d probably expect it to. In fact, ProxyWebRequest is a plain-jane data contract. Here’s what it looks like:

   1: /// <summary>
   2:     /// This data contract is used to return the data that came out as part of 
   3:     /// the HttpWebResponse
   4:     /// </summary>
   5:     [DataContract(Namespace = "http://Knowledgecast.HttpProxy.Server.IMakeWebRequest")]
   6:     public class ProxyWebResponse
   7:     {
   8:         /// <summary>
   9:         /// Takes in an HttpWebResponse and populates itself with the relevant
  10:         /// values
  11:         /// </summary>
  12:         /// <param name="response"></param>
  13:         public ProxyWebResponse(HttpWebResponse response)
  14:             : this(response.IsFromCache, response.ResponseUri, response.IsMutuallyAuthenticated)
  15:         {
  16:             ContentLength = response.ContentLength;
  17:             ContentType = response.ContentType;
  18:             Stream s = response.GetResponseStream();
  19:  
  20:             int bytesRead = 0;
  21:             int numBytesToRead = (int)ContentLength;
  22:             if (s.CanRead)
  23:             {
  24:                 ResponseBody = new byte[ContentLength];
  25:                 while (true)
  26:                 {                    
  27:                     int n = s.Read(ResponseBody, bytesRead, numBytesToRead);
  28:                     if (n == 0)
  29:                     {
  30:                         break;
  31:                     }
  32:  
  33:                     bytesRead += n;
  34:                     numBytesToRead -= n;
  35:                 }
  36:  
  37:                 s.Close();
  38:             }
  39:  
  40:             if (response.Headers != null && response.Headers.Count > 0)
  41:             {
  42:                 Headers.Add(response.Headers);
  43:             }
  44:         }
  45:  
  46:         /// <summary>
  47:         /// Constructor
  48:         /// </summary>
  49:         /// <param name="isFromCache">Is the response from a cache?</param>
  50:         /// <param name="responseUri">The response URL</param>
  51:         /// <param name="isMutuallyAuthenticated">Are the server/client mutually authenticated?</param>
  52:         public ProxyWebResponse(bool isFromCache, Uri responseUri, bool isMutuallyAuthenticated)
  53:         {
  54:             IsFromCache = isFromCache;
  55:             ResponseUri = responseUri;
  56:             IsMutuallyAuthenticated = isMutuallyAuthenticated;
  57:         }
  58:  
  59:         /// <summary>
  60:         /// The number of bytes returned by the request. Content length does not include
  61:         ///     header information.
  62:         /// </summary>
  63:         [DataMember]
  64:         public long ContentLength { get; set; }
  65:  
  66:         /// <summary>
  67:         /// A string that contains the content type of the response.
  68:         /// </summary>
  69:         [DataMember]
  70:         public string ContentType { get; set; }
  71:  
  72:         HeaderCollection _headers;
  73:         /// <summary>
  74:         /// A HeaderCollection that contains the header information returned
  75:         ///     with the response.
  76:         /// </summary>
  77:         [DataMember]
  78:         public HeaderCollection Headers
  79:         {
  80:             get
  81:             {
  82:                 if (_headers == null)
  83:                 {
  84:                     _headers = new HeaderCollection();
  85:                 }
  86:  
  87:                 return _headers;
  88:             }
  89:             set
  90:             {
  91:                 _headers = value;
  92:             }
  93:         }
  94:  
  95:         /// <summary>
  96:         /// true if the response was taken from the cache; otherwise, false.
  97:         /// </summary>
  98:         [DataMember]
  99:         public bool IsFromCache { get; set; }
 100:  
 101:         /// <summary>
 102:         /// A string that contains the name of the server that sent the response.
 103:         /// </summary>
 104:         [DataMember]
 105:         public Uri ResponseUri { get; set; }
 106:  
 107:         /// <summary>
 108:         /// true if mutual authentication occurred; otherwise, false.
 109:         /// </summary>
 110:         [DataMember]
 111:         public bool IsMutuallyAuthenticated { get; set; }
 112:  
 113:         /// <summary>
 114:         /// The body of the response as a byte buffer. This is obtained
 115:         /// by reading in the stream of bytes returned by 
 116:         /// HttpWebResponse.GetResponseStream
 117:         /// </summary>
 118:         [DataMember]
 119:         public byte[] ResponseBody { get; set; }
 120:     }

 

 

That takes care of the web service. Now lets move on to the client. This is where all the clever code is anyway. We need to make sure it is very easy for you to switch from using this custom proxy service to the real HttpWebRequest when the web site owners eventually put a cross-domain policy online. So we should find a way to plug in to the existing WebRequest infrastructure on the client. Turns out that this is really straightforward to do. First, we start out by implementing a custom version of the WebRequest class. Here’s what our ProxyWebRequest looks like:

   1: /// <summary>
   2:     /// The ProxyWebRequest internally forwards the web request made
   3:     /// on it to the Web Request Proxy service. This means that the server
   4:     /// actually makes the request on the Silverlight application's behalf
   5:     /// thus removing the cross-domain web request restrictions of Silverlight. Be
   6:     /// mindful however that this puts stress on the server and also
   7:     /// complicates authentication (double hop et al)
   8:     /// </summary>
   9:     public class ProxyWebRequest : WebRequest
  10:     {
  11:         ProxyService.ProxyWebResponse _response = null;
  12:         Knowledgecast.HttpProxy.Client.ProxyService.MakeWebRequestClient client = null;
  13:         byte[] _requestBody;
  14:  
  15:         /// <summary>
  16:         /// Create a ProxyWebRequest based on the url
  17:         /// </summary>
  18:         /// <param name="url">The URL to which a request must be created</param>
  19:         public ProxyWebRequest(Uri url)
  20:         {
  21:             _requestUri = url;
  22:             client = new Knowledgecast.HttpProxy.Client.ProxyService.MakeWebRequestClient();
  23:             client.MakeHttpWebRequestCompleted += MakeHttpsWebRequestCompleted;
  24:         }
  25:  
  26:         void MakeHttpsWebRequestCompleted(object sender, Knowledgecast.HttpProxy.Client.ProxyService.MakeHttpWebRequestCompletedEventArgs e)
  27:         {
  28:             if (e.Cancelled == false && e.Error == null)
  29:             {
  30:                 object[] state = e.UserState as object[];
  31:                 if (state != null)
  32:                 {
  33:                     AsyncCallback callback = state[0] as AsyncCallback;
  34:                     object originalState = state[1];
  35:                     _response = e.Result;
  36:                     callback(new ProxyWebRequestAsyncResult(originalState, true));
  37:                 }
  38:             }
  39:         }
  40:  
  41:         /// <summary>
  42:         /// Not implemented
  43:         /// </summary>
  44:         public override void Abort()
  45:         {
  46:             throw new NotImplementedException();
  47:         }
  48:  
  49:         /// <summary>
  50:         /// Return a request stream that can be used to fill in request
  51:         /// data. This is an asynchronous method
  52:         /// </summary>
  53:         /// <param name="callback">Callback method to call when the request stream is ready</param>
  54:         /// <param name="state">State to pass on to the callback method</param>
  55:         /// <returns>An IAsyncResult indicating the status of the request</returns>
  56:         public override IAsyncResult BeginGetRequestStream(AsyncCallback callback, object state)
  57:         {
  58:             var result = new ProxyWebRequestAsyncResult(state, true);
  59:             callback(result);
  60:             return result;
  61:         }
  62:  
  63:         /// <summary>
  64:         /// Call this method in the callback method passed to BeginGetRequestStream
  65:         /// to actually get the stream. Ensure that you set the ContentLength property
  66:         /// before you call this method or you will get a stream with 0 capacity
  67:         /// </summary>
  68:         /// <param name="asyncResult">IAsyncResult that was passed to the callback method</param>
  69:         /// <returns>Stream which can be used to populate the request data (if applicable)</returns>
  70:         public override Stream EndGetRequestStream(IAsyncResult asyncResult)
  71:         {
  72:             _requestBody = new byte[(int)ContentLength];
  73:             Stream s = new MemoryStream(_requestBody, true);
  74:             return s;
  75:         }
  76:  
  77:         /// <summary>
  78:         /// Begins an asynchronous request for
  79:         ///     an Internet resource.
  80:         /// </summary>
  81:         /// <param name="callback">The System.AsyncCallback delegate</param>
  82:         /// <param name="state">An object containing state information for this asynchronous request</param>
  83:         /// <returns>An System.IAsyncResult that references the asynchronous request</returns>
  84:         public override IAsyncResult BeginGetResponse(AsyncCallback callback, object state)
  85:         {
  86:             var result = new ProxyWebRequestAsyncResult(state, false);
  87:  
  88:             Dictionary<string, string> headersDictionary = null;
  89:             if (Headers != null && Headers.Count > 0)
  90:             {
  91:                 headersDictionary = new Dictionary<string, string>();
  92:                 foreach (var key in Headers.AllKeys)
  93:                 {
  94:                     headersDictionary.Add(key, Headers[key]);
  95:                 }
  96:             }
  97:  
  98:             client.MakeHttpWebRequestAsync(RequestUri.AbsoluteUri, Method, _requestBody, ContentType, headersDictionary, new object[] { callback, state });
  99:             return result;
 100:         }
 101:  
 102:         /// <summary>
 103:         /// Returns a System.Net.WebResponse.
 104:         /// </summary>
 105:         /// <param name="asyncResult">An System.IAsyncResult that references a pending request for a response</param>
 106:         /// <returns>A System.Net.WebResponse that contains a response to the Internet request.</returns>
 107:         public override WebResponse EndGetResponse(IAsyncResult asyncResult)
 108:         {
 109:             return new ProxyWebResponse(_response);
 110:         }
 111:  
 112:         /// <summary>
 113:         /// The content type of the request data
 114:         /// </summary>
 115:         public override string ContentType { get; set; }
 116:  
 117:         /// <summary>
 118:         /// The number of bytes of request data being sent
 119:         /// </summary>
 120:         public override long ContentLength { get; set; }
 121:  
 122:         /// <summary>
 123:         /// A System.Net.WebHeaderCollection containing the header name/value pairs associated
 124:         ///     with this request.
 125:         /// </summary>
 126:         public override WebHeaderCollection Headers { get; set; }
 127:  
 128:         /// <summary>
 129:         /// The protocol method to use in this request
 130:         /// </summary>
 131:         public override string Method { get; set; }
 132:  
 133:         private Uri _requestUri;
 134:         /// <summary>
 135:         /// A System.Uri representing the resource associated with the request
 136:         /// </summary>
 137:         public override Uri RequestUri
 138:         {
 139:             get
 140:             {
 141:                 return _requestUri;
 142:             }
 143:         }
 144:     }

 

We override all of the overrideable properties and methods available in the WebResponse class. The most important method in the above code is our implementation of the BeginGetResponse method. The implementation actually calls the MakeHttpWebRequest service method on the service proxy. As with all calls to web services in Silverlight, the call is asynchronous. In the completed event (the MakeHttpsWebRequestCompleted method) we save the returned ProxyWebResponse into a class member variable. We then call the callback that the client code registered when it called BeginGetResponse. When the EndGetResponse method gets called (usually from the callback method) we instantiate a new ProxyWebResponse (there’s a client version as well, which inherits from WebResponse) based on the ProxyWebResponse returned by the service. The reason we need to do this is because the EndGetResponse method MUST return a type that inherits from WebResponse.

Now the last thing we need to do is make sure client code has a way of getting a handle to our custom ProxyWebRequest. The best way to do this is to register it with the WebRequest class. Before that however, we need to create an IWebRequestCreator that can create ProxyWebRequest objects for WebRequest. So here’s our ProxyWebRequestCreator:

   1: /// <summary>
   2:     /// Creates a ProxyWebRequest. Used to register the ProxyWebRequest
   3:     /// prefix (phttp and phttps)
   4:     /// </summary>
   5:     public class ProxyWebRequestCreator : IWebRequestCreate
   6:     {
   7:         #region IWebRequestCreate Members
   8:  
   9:         /// <summary>
  10:         /// Create a ProxyWebRequest based on a URL
  11:         /// </summary>
  12:         /// <param name="uri">URL of the request</param>
  13:         /// <returns>A ProxyWebRequest instance</returns>
  14:         public WebRequest Create(Uri uri)
  15:         {
  16:             return new ProxyWebRequest(uri);
  17:         }
  18:  
  19:         #endregion
  20:     }

Pretty simple that bit of code. Just creates a new ProxyWebRequest and returns it. Now we’re going to add a static method to our ProxyWebRequest class to register our ProxyWebRequestCreator with a prefix. Here’s that code:

   1: /// <summary>
   2:         /// Register the prefixes (phttp and phttps) used to create 
   3:         /// a ProxyWebRequest
   4:         /// </summary>
   5:         public static void RegisterHttpProxyPrefix()
   6:         {
   7:             WebRequest.RegisterPrefix("phttps", new ProxyWebRequestCreator());
   8:             WebRequest.RegisterPrefix("phttp", new ProxyWebRequestCreator());
   9:         }

 

 

Right! Now that all pieces are in place, what exactly does one need to be able to use this code? Simple. Here’s how you would instantiate a ProxyWebRequest:

   1: var request = WebRequest.Create("phttp://search.twitter.com/search.atom?q=" + HttpUtility.UrlEncode(query) + "&rpp=10");

Notice the extra p at the front of the address? That’s what ensures we get a ProxyWebRequest instead of a regular HttpWebRequest. Before we use this code however, we must register the phttp prefix with WebRequest. So we would need to do this at some point in our code:

   1: ProxyWebRequest.RegisterHttpProxyPrefix();

 

 

And what do you do when you want to switch back to the regular HttpWebRequest? Simple again. You just change your WebRequest.Create to this:

   1: var request = WebRequest.Create("http://search.twitter.com/search.atom?q=" + HttpUtility.UrlEncode(query) + "&rpp=10");

 

That’s it! Keep in mind that for the proxy service to work, you will also need a ServiceReferences.ClientConfig in your client project (the sample has an example of this) which registers the proxy service’s endpoint configuration. Here’s the code for this post and a quick sample of how to use it:

Have fun!

]]> Automatic Change Notification for Your View Models https://docs.microsoft.com/archive/blogs/knowledgecast/automatic-change-notification-for-your-view-models Wed, 02 Jun 2010 00:20:29 GMT https://blogs.msdn.microsoft.com/knowledgecast/2010/06/02/automatic-change-notification-for-your-view-models/ Note: If you’d rather just jump into the code the sample that goes with this post is here:

One of the features in WPF Starter Kit (http://wpfstarterkit.codeplex.com) that I am very proud of is the automatic change notification functionality. While implementing the INotifyPropertyChanged method in a base class makes our lives a little easier, it still means you lose the benefit of automatic properties that comes with C# 3.0. So instead of looking like this:

   1: public class Window1ViewModel
   2:     {
   3:         public bool TestProperty { get; set; }
   4:     }

your view models typically end up looking something like this:

   1: public class Window1ViewModel : BaseViewModel
   2:     {
   3:         private bool _testProperty;
   4:         public bool TestProperty
   5:         {
   6:             get
   7:             {
   8:                 return _testProperty;
   9:             }
  10:             set
  11:             {
  12:                 _testProperty = value;
  13:                 OnPropertyChanged("TestProperty");
  14:             }
  15:         }
  16:     }

As you can probably tell, the OnPropertyChanged method in the BaseViewModel raises the PropertyChanged event on behalf of our view model. Now that might not look like a big difference when there’s just one property involved but maintaining a view model with several properties can quickly get out of hand. Add to that the fact that at some point, someone on your team will invariably end up changing the property name and forget to change the text in the call to OnPropertyChanged. What does this mean? This means change notification just stops working. Just like that. Pandemonium! :)

There are of course ways to mitigate this problem. Firstly, we could implement some sort of check in the OnPropertyChanged event to ensure that the string passed in does actually refer to a property on the current object. Here’s what our BaseViewModel looks like:

   1: /// <summary>
   2: /// Base class for all classes which act as data source for user interface elements.
   3: /// This class mplements the INotifyPropertyChanged interface
   4: /// </summary>
   5: public abstract class BaseViewModel : INotifyPropertyChanged
   6: {
   7:     /// <summary>
   8:     /// Called when [property changed].
   9:     /// </summary>
  10:     /// <param name="propertyName">Name of the property.</param>
  11:     protected void OnPropertyChanged(string propertyName)
  12:     {
  13:         PropertyChangedEventHandler eventHandlers = this.PropertyChanged;
  14:         if (eventHandlers != null)
  15:         {
  16:             VerifyPropertyName(propertyName);
  17:             eventHandlers(this, new PropertyChangedEventArgs(propertyName));
  18:         }
  19:     }
  20:  
  21:     /// <summary>
  22:     /// Verifies the name of the property.
  23:     /// </summary>
  24:     /// <param name="propertyName">Name of the property.</param>
  25:     private void VerifyPropertyName(string propertyName)
  26:     {
  27:         if (TypeDescriptor.GetProperties(this)[propertyName] == null)
  28:         {
  29:             string msg = string.Format(CultureInfo.CurrentCulture, "Invalid property name : {0}", propertyName);
  30:             throw new ArgumentOutOfRangeException("propertyName", msg);
  31:         }
  32:     }
  33:  
  34:     #region INotifyPropertyChanged Members
  35:  
  36:     public event PropertyChangedEventHandler PropertyChanged;
  37:  
  38:     #endregion
  39: }

Notice the VerifyPropertyName method that gets called by OnPropertyChanged to verify the property’s name. This is a good solution, but there’s still a problem. Verifying the property name gives us runtime checking but it still doesn’t prevent code that causes this issue getting compiled and checked in. Finally, this still doesn’t solve the ugliness issue. Our view model still contains a LOT of code that does not have much to do with our business logic. Code that is just plumbing to support MVVM.

Enter interception! Interception is the technique we’re going to use to bring our view model code as close to the first code snippet (with automatic properties and no calls to OnPropertyChanged) as possible. With interception, our view model will look something like this:

   1: public class Window1ViewModel : BaseViewModel
   2: {
   3:     public virtual bool TestProperty { get; set; }        
   4: }
A huge improvement, wouldn’t you say? So without further adieu let’s get started.

 

First, lets get set up:

1. Download the sample solution above and open it up. It has all the code we’re going to be talking about.

OR

1. Start a new WPF Windows application

2. Add the BaseViewModel class shown above

3. You will already have a new Window called Window1. Add a class called Window1ViewModel:

   1: public class Window1ViewModel : BaseViewModel
   2: {
   3:     private bool _testProperty;
   4:     public bool TestProperty
   5:     {
   6:         get
   7:         {
   8:             return _testProperty;
   9:         }
  10:         set
  11:         {
  12:             _testProperty = value;
  13:             OnPropertyChanged("TestProperty");
  14:         }
  15:     }
  16: }

4. Add a Loaded event handler to Window1 and add the following line of code to the handler:

   1: DataContext = new Window1ViewModel();

 

What we’ve done here is set up a very simple example of Model View ViewModel (MVVM) where the ViewModel is supported by a simple base class. To add support for interception we will use the Unity Dependency Injection (DI) container (http://unity.codeplex.com/) released by the patterns and practices team. While Unity is by no means the only way to do DI in .NET, it is the one I am most familiar with. If you want to read up on the need and theory behind DI this is a good starting point: http://msdn.microsoft.com/en-us/magazine/cc163739.aspx. The next step is to go ahead and add references to all of the assemblies that ship with the Unity container.

Now we’ll write what in Unity parlance is called a “Call Handler”. A call handler basically handles a method (or in our case, property) call. What this means is that if you have a call handler set up on an object or type the call handler is executed before any methods (you get to choose which methods to target) of that object or type are called. What this lets you do is intercept the call and do something meaningful with what you have in the call handler. For example, a call handler might be used logging or to audit method entry points. A Unity call handler must inherit from the Microsoft.Practices.Unity.InterceptionExtension.ICallHandler interface. Here’s what ICallHandler looks like:

   1: public interface ICallHandler
   2: {
   3:     int Order { get; set; }
   4:  
   5:     IMethodReturn Invoke(IMethodInvocation input, GetNextHandlerDelegate getNext);
   6: }

The Invoke method is where your call handler can do any work that it needs to. The Order property is the your call handler’s position (if there are other call handlers involved). We’re going to implement a call handler that:

  1. figures out whether or not the method being called is a property setter.
  2. figures out whether the value being set if different from the old value
  3. If 1 and 2 are true, find the PropertyChangedCallback event on the current or one of the base classes
  4. Check if the PropertyChangedCallback has any handlers assigned and if so, call those handlers

Here’s what the PropertyChangedCallHandler looks like:

   1: public class PropertyChangedCallHandler : ICallHandler
   2: {
   3:     #region ICallHandler Members
   4:  
   5:     public IMethodReturn Invoke(IMethodInvocation input, GetNextHandlerDelegate getNext)
   6:     {
   7:         bool shouldRaise = ShouldRaiseEvent(input);
   8:         IMethodReturn res = getNext()(input, getNext);
   9:  
  10:         if (res.Exception == null && shouldRaise)
  11:         {
  12:             RaiseEvent(input);
  13:         }
  14:  
  15:         return res;
  16:     }
  17:  
  18:     public int Order
  19:     {
  20:         get;
  21:         set;
  22:     }
  23:  
  24:     #endregion
  25:  
  26:     private bool ShouldRaiseEvent(IMethodInvocation input)
  27:     {
  28:         MethodBase methodBase = input.MethodBase;
  29:  
  30:         //Is the method a property setter?
  31:         if (!methodBase.IsSpecialName || !methodBase.Name.StartsWith("set_"))
  32:         {
  33:             return false;
  34:         }
  35:  
  36:         //Get the name of the property out so we can use it to raise a 
  37:         //property changed event
  38:         string propertyName = methodBase.Name.Substring(4);
  39:  
  40:         //Retrieve the property getter
  41:         PropertyInfo property = methodBase.ReflectedType.GetProperty(propertyName);
  42:         MethodInfo getMethod = property.GetGetMethod();
  43:  
  44:         //IF the property has no get method, we don't care
  45:         if (getMethod == null)
  46:         {
  47:             return false;
  48:         }
  49:  
  50:         //Get the current value out
  51:         object oldValue = getMethod.Invoke(input.Target, null);
  52:  
  53:         //Get the updated value
  54:         object value = input.Arguments[0];
  55:  
  56:         //Is the new value null?
  57:         if (value != null)
  58:         {
  59:             //Is the new value different from the old value?
  60:             if (value.Equals(oldValue) == false)
  61:             {
  62:                 return true;
  63:             }
  64:         }
  65:         else
  66:         {
  67:             //Is the new value (null) different from the 
  68:             //old value (non-null)?
  69:             if (value != oldValue)
  70:             {
  71:                 return true;
  72:             }
  73:         }
  74:  
  75:         return false;
  76:     }
  77:  
  78:     private void RaiseEvent(IMethodInvocation input)
  79:     {
  80:         FieldInfo field = null;
  81:  
  82:         //Get a reference to the PropertyChanged event out of the current 
  83:         //type or one of the base types
  84:         var type = input.MethodBase.ReflectedType;
  85:         while (field == null && type != null)
  86:         {
  87:             field = type.GetField("PropertyChanged", BindingFlags.Instance | BindingFlags.NonPublic);
  88:             type = type.BaseType;
  89:         }
  90:  
  91:         //If we found the PropertyChanged event
  92:         if (field != null)
  93:         {
  94:             //Get the event handler if there is one
  95:             var evt = field.GetValue(input.Target) as MulticastDelegate;
  96:             if (evt != null)
  97:             {
  98:                 //Get the property name out
  99:                 string propertyName = input.MethodBase.Name.Substring(4);
 100:                 //Invoke the property changed event handlers
 101:                 evt.DynamicInvoke(input.Target, new PropertyChangedEventArgs(propertyName));
 102:             }
 103:         }
 104:     }
 105: }

Note how we use the getNext delegate to call the next interceptor (or the actual method) in line. This is VERY important because if we don’t do this the method being intercepted won’t actually get called. We definitely don’t want that happening now do we :)

The ShouldRaiseEvent method implements checks whether or not the method being called is a property setter and whether the value being set is different from the existing value. This is important because we only want to target properties for interception and we want to ensure we’re not raising the PropertyChanged callback without reason. The RaiseEvent method is where we actually raise the PropertyChanged event. Notice that it actually climbs up the inheritance hierarchy of the current type to find the PropertyChanged event. This saves us the task of implementing INotifyPropertyChanged in every single view model we write. Instead, we can just implement it is in the BaseViewModel (as we have) and rely on the call handler to find the event.

At this point you’re probably wondering how to link up the PropertyChangedCallHandler with our Window1ViewModel. We do this by passing on the responsibility of instantiating the view model to the unity container while telling it to set up the new object for interception with our custom call handler. To do this, we go change the code in Window1’s Loaded event handler from this:

   1: DataContext = new Window1ViewModel();

to this:

   1: var viewModelType = typeof(Window1ViewModel);
   2: var unity = new UnityContainer();
   3: var notificationPolicy = unity.AddNewExtension<Interception>()
   4:         .RegisterType(typeof(BaseViewModel), viewModelType, "Window1")
   5:         .Configure<Interception>()
   6:         .SetDefaultInterceptorFor(viewModelType, new VirtualMethodInterceptor())
   7:         .AddPolicy("NotificationPolicy");
   8:  
   9: notificationPolicy.AddMatchingRule(new PropertyMatchingRule("*", PropertyMatchingOption.Set));
  10: notificationPolicy.AddCallHandler<PropertyChangedCallHandler>();
  11:  
  12: var viewModel = unity.Resolve<BaseViewModel>("Window1");
  13: DataContext = viewModel;

What we’re doing here is:

  1. on line 2, we create a new Unity container
  2. starting on line 3, we tell the container to set up interception for the type Window1ViewModel. We also register the type with a name: Window1. We use a VirtualMethodInterceptor which basically means that all virtual methods (and properties) on objects of this class will be intercepted. We call this interception policy NotificationPolicy and get a reference to it.
  3. We add a matching rule for this policy that basically says we only want to look at properties and we only want to look at property setters. This makes some of the code in PropertyChangedCallHandler.ShouldRaiseEvent redundant but hey, better safe than sorry :)
  4. Finally, we add our PropertyChangedCallHandler to the policy

Basically what we’ve done is tell the unity container that we need it to intercept all objects of type Window1ViewModel and insert the call handler called PropertyChangedCallHandler in some of the method (property setters) calls. This can also be done using application configuration (app.config) and I encourage you to explore that option. The final step of the process is to clean up our view model. We don’t need the OnPropertyChanged call any longer. Here’s what the updated Window1ViewModel ought to look like:

   1: public class Window1ViewModel : BaseViewModel
   2: {
   3:     public virtual bool TestProperty { get; set; }        
   4: }

Not bad huh! Note that we make the property virtual because we used the VirtualMethodInterceptor which is only capable of intercepting virtual properties and methods. Here’s the code for the sample:

The sample application is a simple application where the TestProperty is bound to a CheckBox as well as a TextBlock. When you check the CheckBox the TextBlock value gets updated to True and when you uncheck the CheckBox the TextBlock gets set to False (remember that in WPF, bindings are TwoWay by default). Here’s a couple of screenshots showing that:

image

image 

Have fun. If you need to reach me, use the comment form below. This code (and lots of other useful stuff) is part of the WPF Starter Kit at http://wpfstarterkit.codeplex.com.

]]> Using Strongly Typed Classes to Generate Infopath Forms (Xsd.exe) https://docs.microsoft.com/archive/blogs/knowledgecast/using-strongly-typed-classes-to-generate-infopath-forms-xsd-exe Mon, 26 Apr 2010 11:34:42 GMT https://blogs.msdn.microsoft.com/knowledgecast/2010/04/26/using-strongly-typed-classes-to-generate-infopath-forms-xsd-exe/ I’ve been working on a SharePoint 2007 project recently where part of a workflow involved generating a large number of Infopath forms in a SharePoint Infopath form library. Now one way (and arguably the more popular way) would have been to create an empty form based on the library’s template, save it somewhere and use it as reference to generate the form at runtime, perhaps using an XmlDocument object. Another way, which I hit upon while doing this would be to just package the form as part of the assembly (as an embedded resource) and load it up into an XmlDocument at runtime. This would save us the effort of writing loads of tedious XmlDocument related code. We could then use Xpath expressions to work our way through the document populating the relevant nodes. While both of these methods work, they’re too prone to failure.

That’s when I thought of another idea. An Infopath form is basically an XML file with a bunch of extra processing instructions on top. For example, here’s a super simple Infopath form I put together for this post:

image

The form gathers a bit of data about a user. In fact, it isn’t actually as simple as it looks. The Hobbies section at the bottom is a repeating section that can contain any number of values. Repeating sections (as well as optional sections) are of course quite common in real life Infopath forms so its a good idea to see how our approach works with a form that has one. Here’s what the form’s XML looks like with some dummy data:

   1: <?xml version="1.0" encoding="UTF-8"?>
   2: <?mso-infoPathSolution solutionVersion="1.0.0.4" productVersion="12.0.0" PIVersion="1.0.0.0" href="http://mosstest/TestFormLibrary/Forms/template.xsn" name="urn:schemas-microsoft-com:office:infopath:TestFormLibrary:-myXSD-2010-04-26T19-55-45" ?>
   3: <?mso-application progid="InfoPath.Document" versionProgid="InfoPath.Document.2"?>
   4: <my:myFields xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:my="http://schemas.microsoft.com/office/infopath/2003/myXSD/2010-04-26T19:55:45" xmlns:xd="http://schemas.microsoft.com/office/infopath/2003" xml:lang="en-us">
   5:   <my:Username>username</my:Username>
   6:   <my:Password>secret</my:Password>
   7:   <my:ConfirmPassword>secret</my:ConfirmPassword>
   8:   <my:EmailAddress>email@address.com</my:EmailAddress>
   9:   <my:Hobbies>
  10:     <my:Hobby>
  11:       <my:Description>Hobby1</my:Description>
  12:     </my:Hobby>
  13:     <my:Hobby>
  14:       <my:Description>Hobby2</my:Description>
  15:     </my:Hobby>
  16:   </my:Hobbies>
  17: </my:myFields>

Notice the two <?mso… XML processing instructions on top? These are what differentiate this form from any odd XML document. That and the namespace definition for the “my” namespace prefix. An interesting thing about the my prefix is the date/time stamp at the end of it. I have had situations where this mismatched in the generated form (because I created the classes from a template different from the one I deployed) and it has been a source of huge headaches. You’ve been warned! Also pay close attention to the value of the href attribute on the <?mso-infoPathSolution> processing instruction. This is the location of the Infopath form’s template as deployed on the SharePoint server. You will probably want to plug this in at runtime depending upon what your site address and form library names are.

There are other namespace prefixes as well, such as xsi and xd that you will need to think about. Finally, there’s the xml:lang attribute that identifies the language for the form. The Infopath designer might add more prefixes if it uses them within the schema so it’s a good idea to have a copy of an empty form handy just to see what you’re generating.

Right, now that we know what we’re generating, lets get cracking on the problem. The first step is to get a handle on the Infopath form’s schema. The quickest way to do this is to open up the form template in Design mode and select the File –> Save As Source Files option. Here’s what it looks like:

image

Choose a folder where you want to save the source files. Be sure to use the same form that you published to the form library. Also be aware that if you are signing the form (perhaps you have some code in your form that you need to run) Infopath will warn you that saving as source files will remove the signature. This is fine because we won’t have to sign the generated forms. You should get a folder full of files like this:

image

The one we’re interested in here is myschema.xsd. This file defines the schema for the Infopath form that we just saw. Next step is to bring up the Visual Studio Command Prompt. Now we’ll use the xsd.exe utility to generate class files for the XML schema definition in myschema.xsd. Change into the directory where myschema.xsd is and use the following command:

xsd.exe /c /l:cs /n:Knowledgecast.TestForm myschema.xsd

The first argument (/c) asks xsd.exe to generate classes and the second one (/l:cs) specifies the language to use. In our case, this is C#. We use the /n argument to specify the namespace under which the classes must be generated. Go ahead and change this to an appropriate value for your solution. Finally, we specify the name of the schema for which classes need to be generated (myschema.xsd). The xsd.exe utility has other arguments that you might find useful depending upon your situation. You can explore the other arguments by using the /? argument. The command execution usually results in a single file (called myschema.cs in our case) containing all the class files necessary to generate an instance of the schema. The class names map to the XML element names so in our case the top-level class would be called myFields.

For the final step, lets build a little console application around our generated classes and actually generate a form. The first thing to do would be to bring in myschema.cs and make it part of the project. Once that is done, writing the code to generate the form is easy. Here’s what the main method of the console application looks like:

   1: static void Main(string[] args)
   2:         {
   3:             myFields form = new myFields
   4:             {
   5:                 Username = "user1",
   6:                 Password = "supersecret",
   7:                 ConfirmPassword = "supersecret",
   8:                 EmailAddress = "dummyaddress@dummysite.com",
   9:                 Hobbies = new Hobby[]
  10:                 {
  11:                     new Hobby
  12:                     {
  13:                         Description = "This is hobby 1"
  14:                     },
  15:                     new Hobby
  16:                     {
  17:                         Description = "This is hobby 2"
  18:                     }
  19:                 }
  20:             };
  21:  
  22:             using (var xmlWriter = new XmlTextWriter(@"C:\Dev\Knowledgecast.TestForm\GenerateTestForm\TestForm.xml", Encoding.UTF8))
  23:             {
  24:                 var serializer = new XmlSerializer(form.GetType());
  25:                 var ns = new XmlSerializerNamespaces();
  26:                 ns.Add("xsi", "http://www.w3.org/2001/XMLSchema-instance");
  27:                 ns.Add("my", "http://schemas.microsoft.com/office/infopath/2003/myXSD/2010-04-26T19:55:45");
  28:                 ns.Add("xd", "http://schemas.microsoft.com/office/infopath/2003");
  29:  
  30:                 var templatePath = "http://mosstest/TestFormLibrary";
  31:                 xmlWriter.WriteProcessingInstruction("mso-infoPathSolution", "solutionVersion=\"1.0.0.4\" productVersion=\"12.0.0\" PIVersion=\"1.0.0.0\" href=\"http://hulmossteam:90/TestFormLibrary/Forms/template.xsn\" name=\"urn:schemas-microsoft-com:office:infopath:TestFormLibrary:-myXSD-2010-04-26T19-55-45\"");
  32:                 xmlWriter.WriteProcessingInstruction("mso-application", "progid=\"InfoPath.Document\" versionProgid=\"InfoPath.Document.2\"");
  33:  
  34:                 serializer.Serialize(xmlWriter, form, ns);
  35:             }
  36:         }

We simply fill out the myFields class with some dummy data and a couple of hobbies. We use an XmlTextWriter because it lets us add the extra processing instructions we need and conveniently lets us put all the XML in a file. Note that your definition for the my namespace and template path will probably end up looking different from mine.

Run the program and and upload the file that was generated to the form library. To test whether the form came out right, open it up by clicking on it in the form library. Here’s what mine looks like:

image

Voila! We’ve just generated an Infopath form using a strongly typed class. One of the things I plan to do on our project is to make the source files part of the project and turn the call to xsd.exe into a pre-build event. That way, any time someone updates the form template all they have to do is update the source files and rebuild. It would be interesting to see how this would work on the build server. But that is a challenge for another day :)

]]> Preloading Content for Your Silverlight Applications and Web Parts https://docs.microsoft.com/archive/blogs/knowledgecast/preloading-content-for-your-silverlight-applications-and-web-parts Thu, 22 Apr 2010 13:56:41 GMT https://blogs.msdn.microsoft.com/knowledgecast/2010/04/22/preloading-content-for-your-silverlight-applications-and-web-parts/ I’ve been studying up on Sharepoint 2010 recently and one of the great things about it is the extensive use of AJAX and Silverlight in the new version. Combine that with the huge improvements in the development environment on Sharepoint 2010 (F5 development, finally!) and you’ve got the potential for some very nice web 2.0ish portals. This is great news for everyone who works on Sharepoint as well as people who work on Silverlight.

With this in mind I started out writing a few Silverlight web parts to familiarize myself with the new Sharepoint client object model. Everything worked great and pretty soon I had a Sharepoint page built entirely of Silverlight applications (hosted in Sharepoint 2010’s built in Silverlight web part) that could talk to each other. Great! Except when the page downloaded all I saw was a bunch of “Loading” messages. Not so great. So what’s so wrong with having a bunch of silverlight apps that pull data down from the server you say? Well nothing, except when people visit my portal I don’t want them wondering whether it’s Silverlight that’s slowing things down for them.

So here’s what we do. We make sure that when the page comes down, it comes down with enough data to let the Silverlight applications display whatever it is they want to display. But how do we get this data into the page? And how do we then pick it up from there and get it into the Silverlight applications? One way would be to use initparams attribute on the Silverlight’s object tag. It works, but it’s messy (all that data in one attribute) and we end up with a long string that we’ll have to interpret on the other (Silverlight) end.

Instead, we’ll use the very useful Silverlight HTML bridge features. First, we write out the data to the page. Here’s a little JsonSerializationHelper class I wrote:

   1: public class JsonSerializationHelper
   2:     {
   3:         public static void SerializeToPage(Page page, List<MenuItem> items)
   4:         {
   5:             DataContractJsonSerializer serializer = new DataContractJsonSerializer(typeof(List<MenuItem>));
   6:             string json = null;
   7:  
   8:             using (MemoryStream stream = new MemoryStream())
   9:             {
  10:                 serializer.WriteObject(stream, items);
  11:                 json = Encoding.Default.GetString(stream.ToArray());
  12:             }
  13:  
  14:             if (page.ClientScript.IsClientScriptBlockRegistered(page.GetType(), "GetMenuItems") == false)
  15:             {
  16:                 StringBuilder sb = new StringBuilder();
  17:                 sb.Append("function GetMenuItems()");
  18:                 sb.Append(Environment.NewLine);
  19:                 sb.Append("{");
  20:                 sb.Append(Environment.NewLine);
  21:                 sb.Append("return ");
  22:                 sb.Append(json);
  23:                 sb.Append(";");
  24:                 sb.Append(Environment.NewLine);
  25:                 sb.Append("}");
  26:  
  27:                 page.ClientScript.RegisterClientScriptBlock(page.GetType(), "GetMenuItems", sb.ToString(), true);
  28:             }
  29:         }
  30:     }

What the JsonSerializationHelper does is take a collection of objects of type MenuItem and spit them out to the ASPX page as a Javascript function. The function in turn returns the collection as a JSON array. The MenuItem class has a couple of members, DisplayText (string) and a Value (string). This of course is a very simple data structure you’ll rarely encounter or use in real life. However, JSON has a very rich syntax that can be used to express complex hierarchical data structures very succinctly. Why use JSON instead of XML or something else? Well there’s nothing stopping us using either, but we do want to keep the size of the page down. Adding a whole bunch of extra angle brackets isn’t going to help. If you want to, go ahead and use the XmlSerializer here.

A quick look at the MenuItem class:

   1:  public class MenuItem
   2:      {
   3:          public string DisplayText { get; set; }
   4:          public string Value { get; set; }
   5:      }

Simple right? Now we go ahead and add some code into the Page_Load method of our ASPX page (the one that hosts the Silverlight object tag) to actually do the serialization. Here’s what our Page_Load method looks like now:

   1:  protected void Page_Load(object sender, EventArgs e)
   2:          {
   3:              var items = GetDummyList();
   4:              JsonSerializationHelper.SerializeToPage(Page, items);
   5:          }

The GetDummyList method just goes ahead and generates a dummy list (surprise surprise!) of menu items that we can feed to our serialization helper. We also pass in the current Page object so that the helper knows where to serialize the Javascript.

So what we’ve got now is an ASPX page with a Javascript function called GetMenuItems. The function returns a JSON array of MenuItem objects that contain the data that we need to display in our Silverlight application. Almost there. For your reference, here’s what the generated Javascript method looks like:

   1:  function GetMenuItems()
   2:  {
   3:  return [
   4:  {"DisplayText":"Menu Item A","Value":"Menu Item A Value"},
   5:  {"DisplayText":"Menu Item B","Value":"Menu Item B Value"},
   6:  {"DisplayText":"Menu Item C","Value":"Menu Item C Value"},
   7:  {"DisplayText":"Menu Item D","Value":"Menu Item D Value"},
   8:  {"DisplayText":"Menu Item E","Value":"Menu Item E Value"}];
   9:  }

The next step is working out a way to pick up data from the GetMenuItems function and deserialize it. Time for another JsonSerializationHelper! Except this one lives in the Silverlight project. Here’s what it looks like:

   1: public class JsonSerializationHelper
   2:     {
   3:         const string JavascriptMethod = "GetMenuItems";
   4:  
   5:         /// <summary>
   6:         /// Deserialize menu items to be shown in the wheel from the current HTML page
   7:         /// </summary>
   8:         /// <returns>A list of wheel menu items</returns>
   9:         public static ObservableCollection<MenuItem> DeserializeFromPage()
  10:         {
  11:             object json = HtmlPage.Window.Invoke(JavascriptMethod, null);
  12:             var list = ((ScriptObject)json).ConvertTo<ObservableCollection<MenuItem>>();
  13:             return list;
  14:         }
  15:     }

Perhaps we should have called it the JsonDeserializationHelper :)

Anywho, the class has just one method called DeserializeFromPage. This method uses the Silverlight HtmlPage class to invoke the GetMenuItems method. Of course, we could make the method even more generic by passing in the name of the function to call but lets leave that for another day. We cast the object returned by the Invoke method to a ScriptObject (because we know that’s what it is) and call the very useful ConvertTo method of the ScriptObject class.

At first, what ConvertTo does might seem like magic, but all it’s really doing is trying to interpret the ScriptObject based on the template parameters we’ve passed in. In this case, we’re telling ConvertTo that we think the JSON object is a collection (hence the ObservableCollection) of MenuItem objects. The ConvertTo method figures out the mapping by looking at the JSON above and gives us a collection of MenuItem objects.

Now you might be wondering how the MenuItem class ended up in the Silverlight project. It is true that we can’t share assemblies between the regular CLR and Silverlight but there’s nothing stopping us sharing the source files. That’s exactly what I did, I right-clicked the Silverlight project and did an Add…Existing Item. Then I went and found the MenuItem class in the web project and just added it as a “link”. That means that while both projects reference it, there is really just one source file. And since the MenuItem class doesn’t use anything that isn’t in the Silverlight class library everything builds just fine. Neat, isn’t it?

image

 

Okay, now we get to the final step, displaying the data we got. For the purpose of this sample, I just put an ItemsControl in my MainPage.xaml. Here’s what it looks like:

   1: <ItemsControl x:Name="lstItems" Background="AntiqueWhite" Width="350">
   2:             <ItemsControl.ItemTemplate>
   3:                 <DataTemplate>
   4:                     <Border BorderThickness="2" BorderBrush="Gray" Margin="5">
   5:                         <Grid Margin="5">
   6:                             <Grid.ColumnDefinitions>
   7:                                 <ColumnDefinition Width="3*" />
   8:                                 <ColumnDefinition Width="2*" />
   9:                             </Grid.ColumnDefinitions>
  10:                             <TextBlock Text="{Binding DisplayText}" FontWeight="Bold" Foreground="Gray" FontSize="25" Grid.Column="0" />
  11:                             <TextBlock Text="{Binding Value}" Grid.Column="1" VerticalAlignment="Bottom" />
  12:                         </Grid>
  13:                     </Border>
  14:                 </DataTemplate>
  15:             </ItemsControl.ItemTemplate>
  16:         </ItemsControl>

It simply displays the DisplayText and Value properties in a grid. Next, I added a Loaded event handler for MainPage and put the code in to load the data:

   1: private void UserControl_Loaded(object sender, RoutedEventArgs e)
   2:         {
   3:             lstItems.ItemsSource = JsonSerializationHelper.DeserializeFromPage();
   4:         }

And that’s it. We’re done! The code for this sample is here:

Go ahead and give it a whirl. Do let me know what you think and if you run into any problems.

]]> Technorati Claim Verification https://docs.microsoft.com/archive/blogs/knowledgecast/technorati-claim-verification Tue, 12 Jan 2010 06:24:02 GMT https://blogs.msdn.microsoft.com/knowledgecast/2010/01/12/technorati-claim-verification/ Sorry about this folks, but Technorati (http://www.technorati.com) wants me to post this code: H5ZVWFJ3E4S8 to verify that this is indeed my blog :)

]]> WPF Starter Kit: Automatic Change Notification on View Models https://docs.microsoft.com/archive/blogs/knowledgecast/wpf-starter-kit-automatic-change-notification-on-view-models Thu, 31 Dec 2009 03:50:00 GMT https://blogs.msdn.microsoft.com/knowledgecast/2009/12/31/wpf-starter-kit-automatic-change-notification-on-view-models/ As a little new year gift to myself, I thought I'd check in a change I've been working on for the WPF Starter Kit for some time now. In a nutshell, the WPF Starter Kit (http://wpfstarterkit.codeplex.com) is a great way to get started building Model View ViewModel (MVVM) based WPF applications. I made an earlier post introducing the WPS Starter Kit here: http://blogs.msdn.com/knowledgecast/archive/2009/11/02/the-wpf-starter-kit.aspx.

If you're like me and writing WPF applications using MVVM you're probably tired of defining all your view model properties like this:

/// <summary>
/// Gets/sets the route state.
/// </summary>
public RouteStatus CurrentRouteStatus
        { 
            get
            {
                return _routeStatus;
            } 
            set
            {
                _routeStatus = value;
                OnPropertyChanged("CurrentRouteStatus");
            }       
        }

Now I’ve used a base class here to eliminate some of the hassles of null-checking and raising the PropertyChanged event but it only gets us so far. One of the coolest features of C# 3.0 was automatic properties which lets you define properties like this:

/// <summary>
/// Gets/sets the route state.
/// </summary>
public RouteStatus CurrentRouteStatus { get; set; }

Unfortunately those of us using WPF (or Silverlight) data binding are hamstrung into using the old way simply because we want change notification support. I’m sure I’m not the only one who thinks that sucks big time. Well, the suckiness is over! View Models in the WPF Starter Kit now support automatic change notification on virtual properties. What this means is that provided you define your properties like this:

/// <summary>
/// Gets/sets the route state.
/// </summary>
public virtual RouteStatus CurrentRouteStatus { get; set; }

setting the property should automatically result in the PropertyChanged event being raised. The only difference here is that our property is virtual. This has no effect on how the property is used or implemented. As long as the class inherits from the WPF Starter Kit’s BaseViewModel (or the infinitely more useful UserInterfaceViewModel) it gets the benefits of automatic change notification.

The magic, in case you’re interested, happens because we use Unity (http://www.codeplex.com/unity) to inject code into the property’s setter at runtime. For more detail on how it works, you might want to explore this excellent blog post by Dmitry Shechtman. While this is not exactly how the WPF Starter Kit works, it did get me pointed in the right direction on this. I also plan to make a blog post later explaining exactly how the interception code works.

In the meantime, enjoy this new feature and the cleaner code it gets you. Happy New Year!

]]> The WPF Starter Kit https://docs.microsoft.com/archive/blogs/knowledgecast/the-wpf-starter-kit Mon, 02 Nov 2009 08:23:00 GMT https://blogs.msdn.microsoft.com/knowledgecast/2009/11/02/the-wpf-starter-kit/ Disclaimer: It has come to my attention that there is some confusion in the community regarding the "official status" of the WPF Starter Kit. I wanted to make it clear that this toolkit has come out of my and my team's efforts on a recent project and is by no means the endorsed (by Microsoft) or only way of implementing the features outlines below. The p&p team's Composite WPF and Silverlight guidance (http://compositewpf.codeplex.com/) and the WPF codeplex site (http://wpf.codeplex.com) are the official sources of guidance. Another source of inspiration to me has been the people and articles of http://wpfdisciples.wordpress.com/. There are a bunch of community-created MVVM toolkits out there, and most are as valid as this one.

If you're looking to get straight to the code, go here: http://wpfstarterkit.codeplex.com/ 

I have been working on a WPF project the last few months. We've managed to accomplish something pretty incredible by putting a WPF application at the center of a hostile environment (a train engine) paired with a ruggedized tablet. The tablet itself ships with Windows XP Tablet Edition (talk about being behind the times!) but the great thing about WPF as a platform is that this didn't matter so much. We were still able to build our application and deploy it on the tablet as well as on Windows 7 desktops with only minor issues (most of them to do with the graphic drivers on different video hardware).

When I started out with this application I really wanted to use the Model View View Model pattern. Not only because MVVM is the hot new pattern (which it admittedly is) but also because I think MVVM is what MVC always wanted to be. Of course, WPF's brilliant data binding and commanding support only helps. We did evaluate what was then known as Prism (http://compositewpf.codeplex.com/) but found it a little too complicated for a project this size (the application only has about 30 views). Another thing that didn't fit was the large learning curve. Most of the people on the project, while quite well versed with managed code, were new to the WPF way of doing things.

That was when I made the decision to build a up a barebones, simple MVVM/Navigation/Commanding framework that would be easy to pick up in a single afternoon. While it does not have the modularity, complexity or extensibility of Prism, it worked very well for our application. Here's what the WPF Starter Kit supports:
A simple, easy to use implementation of the Model View View Model pattern

  • A navigation framework that allows for clean navigation between View/ViewModel units. This framework is based on built-in WPF navigation
  • Support for passing data between View Models
  • Support for generic exception handling
  • Support for long running operations on the UI thread

The source code for the project is here: http://wpfstarterkit.codeplex.com/. Feel free to log bugs if you find something not working. There's also a presentation that should make it easy to get started using the kit: http://wpfstarterkit.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=35301#DownloadId=90586. Finally, there is a sample project in the solution that shows off each of the features mentioned above. I'll try and make separate posts covering each of these features and tasks you'd normally need to perform while writing a functional multi-view application with the WPF Starter Kit.

Have fun!

]]> Windows Mobile 6.5 Emulator Available https://docs.microsoft.com/archive/blogs/knowledgecast/windows-mobile-6-5-emulator-available Fri, 05 Jun 2009 16:04:16 GMT https://blogs.msdn.microsoft.com/knowledgecast/2009/06/05/windows-mobile-6-5-emulator-available/ The developer kit for Windows Mobile 6.5 (including documentation) is now up here: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=20686a1d-97a8-4f80-bc6a-ae010e085a6e. You might remember me talking about this at the Tech Ed session last month.

Also included are some samples on the new Gesture APIs. WM 6.5 also supports a new programming model called Widgets (lightweight script applications that run inside an instance of IE6). And yes, WM6.5 does come with Internet Explorer 6. Finally! :)

]]> MOSS: Using the List Web Service to Rename a File https://docs.microsoft.com/archive/blogs/knowledgecast/moss-using-the-list-web-service-to-rename-a-file Wed, 20 May 2009 04:12:22 GMT https://blogs.msdn.microsoft.com/knowledgecast/2009/05/20/moss-using-the-list-web-service-to-rename-a-file/ Right, so I ran into an interesting problem recently. I needed to rename a bunch of files in a document library we have on our team’s MOSS site. Problem is, this is a lot of documents. So I figured I’d use MOSS’s web services to do it.

Now in MOSS, a document library is just a specialized list of items (the items just happen to be files). So the web service that I need to use is the MOSS Lists web service (http://msdn.microsoft.com/en-us/library/lists.aspx). Turns out, doing this with the MOSS Lists web service isn’t quite as trivial as I thought it would be (it never is :D).

So here it is, a super simple WPF application that lets you see Document Libraries in a MOSS site and then rename files within a selected document library:

The meat of the logic is in the btnRename_Click handler. I use the user inputs to build up a batch element that tells the UpdateListItems method what to do. More information about the Batch element here: http://msdn.microsoft.com/en-us/library/ms437562.aspx.

The interesting thing about using the Batch element is that not only can you process a whole bunch of files, but you can do different operations on each one of them. What’s more, the OnError flag lets you specify what happens if one of the operations in the Batch runs into an error.

]]> Building Great Looking Mobile Applications https://docs.microsoft.com/archive/blogs/knowledgecast/building-great-looking-mobile-applications Fri, 15 May 2009 00:43:21 GMT https://blogs.msdn.microsoft.com/knowledgecast/2009/05/15/building-great-looking-mobile-applications/ Today at Tech Ed I’ll be trying out something interesting. Instead of speaking on a particular technology area, I’ll be talking about building great looking applications for Windows Mobile. I won’t bother doing a full blown post about this because most of what I will talk about is covered by Alex here: http://msdn.microsoft.com/en-us/library/dd630622.aspx.

In case you were an attendee (I am writing this just before the session) and want access to the Powerpoint deck and demos I’ve got it all packaged up and loaded on my SkyDrive (link below). I realize that some of you will want to re-present this session to an internal audience, so I’ve added demo scripts (word documents) to the demos with talking points and steps of the demo. Do get in touch with me and let me know what you thought of the session.

I’ve also got a mesh folder where I’ll be updating this material. If you want access to that, leave a comment, email me (arunjeet.singh at hotmail.com) or tweet me (@arunjeetsingh).

Right, now I’ve got to go pour some coffee down my throat to put those butterflies in my stomach to rest. Cya at Tech Ed!

]]>