I cannot count how many times people have requested the source code to the ATAPI.NET or ITAPI3 projects.  My response has always been that I was unable to release it due to ownership issues (it was developed under contract for a client).  I am pleased to announce this morning that I have worked through those issues and have been granted permission to release the project in it’s entirety as source code on CodePlex!

Here’s their new homes:  http://atapi.codeplex.com/ and http://itapi3.codeplex.com

I’ll open up discussion board access there as well for Q&A.  If you would like to contribute to the project, shoot me an email and we’ll see about getting you access!

In the last post, I referred to the DragPositionBehavior in the JulMar MVVM library.  This behavior allows any UIElement to be dragged and repositioned using the mouse without requiring any code logic on your part.  It’s easy to apply – using the traditional Blend syntax (easiest done by dragging the behavior onto an element):

This is the simplest way to use this, however it doesn’t work when the behavior is to be applied with a Style – in my example in the prior post, we need to drag around the ListBoxItem container, not just the content.  So I showed an alternative syntax to apply the same behavior:

Here, the behavior is being applied by setting the IsEnabled attached property onto the ListBoxItem.  Here’s the implementation for that:

This is a boilerplate example of an attached property – nothing to see here.  The magic happens in the PropertyChange callback:

Let’s break this down a little.  When we have the IsEnabled property set onto an element, first we verify it’s a UIElement (we cannot drag it on anything that isn’t because the mouse events are defined at this level).  Next, we check the behaviors collection on that element – if an existing behavior is there and we are setting the property to “false”, then we remove the existing behavior from the collection.  If there is no behavior, and we are setting the property to “true”, then we add a new DragPositionBehavior instance to the collection here.  This, in effect, is exactly what the first block of XAML is doing, and it’s what we do as well here in code – so the Style setter works as expected.

This isn’t really a trick – I’m sure others have thought of it as well, but it’s a useful thing to add into your behaviors so they can be universally used, both by Blend as well as by developers directly wanting to apply it in places where Blend cannot today.

In this post, we will look at the IUIVisualizer, and bring together some of the concepts we’ve talked about already through a new sample – a simple picture viewer:

The application grabs all the images from the user’s photo folder and then displays each one onto the surface of a corkboard.  You can change the properties of an image, remove an image or add additional images.  It’s not designed to be a true image application ala photoSuru, it’s really more of a sample of MVVM practices with the helper library.  Here’s some of the coding examples present in the sample:

• It registers a ISelectFile service and implements it as an OpenFileDialog.
• It displays a “Picture Properties” dialog using the IUIVisualizer service.
• It maps mouse DoubleClick on an image into a command in the ViewModel to display the properties.
• It provides drag support through a behavior on the style.

Let’s look at this four features in particular.  Download the sample from here:

PictureViewer

Open the project in Visual Studio 2008 SP1, it should build and run without any issues.  The project structure is pretty much like all the other samples I’ve blogged about – I’m trying to keep to a consistent model:

Service Registration

If you look at the App.xaml.cs code behind, you’ll find the registration work being done in the constructor:

First, note that it registers the standard services – that’s something I always do, even if I don’t anticipate needing them all, it doesn’t hurt to have them there. Next, it adds the file selector service by calling ServiceProvider.Add on the ViewModel class.  The interface is defined as a single method:

The registration ties this interface to an implementation that displays the OpenFileDialog, for testing purposes, that would be replaced with a minimum of two implementations: one that returns null/empty and one that returns a valid filename to test both cases.

The final line in the app.xaml.cs file registers a UI dialog to display the properties of the image.  This is done through the IUIVisualizer interface which is defined in the helper library:

Notice the Register and Unregister methods take a string defined as a “key”.  This is the key that invokers will use to display the UI visually; I often use the typename of the View, but you can use any string here as long as you are consistent in registration vs. invocation.  In this sample, I’ve used the key “ShowElementProperties” – we’ll see in a moment how it is displayed.  The second parameter for the Register method takes the Type to display.  The type must be a WPF Window-derived type (i.e. NavigationWindow or Window) and will represent the View in our MVVM pattern.

Displaying a UI with IUIVisualizer

In the PictureViewModel type, there is an ICommand that is used to drive the Property window:

The default constructor fills that in with a DelegatingCommand to jump to a method of the ViewModel:

The handler method is marked as internal because the MainViewModel forwards it’s own command to this same method handler (from the menu and toolbar).  Notice that the method first gets the IUIVisualizer service; you must use the same service instance where you registered the UI view.  Next, it calls ShowDialog to display a modal view.  It takes two parameters – the view key, and the view model.

A modal view is one that forces the user to interact and dismiss the dialog before they can continue working with the other elements in the application.  It is what, as an example, applications often use for Options dialogs.  ShowDialog will display the View associated with the given string key (“ShowElementProperties”).  The second parameter is the ViewModel you want to associate to it – in this case we are passing the associated picture we want to work with.  The dialog is then displayed and allows the user to edit the picture properties:

