This week I ran into a WPF data binding problem and spent about a day trying to figure out why it wasn’t working.  A day is a long time to spend on why a “Text” property is not binding to an object’s property which is of the type “String”.  Here’s some quick tips on identifying the source of the data binding problem.

1)  Ensure Data Binding Debugging Information shows in Visual Studio’s Output window.  Visual Studio has the capability of showing verbose data binding trace information.  This can help you get to the bottom of the issue quickly.  In my case, my output window was not showing any data binding information…  You’ll need to adjust some Visual Studio debugging options.  First, ensure that all debugging information is not being sent to the immediate window.  Tools >> Options >> Debugging >> “Redirect all Output Window text to the Immediate Window”.  Uncheck that.  Next, Tools >> Options >> Debugging >> Output Window >> WPF Trace Settings >> Data Binding.  Select an option here.  When I was debugging I wanted to see everything going on so I selected “Verbose”.  Unfortunately, the information did not tell my anything as to why my two-way binding was not updating the underlying object’s property…

2)  Understand Dependency Properties and the INotifyPropertyChanged interface.  In order for the UI to properly show object property changes or to perform two-way binding, the property which it binds to needs to be a dependency property or the object needs to implement the INotifyPropertyChanged interface so that the UI properly reflects the object’s property changes and the UI can also update the object’s properties (if two-way binding is enabled).  In my case, my UI control was bound to a dependency property which its type also implemented INotifyPropertyChanged and my two-way binding still didn’t work…

3)  Are you using a Converter in the data binding expression?  Sometimes converters can throw exceptions and break the binding.  Put breakpoints in your converter and ensure the conversions are not throwing exceptions and breakpoints are being hit.  In my case, the convert from was being hit, but the convert back (updating the object from the UI via two-way data binding) was not being hit.  So one-way was working, but two-way was not…

4)  Are you binding a Custom Control which overrides/overloads the property which you are wanting to bind to?  This was the problem for me.  I was wanting to two-way bind the “Text” property of a custom user control to my object’s property.  The custom control was inheriting from TextBox and they were overloading the “Text” property.  Apparently this broke the two-way data binding.  I figured it out by simply dropping a vanilla TextBox onto my UI and binding it’s “Text” property to my expression and two-way binding worked great.  So, when things get really hairy, simplify what you are doing and add more and more things back into the picture until something breaks.  Troubleshooting 101 for the win.

By default, if the programmer does not specify the DateTime kind, .NET WCF services will serialize and deserialize DateTime objects based on the local time zone.  What this means is that if you have a client entering information on the east coast (EST) and your server is in central time (CST), the DateTime values entered by the client will have their hour decremented by 1 when the data is deserialized at the server.

The reason why WCF behaves this way is because it thinks that the DateTime entered on the client is in local time.  As a result, when the value reaches the server, 11:00 AM client local time is converted to 10:00 AM because that is what the local time is on the server.

If this is not what is desired, specifying the kind of the DateTime value appears to alter the serialization/deserialization behavior.  Specifying what kind of date your value is will not alter the underlying value.

Unspecified - No conversion:  returnValue = DateTime.SpecifyKind(value, DateTimeKind.Unspecified)
Local - Time Zone conversions:  returnValue = DateTime.SpecifyKind(value, DateTimeKind.Local) 
UTC – No conversions:  returnValue = DateTime.SpecifyKind(value, DateTimeKind.Utc)

On Thursday 4/15/2010, Microsoft officially released the final version Silverlight 4.  Scott Guthrie gave a 60 minute keynote on Silverlight 4 a few days prior.  If you haven’t watched the keynote, I’d recommend doing so.  I was impressed with the new features and the demos provided.  Silverlight 4 includes a ton of new features. 

Here is a quick list of some of the new features that I found interesting:

