Monday, November 24, 2014

Detecting Binding Errors in WPF

The binding engine in WPF is magical.  It makes possible the separation of the view from the view logic.  The MVVM pattern is dependent on this magical binding engine.  One not so great aspect of this is that binding errors fail silently in WPF.  There are several ways ways to get binding errors. For example, changing a property name and forgetting to update the Xaml binding expression.

WPF does log these data-binding errors to the output window.  The issue with that is it can sometimes be hard to find them amid all the other stuff being output by the debugger.  If you do manage to find one, it will look something like this....

System.Windows.Data Error: 4 : Cannot find source for binding with reference 'ElementName=DiamSlider'. BindingExpression:Path=Value; DataItem=null; target element is 'Slider' (Name='PipeDiamSlider'); target property is 'ToolTip' (type 'Object')

Another method for finding these errors is using a tool like Snoop or WPF Inspector. This works but it's tedious.

Recently I ran across a great simple solution to this issue.  Behind the scenes WPF is writing out errors to the PresentationTraceSources class.  This means that a simple trace listener can be created to show the output of the binding errors in a message box.  This trace listener is registered in the applications main window .xaml.cs.  This is a very simple idea, but it has been incredibly helpful in ridding our application of binding errors.

I discovered this method on tech.pro in an article written by Michael Kuehl. Bea Stollnitz also has a great blog post that digs deeper into methods of detecting binding errors.

Friday, November 21, 2014

Helix 3D Toolkit - Well Viewer Part 2

In September I wrote a post about creating a well profile viewer using Helix Toolkit.  At work the requirements were extended to include showing a tube representing the work-string inside the well-bore.  Additionally, the ability to show a color gradient denoting a set of values was also needed. I've re-factored the original code in my first post and update the Gist.

Our torque and drag model generates a list of calculated values at a regular interval of depth. These values are then mapped to the work-string inside the well-bore.  There are two interesting issues here.

The work-string is confined by the well profile in real-life, and similarly when modeling this issue our work-string path will follow the path of our well.  To code the new requirements, the base class created in the first post will be extended, and the reliance on the well profile path, will introduce temporal coupling in code.

The other interesting thing to note is that we don't have a one to one relationship with values coming from the torque and drag model being mapped to 3D points.  It might take 100 or 200 points to represent the 3D center-line of the well-bore, while the torque and drag model can return several thousand data points.   To get around this issue, the data needs to be interpolated by depth at each 3D point along the profile.

Overview of Mapping Values as Texture Coordinates in Helix Toolkit
Helix toolkit uses the concept of texture mapping to apply a skin over the 3D objects.  The concepts are explained in detail on Wikipedia.  For what we are doing the concepts can be simplified to this, the texture coordinate will determine which value from a linear brush will be applied to the geometry.  Values on a linear gradient brush range from 0 to 1, so the values being mapped will also need to be normalized into this range.    Once we have a list of texture coordinates, one for each 3D point, we can simply bind to them from our pipe in Xaml.


Here is the code.
It was requested that I provide a working example, I've placed somewhat simplified project in OneDrive that will help you get up and running.

Monday, November 17, 2014

Why I Attend a .Net User Group

When I started programming, I wished I had another avenue to meet and connect with those that shared a like passion for code.  Frankly, it's fairly difficult to strike up a conversation with most people about coding.  If you work for a large organization you may have plenty of workmates to chat with, however, many programmers are working alone for small organizations.  

User groups provide a great way to meet other passionate developers in the local community.  The act of attending a user group can mark you as a developer that has drive and passion.  When I moved to the Houston area, I joined the NHDNUG  (North Houston .Net User Group) and quickly started to reap the benefits of information I received at the monthly meetings.  One speaker talked about Software Craftsmanship and the tools of the trade causing me rethink how I approached programming.  That talk also led me to NCrunch - a tool that I can hardly imagine not having.  

I've since become a board member at our local user group. My role has been small but I still enjoy the participation. My wife refers to our meetings as "Nerds Anonymous" :)  If you've got a programming addiction, its time to find a user group near you.

Saturday, November 8, 2014

Prism - Custom PopupWindowAction

One of the nice features in the Prism is the interaction request pattern supported by the InteractionRequest class. I'll quickly provide a brief overview here. In your view model, you can define properties of type InteractionRequest<INotification> and InteractionRequest<IConfirmation>. In your view you bind to a blend interaction trigger with an action of type PopupWindowAction. Manipulating the InteractionRequest from the view model will trigger the PopupWindowAction, showing you pop-up window. This is a neat way to show dialogs while still adhering to the MVVM pattern for testability.

If you do not set the WindowContent property of the PopupWindowAction class, then the DefaultConfirmationWindow or DefaultNotificationWindow will be displayed. These windows are very basic. In fact, they don't have text wrapping. In my application, I mainly use them to display messages to the user. Without text wrapping, messages shown in the DefaultNotifiactionWindow were truncated.

The WindowContent property can be used to show custom content declared in a user control. Here is a custom user control where I've defined a TextBlock with text wrapping. Note that in the .xaml.cs of the user control, I implement the IInteractionRequestAware interface. This will provide the FinishAction and Notification properties, which the control will use.
Often, I favor having a window factor for more complex windows, however, for simple dialog's and interactions this works very well.