The XAML code for this view is contained in the PropertyWindow.xaml file – it has a couple of interesting elements to it which you will see when you interact with this dialog:

1. Watermarked Text display: if you remove the title, it will display some grayed out text in it’s place “Enter the Title Here”:

2. Numeric TextBox:  if you move your mouse cursor over the X/Y/Width/Height boxes you will see a sizing arrow that allows you to drag and change the values without typing.  You can also double-click to change the values and it enforces numeric text box behavior.

Both of these are accomplished with Blend Behaviors. There are plenty of resources on the web about these so I won’t go into detail on their creation – check the library source code if you want to see how they work, but using them involves taking a dependency on two assemblies:

1. System.Windows.Interactivity.dll
2. JulMar.Wpf.Behaviors.dll

Both of these are included in the Dependencies folder.  The first comes from the Blend SDK and is freely redistributable with your project.  To use them, you add the behavior to the visual element in question, for example, the watermarked textbox behavior gets applied like this:

I’ve also applied a Trigger to change the font/colors when the TextBox is watermarked.

The numeric behavior looks like this:

Notice that I’ve changed the Binding.UpdateSourceTrigger to be PropertyChanged – this is so the dragging effect works properly and updates the value in the underlying view model.

Ways to invoke commands in the view

So let’s look now at how we get the command executed.  Switching to the MainWindow.xaml you will find three places where the Show Properties command is wired up.

First, it can be invoked using a keyboard accelerator. This requires using a BindableCommand from the library, placing it into resources and then binding against that.  The command we will be executing is the one on the MainViewModel so it requires the actual picture element as a parameter:

The MainViewModel simply forwards this command onto the PictureViewModel using a typed DelegatingCommand:

Next, we can invoke the command using the menu and toolbar:

Note that here we are also binding to the MainViewModel command – so we must supply the parameter using the CommandParameter.  The final invocation place is when you double-click on the picture itself.  This is done a little differently if you’ve not done much WPF work. 

A quick segway – View code behind vs. View Models

First, the display of images is actually housed in a ListBox.  It turns out that anytime you need to display multiple things grouped somehow, and allow the user to select one or more of those things, a ListBox is almost always the way to go.  WPF allows us to customize the visuals however we like, so here the panel has been replaced with a Canvas (allowing pixel positioning), and each item is drawn as a DataTemplate.  The template decides how to render each item in the ListBox – the PictureViewModel in this case.  In the sample, it is rendering an image and an optional TextBlock that is turned on and off through a property (and can be changed through the tool bar).  I encourage you to look at the code to see how all that is done. 

One of the core things necessary in MVVM is the ability to interact with visuals and then sometimes push notifications of that interaction back to the view model.  I say “sometimes” because it’s perfectly acceptable to place code into the code behind for the XAML as well. Where you put the logic depends on whether it is view-specific and whether you want to test it independently of the view.  If it’s not view specific OR you want to test it, then move it into the view model.  An example of something that we probably don’t care about is closing the application – I’ve wired it up to a command here just to show that you can, but it’s completely unnecessary to do that.  The view model isn’t doing any closing logic, so it would be fine to wire a handler into the MainWindow.xaml.cs and just call “this.Close()” in there.

Ok, so back to the double-click implementation.  In the DataTemplate assigned to the ListBox.ItemTemplate property you will find the definition for the image itself:

Note the use of the Interaction.Triggers tag – this is also part of the Blend behavior implementation.  In this case, we are triggering off something (property change, event, etc.) and then performance some action.  In the JulMar.Wpf.Behaviors assembly you will find a whole bunch of triggers, behaviors and actions.  In this case, I am using the DoubleClickTrigger which monitors for a quick double tap of the left mouse button.  When that happens, it runs the list of actions associated with it – in this case, it invokes the ShowPropertiesCommand.  Now, here we are defining the trigger behavior on the UI that is bound to an actual PictureViewModel (note the property bindings on the image and you will see that I’m telling you the truth!) So here the command being invoked is the PictureViewModel command – so no parameter is necessary.

Drag/Position Behavior

The last thing I want to point out is the dragging behavior.  This is also done through a Blend behavior, but it is being applied in a slightly different way: through a Style. 

...

Now, for those who have used Blend behaviors a lot, you may now that it is currently not possible to apply behaviors through Styles.  This is a restriction of the Attached Property definition being used – the collection cannot be associated on a style.  This is a very unfortunate problem because it makes my scenario very hard: I want to drag and reposition these items around through the mouse.  If I put the behavior onto the DataTemplate then I move the content but not the item container itself (the thing that provides selection and focus rendering)  So I would end up with a very weird visualization where you click on an item and the focus rectangle is drawn in a completely different place than the item itself!