• Tooling – Multi-Targeting Silverlight 3 and 4.  You can also now design within VS 2010.
• Printing API – You can now print from Silverlight.
• Right-Click Event Handling – MouseRightButtonUp/Down events are now available.
• Webcam & Microphone Access – SL can now use the client’s webcam(s) and microphone(s).
• Mouse Wheel Support – The mouse wheel event was added in SL 3, but now TextBox, ComboBox, Calendar, DatePicker, and the ScrollViewer auto-scroll.  You no longer have to manually handle the event.
• RichTextArea Control – Provides an area where users can create and edit text and specify bold/italic/underlined/etc text.
• Google Chrome Support - M$ finally now supports Google Chrome.
• Implicit Theming – Create a style for a targeted type and all of those types will implicitly use it.
• Fluid UI Support in the ItemsControl – 3 new states: BeforeLoaded, Loaded, and Unloaded.
• DataGrid Enhancements – Column relative width sizing refactored.
• DataBinding Enhancements – Binding can now use StringFormat, TargetNullValue, FallbackValue (e.g. Dates no longer requires ValueConverters to format the date).
• IDataErrorInfo – When this interface is implemented, it reports data validation errors that a UI can bind to.  Only one property is validated/reported on at a time.
• INotifyDataErrorInfo – Allows developers to provide custom validation logic server-side via asynchronous routines.  Here is a video on the new data validation features.
• Silverlight Drop Target – Drag and drop folders/files into your Silverlight application.
• ViewBox – New control which is used to simplify the resizing of images.
• Text Trimming – Auto adding of word ellipse (…)
• Keyboard Access in Full Screen Mode – If SL is in full screen mode – all keyboard input is accepted in Silverlight as long as the application is trusted.
• Network Authentication – You can now pass separate credentials when connecting with 3rd party service providers.
• COM Interop – Silverlight can now create COM objects – however this only applies to trusted SL applications.
• Notification (“Toast”) API – Notifications (like a new Outlook email as arrived) can now be used.
• Local File Access – SL can now access the user’s “My” folders (e.g. My Documents, etc).  This requires trusted SL application.
• Elevated Trust Applications – Many new features in SL4 require elevated trust.  This new feature will prompt the user to allow/fully trust the SL application when installed.
• HTML Hosting with WebBrowser – You can now show and host HTML within your SL application.
• Clipboard API – SL now has access to copy to and paste from the clipboard.

Fiddler is the tool of choice when it comes to inspecting WCF messages that utilize an HTTP transport.  In a previous post I mentioned that HTTP WCF messages should be in encoded in a binary format to decrease their size.  The problem you run into when encoding your WCF messages is that when Fiddler attempts to inspect an encoded message, it’s not in a readable format.  To resolve this limitation, you can download a free plug-in which will add an inspector to Fiddler to decode binary WCF message.  Using this new inspector, you can inspect binary encoded WCF messages freely from within Fiddler.

http://code.msdn.microsoft.com/wcfbinaryinspector

Silverlight 3 offers us some new features when it comes to WCF web services.  In Silverlight 2, BasicHttpBinding was the only supported binding.  This essentially encodes your serialized objects in clear text and sends them over an HTTP transport.  Because the objects were sent as clear text, the message size could get out-of-hand.  When sending data across HTTP/Internet, you obviously want to decrease the size as this will improve performance of your client application.  Silverlight 3 offers the ability to create custom bindings which support the ability to encode your WCF web service messages as a binary format.

Binary encoding offers some serious performance gains over text encoding.  Personally I’ve seen 30% – 40% reduction in message size between the server and client when binary encoding is enabled.  Keep in mind that binary encoding is a WCF-specific feature.  Therefore if you have heterogeneous technologies wanting to consume your service, you’ll need to stick with BasicHttpBinding.  Here is an example of how to enable binary encoding for your WCF service:

<bindings>
	<customBinding>
		<binding name="binaryHttpBinding">
			<binaryMessageEncoding />
			<httpTransport />
		</binding>
	</customBinding>
</bindings>
   
<endpoint address="" binding="customBinding" bindingConfiguration="binaryHttpBinding" contract="MyService" />