So, in my set of behaviors, many of them allow you to setup the behavior both through Blend and through Style setters (or directly on an element without the full Blend syntax).  I do this by adding an attached property onto the behavior class and then injecting my behavior into the element where the attached property is set.  I’ll show this in a future blog post to give an example for those who’d like to do the same for their own behaviors.

Another question I’ve fielded is why did I even create this behavior at all when the Blend sample already exists to do this?  Well, the short answer is because I had a specific goal in mind here – this behavior knows about Canvas panels.  If the behavior is attached to an element in a Canvas, it changes the position by changing the Canvas.Left and Canvas.Top properties.  If not, it uses a RenderTransform.  The supplied blend sample only uses RenderTransform(at least when I last looked at it).

That about covers it, if you have any questions or comments, then contact me!

In this post, I will go over the simple message visualizers available in the MVVM Helpers toolkit.  Essentially the idea is that it is fairly common to want to display a simple message from the ViewModel to the user.  Since the VM is supposed to be testable, we encapsulate this ability into four services, three of which I’ll focus on here:

To demonstrate the first three visualizer types, we’ll build a very simple MVVM application to display messages.  I start with the project template and remove all the ViewModel and View code to have a blank solution.  Each of the three visualizers we are going to look at take a string Title and Message as their parameters – we’ll drive it from a unique command for each.  To start with, let’s define a simple data structure that wraps an ICommand and a textual title:

Next, in the MainViewModel.cs file, we need a Title string property – this will be the title for each of the visualziations.  It’s just a simple field-backed INPC property, we’ll bind it to something in the view:

Now we can create a collection of the TitledCommand objects and display them to the user for execution.  We will place this collection into the MainViewModel.cs.  Let’s populate it with a set of delegating commands for each type of visualization we want to create.  We will use the DelegatingCommand<T> version which allows us to type the parameter being passed.  We will assume the inbound parameter is always the message to display and there a string:

The CanExecute handler for each of them will test the Title property – ensure there is a value there, and the inbound parameter (the Message) and make sure there is a value there as well.

IMessageVisualizer

The IMessageVisualizer is used to show a simple message to the user – it takes a title, message and an enumeration to decide which buttons to display.  The default implementation of the service displays a MessageBox.  

The buttons you can display include:

The result from the service is which button was used to dismiss the dialog:

Using the visualizer is very easy – request the service from the service locator using the Resolve method (this requires you derive from the JulMar.Windows.Mvvm.ViewModel base class, or hit the service locator using the static property):

Notice that I test to ensure the visualizer is available – remember that services can be replaced or removed – I might do this in my unit tests for example (I actually mock the interface rather than replace it, but you get the point – test to make sure it’s there).

We want to see the result, so I take the resulting enum and convert it to a string and assign it to a new Result property on the ViewModel.  This, like Title, is just a field-backed string that does a property change notification.

IErrorVisualizer

The error visualizer is for cases where you want to display an error dialog to the user with a title and message.  The default implementation displays a MessageBox with an OK button

It returns a boolean response indicating that the user clicked the OK button (versus dismissing using the Close “X” button).   It has a similar interface to the message visualizer:

We will assign the boolean result to the string Result property as well.

INotificationVisualizer

This visualizer is for cases where you are doing something in the ViewModel logic, on the UI thread that takes a moment to process.  Sorting a list, or searching an in-memory list might be an example.  True long-running operations should always be on a separate thread and use properties or the message mediator to coordinate with the UI thread.  That said, there are times when you want to do the logic inline with the request and you know it’s going to take a second or two to process it.  Enter the INotificationVisualizer.  It takes the same title and message as it’s cousin visualizers but the default implementation does not use them – instead, the default implementation simply changes the cursor to an hourglass (the defacto standard for “please wait”).  This is a service that I often replace with a custom visualzation – a progress bar, thumbar progress on Windows 7, or even a dialog overlay.  Invoking it is simple:

The BeginWait() method kicks off the notification visual (hourglass cursor in this case).  It returns a disposable object that you invoke Dispose on to return to the normal cursor.  Again, let me stress this is not optimal for a true long-running operation – this locks the UI up until the thread returns so only use this for very short operations.

Creating the View

The View for this application will be simple – let’s use an ItemsControl to generate a button for each of the exposed commands, two TextBoxes to hold the Title and Message, and then a TextBlock for the result, here’s what I want it to look like:

I’ll let you go through the XAML – it’s straightforward and should be pretty easy to follow.  The only new thing might be that we’ll set focus to the first focusable element using the FirstFocusedElement markup extension:

That should do it – if you’d like to just download the project and play with it, it’s available here: VisualizerTest.zip.  In the next post we’ll take a look at the grand-daddy of the message visualizers in the MVVM Helper toolkit: the IUIVisualizer!

The main project I’ve been working on the past few months has been a rRNA sequencing application.  It’s a joint project involving Microsoft Research and the University of Texas in Austin.  The goal being to produce lightning fast visualizations (nucleotide, 2D and 3D) with very large (100,000 sequence) data sets on WPF.  It’s been a big learning experience for me in many ways because the traditional mechanisms for dealing with things in WPF just flat out fail when we load big datasets and start scrolling them around.  So, we’ve had to invent data virtualization schemes, our own UI virtualization for scrolling, several custom controls and a variety of other elements to pull it off so far.  rCAT 4.0 (coming in March) is even more ambitious with editing support for the sequences!

All that said, our current effort is now online with full source code – it’s interesting stuff to browse through even if you aren’t into molecular biology – check it out at http://rcat.codeplex.com/

Here’s a nice screen shot showing some of the elements – dockable tabs and sidebar items, birds-eye viewer, taxonomy viewer and custom colorization of nucelotide data.  And it, of course, is all MVVM.  Fun stuff!

With that in place you should be able to fire up Visual Studio 2008 and create a sample MVVM project:

Let it generate a project and the build it -- running the program will give you a simple file explorer using the MVVM design pattern and WPF:

In tomorrow's post, we'll break the sample down and see how I built it. See you then!

With this post I am starting a new series - I hope to be more consistent in posting at least once or twice a week. To that end, I am going to focus on the WPF/MVVM helper library I use daily. I released an earlier version of it onto the web and have gotten a lot of comments which has been great, so I am releasing the latest version which has a lot of changes. So, without further ado, here's the code for you to download and play with, this compiles with Visual Studio 2008 SP1, or with Visual Studio 2010 Beta 2.

mvvmhelpers.zip

Read on for the basics of the project structure and files.

Project Structure

Building and Usage There are pre-built assemblies included in the distribution, but you are free to build the source on your own - I don't include the certificate file (so I can tell versions that I have built) but you are free to delete the certificate from the solution or replace it with your own and build your own binaries from the source code. Or you can take any of the source code, modify it however you like and add it directly to your project. Credits As with most projects, this library has benefited significantly from the community. The WPF Disciples list on has been a particular source for ideas and even source code. There are some source files in the project that I did not author, or where I took a bit of code and modified it to suit my purposes. I have tried to make sure people get credit where appropriate in the source code itself, if I missed anyone I am truly sorry. Documentation As I mentioned earlier, my goal is to produce a set of blog posts that detail how to use the library, but there is also some documentation on each class included in the distribution in the form of a .CHM (Windows Help File). I encourage anyone who wants to use this library to check that out.

I just put the latest version of the MVVM helpers online - mvvmhelpers.zip

There's a bunch of new stuff in it - check the release notes for the highlights.  There's a set of breaking changes in it as well, specifically I've moved several of the attached behaviors into the new Blend model.  Originally in my local version I did it to the JulMar.Wpf.Helpers.dll and got a dependency against System.Windows.Interactivity.dll.

I decided that for this release I didn't want to force that dependency so I created a secondary assembly JulMar.Wpf.Behaviors.dll which has all those behaviors in it.  The breaking change is I removed the original attached behaviors from the library (DoubleClickBehavior, NumericTextBehavior, MouseDragBehavior) in favor of using these new versions.  I did update the sample to show how they get used.

In a recent Essential WPF class, one of the students wanted an ObservableDictionary which we whipped up there - I cleaned up that implementation somewhat and added it into this library along with some unit tests for it.

Again, please check the readme included in the .zip file -- as always you are free to do whatever you like with this code.  If you do anything interesting or fun, let me know!

A recent series of blog entries at http://themechanicalbride.blogspot.com/ introduced the Rx framework (System.Reactive.dll) which is an assembly used in the Silverlight toolkit for UI testing purposes.  It essentially provides a mechanism to do event driven programming through LINQ.  I'll refer you to the blog referenced above for all the gory details - frankly I'm still trying to wrap my mind around it!

Silverlight isn't my favorite technology however, I much prefer working in WPF and so I spent some time rebuilding Rx for the desktop CLR!  My original approach was to take my favorite exploration tool, reflector (available for free from www.redgate.com), and disassemble all the classes into C#, placing them into a project file.  I found however that Reflector choked on some of the more complicated structures - requiring me to go and hand-edit a bunch of the code.  I realized while I was doing this that there was a much easier way to convert a Silverlight assembly to a WPF assembly.

As you probably already know, Silverlight shares the same assembly format as the desktop CLR - there is no difference in the IL or structure of the assembly itself.  The difference is in the dependency on mscorlib and other references.  Specifically, when you add an assembly via VS2008, it looks at the version of the referenced mscorlib to determine whether it's a desktop CLR assembly or Silverlight assembly. 

Here's the header of a Silverlight assembly examined through ILDASM:

One of the coolest new features of Blend 3 is the inclusion of behaviors. This new feature formalizes the "attached behavior" model that has become so prevelant in WPF (and Silverlight) development.  I won't go into details on the architecture - instead I'll refer you to a nice reference:

http://blogs.msdn.com/expression/archive/2009/05/19/link-round-up-behaviors-related-posts.aspx

To play with this new support, I built a WatermarkTextBehavior which places a watermark into a TextBox when it has no entered data.  I've included this new behavior into the current build of my MVVM toolkit which I'll release soon, but for now, let's look at the behavior:

First, we derive from System.Windows.Interactivity.Behavior<T> - the placeholder parameter is the Visual type you want the behavior to act on.  This can be UIElement for anything WPF, or more restrictive if necessary based on the events you intend to hook up.  For our purposes here, we will set the restricted type to TextBox.

Next, you override the OnAttached() and OnDetaching() methods to hook up your event behaviors you desire.  Call the base implementation first, and then the AssociatedObject property will be the element you've been attached to (the TextBox in this case).  In our case we want to hook the GotFocus and LostFocus events - this is where we trigger our behavior.

Finally, we can provide any properties necessary to drive our behavior.  These should be done in the form of Dependency Properties so they are bindable and interact nicely with WPF.  The base Behavior<T> derives from Freezable and inherits the DataContext automatically to enable this support.  In our implementation we will have a Text property to indicate the watermark, and an attached property which we will place onto the TextBox so it can be styled when the watermark is being used.

Next we can hook it up in Blend through the Asset panel - all known assets are shown here (either registered, in the Blend directory, or project references).  Drag our WatermarkTextBehavior onto any TextBox and set the Text property and it will generate the following XAML:

Here is the complete source code to the behavior:

          
            using System; using System.Windows; using System.Windows.Controls; using System.Windows.Interactivity; namespace JulMar.Windows.Interactivity
{ ///
<summary>///
This behavior associates a watermark onto a TextBox indicating what the user should///
provide as input.///
</summary>publicclass WatermarkTextBehavior
: Behavior<TextBox> { ///
<summary>///
The watermark text///
</summary>publicstaticreadonly DependencyProperty
TextProperty = DependencyProperty.Register("Text", typeof (string), typeof (WatermarkTextBehavior), new FrameworkPropertyMetadata(string.Empty)); staticreadonly DependencyPropertyKey
IsWatermarkedPropertyKey = DependencyProperty.RegisterAttachedReadOnly("IsWatermarked", typeof(bool), typeof(WatermarkTextBehavior), new FrameworkPropertyMetadata(false)); ///
<summary>///
This readonly property is applied to the TextBox and indicates whether the watermark///
is currently being displayed. It allows a style to change the visual appearanve of
the///
TextBox.///
</summary>publicstaticreadonly DependencyProperty
IsWatermarkedProperty = IsWatermarkedPropertyKey.DependencyProperty; ///
<summary>///
Retrieves the current watermarked state of the TextBox.///
</summary>///
<param name="tb"></param>///
<returns></returns>publicstaticbool GetIsWatermarked(TextBox
tb) { return (bool)
tb.GetValue(IsWatermarkedProperty); } ///
<summary>///
Retrieves the current watermarked state of the TextBox.///
</summary>publicbool IsWatermarked
{ get { return GetIsWatermarked(AssociatedObject);
} private set
{ AssociatedObject.SetValue(IsWatermarkedPropertyKey, value);} } ///
<summary>///
The watermark text///
</summary>publicstring Text
{ get { return (string) base.GetValue(TextProperty);
} set { base.SetValue(TextProperty,
value); } } ///
<summary>///
Called after the behavior is attached to an AssociatedObject.///
</summary>///
<remarks>///
Override this to hook up functionality to the AssociatedObject.///
</remarks>protectedoverridevoid OnAttached()
{ base.OnAttached();
AssociatedObject.GotFocus += OnGotFocus; AssociatedObject.LostFocus += OnLostFocus;
OnLostFocus(null, null);
} ///
<summary>///
Called when the behavior is being detached from its AssociatedObject, but before it
has actually occurred.///
</summary>///
<remarks>///
Override this to unhook functionality from the AssociatedObject.///
</remarks>protectedoverridevoid OnDetaching()
{ base.OnDetaching();
AssociatedObject.GotFocus -= OnGotFocus; AssociatedObject.LostFocus -= OnLostFocus;
} ///
<summary>///
This method is called when the textbox gains focus. It removes the watermark.///
</summary>///
<param name="sender"></param>///
<param name="e"></param>privatevoid OnGotFocus(object sender,
RoutedEventArgs e) { if (string.Compare(AssociatedObject.Text, this.Text,
StringComparison.OrdinalIgnoreCase) == 0) { AssociatedObject.Text =string.Empty;
IsWatermarked =false;
} } ///
<summary>///
This method is called when focus is lost from the TextBox. It puts the watermark///
into place if no text is in the textbox.///
</summary>///
<param name="sender"></param>///
<param name="e"></param>privatevoid OnLostFocus(object sender,
RoutedEventArgs e) { if (string.IsNullOrEmpty(AssociatedObject.Text))
{ AssociatedObject.Text =this.Text;
IsWatermarked =true;
} } } } 
        

• Scenic Ribbon (native Win32 ribbon) in Windows Forms
• Native WM_TOUCH and WM_GESTURE messages
• Sensor API
• Shell APIs (jump lists, thumbnail buttons, libraries)

using System; using System.Diagnostics; using System.Windows; using System.Windows.Controls; using System.Windows.Input; using System.Windows.Media; namespace WpfApplication1
{ publicclass DragDropTabManager
{ privatestaticreadonly DependencyProperty
ManagerProperty = DependencyProperty.Register(typeof (DragDropTabManager).ToString(), typeof (DragDropTabManager), typeof (DragDropTabManager)); publicstaticreadonly DependencyProperty
EnabledProperty = DependencyProperty.RegisterAttached("Enabled", typeof(bool), typeof(DragDropTabManager), new PropertyMetadata(false,
DDTM_EnabledChanged)); privatestaticvoid DDTM_EnabledChanged(DependencyObject
d, DependencyPropertyChangedEventArgs e) { var tc = d as TabControl; if (tc
!= null) { var oldValue = (bool)
e.OldValue; var newValue = (bool) e.NewValue; if (oldValue
== true && newValue == false)
{ var ddtm = tc.GetValue(ManagerProperty) as DragDropTabManager; if (ddtm
!= null) { tc.PreviewMouseDown -= ddtm.TabItem_PreviewMouseDown;
tc.SetValue(ManagerProperty, null); } } elseif (oldValue
== false && newValue == true)
{ var ddtm = new DragDropTabManager(); tc.SetValue(ManagerProperty,
ddtm); tc.PreviewMouseDown += ddtm.TabItem_PreviewMouseDown; } } } publicstaticbool GetEnabled(DependencyObject
obj) { return (bool)obj.GetValue(EnabledProperty);
} publicstaticvoid SetEnabled(DependencyObject
obj, boolvalue) { obj.SetValue(EnabledProperty, value);
} privatebool isMoving; private TabItem
movingTabItem; private TabItem lastTab; private Point
ptStart; void TabItem_PreviewMouseDown(object sender,
MouseEventArgs e) { var ti = e.Source as TabItem; if (ti
!= null && e.LeftButton == MouseButtonState.Pressed)
{ var tc = ti.Parent as TabControl; if (tc
!= null) { tc.MouseMove += tc_MouseMove; tc.MouseLeftButtonUp
+= tc_MouseLeftButtonUp; ptStart = e.GetPosition(tc); movingTabItem = ti; } } } void tc_MouseMove(object sender,
MouseEventArgs e) { var tc = sender as TabControl; if (tc
== null) return; Point pt = e.GetPosition(tc); if (isMoving
== false) { if (Math.Abs(pt.X
- ptStart.X) > 10) { movingTabItem.IsHitTestVisible = false;
movingTabItem.RenderTransformOrigin = new Point(.5, .5);
movingTabItem.RenderTransform = new TranslateTransform(0,
0); tc.Cursor = Cursors.Hand; Panel.SetZIndex(movingTabItem, 1); isMoving = true;
tc.CaptureMouse(); } return; } TabItem newPos = FindTabItem(tc,
pt); if (newPos == null) tc.Cursor
= Cursors.No; else { lastTab = newPos; var xform = movingTabItem.RenderTransform as TranslateTransform; if (xform
!= null) xform.X = pt.X - ptStart.X; tc.Cursor = Cursors.Hand;
} } void tc_MouseLeftButtonUp(object sender,
MouseButtonEventArgs e) { var tc = sender as TabControl;
Debug.Assert(tc != null); tc.ReleaseMouseCapture(); tc.MouseMove
-= tc_MouseMove; tc.MouseLeftButtonUp -= tc_MouseLeftButtonUp; if (isMoving
== true) { isMoving = false; tc.Cursor
= Cursors.Arrow; movingTabItem.RenderTransform = null; movingTabItem.IsHitTestVisible
= true; Panel.SetZIndex(movingTabItem, 0); if (lastTab
!= null) { if (lastTab != null &&
movingTabItem != lastTab) { int targetIndex = tc.Items.IndexOf(lastTab);
tc.Items.Remove(movingTabItem); tc.Items.Insert(targetIndex, movingTabItem); movingTabItem.Focus();
} } } movingTabItem = lastTab = null; } privatestatic TabItem
FindTabItem(UIElement parent, Point pt) { var fe = parent.InputHitTest(pt) as FrameworkElement; while (fe
!= null && fe.GetType() != typeof(TabItem))
fe = VisualTreeHelper.GetParent(fe) as FrameworkElement; return fe as TabItem;
} } } 

About a year ago, I blogged on using the .NET 2.0 facility SynchronizationContext to create thread-aware components which could be hosted and would "do the right thing" for callbacks. Here's the Link to that post.

Recently, I got an email from a reader who wanted to use that paradigm, but wanted to be able to suspend the operation for some period of time and then resume it later on. He asked if there was an easy way to modify the sample I presented, and it turns out that there is.

It essentially involves three steps:

1. In the AsyncStateData structure, add a ManualResetEvent object. This will be used to trigger the pause/resume behavior. It must be initially set as signaled.

2. In the actual asynchronous operation loop, add the event into the loop condition by calling event.WaitOne(). Make sure you have released any locks and the code can safely be halted at that point in the logic otherwise you may create deadlock scenarios and other difficult debugging issues.

3. Add a Pause and Continue method into the class which signals and resets the event.

Step 1: Add the event to AsyncStateDate

 1: class AsyncStateData

 2: {

 3: private ManualResetEvent
pauseEvent = new ManualResetEvent(true);

 4:  ...

 5: }

Step 2: Add event into the loop at a safe point

 1: public
partialclass Calculator

 2: {

 3: privatevoid InternalCalculatePi(int digits,
AsyncStateData

 4: asyncData)

 5:  {

 6: int completedDigits
= 0;

 7: for (; !asyncData.canceled
&& pauseEvent.WaitOne(-1, true) &&

 8: completedDigits
< digits; completedDigits++)

 9:  { ... }

 10:  }

 11:  

 12: ...

 13: }

Step 3: Add a Pause and Continue API

 1: public
partialclass Calculator

 2: {

 3: publicvoid PauseAsync(object asyncTask)

 4:  {

 5:  AsyncStateData
asyncData = asyncTask as AsyncStateData;

 6: if (asyncData
!= null && asyncData.running == true)

 7:  asyncData.pauseEvent.Reset();

 8:  }

 9:  

 10: publicvoid ContinueAsync(object asyncTask)

 11:  {

 12:  AsyncStateData
asyncData = asyncTask as AsyncStateData;

 13: if (asyncData
!= null && asyncData.running == true)

 14:  asyncData.pauseEvent.Set();

 15:  }

 16: ...

 17: }

I've gotten several questions on this topic so I thought it might be a good thing to show in a blog.  Recording with TAPI 3.1 is actually pretty easy if you are running on Windows XP or better.  TAPI 3.1 provides some simple filename-based methods to dump the conversation into a .WAV file.  If you want to control the file, or stream it somewhere else, it's a bit more difficult and Microsoft provides a decent sample with the platform SDK that does it.

Here's a simple example -- in this scenerio we will create a new outgoing call, connect it and then setup an outgoing stream to play a welcome message:

TapiCall currCall = selectedAddress.CreateCall(numberToDial, LINEADDRESSTYPES.PhoneNumber, TAPIMEDIATYPES.AUDIO);
if (currCall !=null)
{
   currCall.Connect(false);
   playbackTerminal = currCall.RequestTerminal(TTerminal.FilePlaybackTerminal, TAPIMEDIATYPES.AUDIO, TERMINAL_DIRECTION.TD_CAPTURE);
   if (playbackTerminal !=null)
   {
      playbackTerminal.MediaPlayList =newstring[] { MESSAGE_PROMPT };
      currCall.SelectTerminalOnCall(playbackTerminal);
   }
}

When the call is actually connected, then we will start the playbackTerminal stream and begin recording the conversation - this would typically be done in the TE_CALLSTATE handler:

if (e.State == CALL_STATE.CS_CONNECTED && playbackTerminal !=null)
{
   // Start the playback message..
   playbackTerminal.Start();
   // Begin recording the conversation - may be half-duplex..
   RecordConversation("RecordedMessage.wav");
}
elseif (e.State == CALL_STATE.CS_DISCONNECTED)
{
   // Stop recording when the call terminates.
   if (recordTerminal !=null)
      recordTerminal.Stop();

   recordTerminal =null;
   playbackTerminal =null;
}

The code for recording the conversation is pretty simple as well, given a filename, just get a recording terminal and assign it.  TAPI will take care of creating the file and writing contents into it.

private void RecordConversation(string fileName)
{
   // This code only works on XP or better (TAPI 3.1).
   if (currCall !=null)
   {
      recordTerminal = currCall.RequestTerminal(TTerminal.FileRecordingTerminal, TAPIMEDIATYPES.MULTITRACK, TERMINAL_DIRECTION.TD_RENDER);
      if (recordTerminal !=null)
      {
         recordTerminal.RecordFileName = fileName;
         currCall.SelectTerminalOnCall(recordTerminal);
         recordTerminal.Start();
      }
   }
}

Finis.

A colleague of mine, Kev Jones, has posted some information on using a detached SQL Server database for driving VSTS unit tests which works great if you need a full blown SQL implementation.  However, if all you want is a simple data feed, you can also use an Excel file, and as it turns out, it's pretty easy to do.

Let's start by stealing Kev's sample, hopefully he won't mind -- say I have a starship class with a FirePhotonTorpedo method:

public class Enterprise
{
   privateint torpedosLeft = 10;

   publicint FirePhotonTorpedo(int count)
   {
      if (torpedosLeft < count)
         thrownew ArgumentException("count");

      torpedosLeft -= count;
      // Instruct bridge officer to "Fire!"
      return torpedosLeft;
   }
}

The equivalent unit test might look something like:

This code just tests a specific case -- I would also need to write other unit tests for edge cases and exceptional cases.  I can do this several different ways I could do this:

1) Write a unit test for each specific case passing each value and testing the expected result.
2) Put all the tests into this one unit test function -- asserting each validation as we go.
3) Pull the input and expected out of a database and run them through the function.

This last step, as Kev details can be done from a SQL database - either one reachable by all the people who might run the unit tests, or as his blog shows from a .MDF file you check in with the project and then locally attach prior to running the unit tests.  Hit the link above for the details on that. 

So, to make an Excel data-driven test, the first step is to create an Excel document with columns for each of our pieces of data.  My sample Excel document has the following columns:

ID	A unique number identifying the row so we can use the Random data driven test
torpedoCount	The input for our unit test
expected	The expected result coming out of the function
shouldFail	Whether the function will throw an exception.

I can then enter a single test on each row of the given worksheet.  Here's a screen shot --

You can create multiple "tables" by adding additional sheets to the worksheet.  Each sheet can be named as appropriate; I'm naming this one "TorpedoData".

Now, I need to add the appropriate attribute to my test case to indicate that it should pull the data from a data source and run the method once per row found.  The key is that any ADO.NET data source can be used.  Here I will specify my Excel file which is named "UnitTests.xls" and indicate that the table itself is a particular sheet within the Excel document "TorpedoData":

[TestMethod]
[DeploymentItem("Tests.xls")] // Copies the file to the deployment directory
[DataSource(
"System.Data.OleDb", // The provider
"Provider=Microsoft.Jet.OLEDB.4.0;Data Source='Tests.xls';Persist Security Info=False;Extended Properties='Excel 8.0'",
"TorpedoData$",      // The table name, in this case, the sheet name with a '$' appended.
DataAccessMethod.Sequential)] 
public void TestFirePhotonTorpedo()
{
}

I also need to update the test case itself to use the data -- we do that through the TestContext.DataRow property that gives us access to the current row of data from our data source:

public void TestFirePhotonTorpedo()
{
   Enterprise target =new Enterprise();
   int torpedoCount = Convert.ToInt32(TestContext.DataRow["torpedoCount"]);
   int expected = Convert.ToInt32(TestContext.DataRow["expected"]);
   bool shouldFail = (bool)TestContext.DataRow["shouldFail"];

   TestContext.WriteLine("Running test with TorpedoCount={0}, ExpectedCount={1}, ShouldFail={2}",
            torpedoCount, expected, shouldFail);

   try
   {
      int actual = target.FireTorpedos(torpedoCount);
      Assert.AreEqual(expected, actual, "FireTorpedos did not return the expected value.");
   }
   catch (Exception ex)
   {
      if (!shouldFail)
         Assert.Fail(string.Format("FireTorpedo threw exception {0}", ex.Message));
   }
}

So, here we will grab the data from the current row, converting it as necessary to the appropriate types, output a test line just to prove that we executed the method more than once and then run the test.  The test will compare the result with the expected database result and output a failure if they aren't the same.  If an exception is thrown, then the shouldFail must be true or that will be considered a failure.

This approach allows me to run through different scenarios very easily and I can just store the Excel worksheet right with my unit tests - make sure it's deployed to the target deployment directory (either through a DeploymentItem attribute, or through the test run configuration).  The size of my table here is about 14K, compared to the equivalent .MDF file which is over 2M for the same data.  If I didn't want to hardcode the filenames and such, I can also use an app.config file for the unit test and put the information there - just as Kev details.

Cool stuff indeed.