Specifying Properties

Custom Editors

• CheckBoxEditor
• CollectionEditor
• ColorEditor
• DateTimeUpDownEditor
• DecimalUpDownEditor
• DoubleUpDownEditor
• EnumComboBoxEditor
• FontComboBoxEditor
• IntegerUpDownEditor
• ItemsSourceEditor
• PrimitiveTypeCollectionEditor
• TextBlockEditor
• TextBoxEditor
• TimeSpanEditor

Custom ItemsSource

Expandable Properties

Conclusion

Let’s begin by defining what the BusyIndicator is used for.  The BusyIndicator is used to give an application user a visual indicator that a long running process is occurring.  So from this definition we can make two assumptions. One; There must be a mechanism for notifying the BusyIndicator when the long running process begins and when it ends.  Two; the long running process will have to occur on a separate thread as to not block the UI.

Anatomy of the BusyIndicator

The first thing you need to do when using any control inside the Extended WPF Toolkit is add a namespace declaration to the consuming view.

The BusyIndicator is a ContentControl.  What this means is that the BusyIndicator can contain a single child element within it’s open and closing tags.  For example:

Looking at this code snippet you can see that the Grid is the BusyIndicator’s Content.  If you were to place anything outside of this Grid element you would receive an exception.

The BusyIndicator has two visual states:

Not Busy:

Busy:

Toggling between these states is as simply as setting a single property called IsBusy.

When the BusyIndicator.IsBusy property is set to True, the BusyIndicator becomes visible and prevents any user interaction with the BusyIndicator’s Content.  So any elements that you have defined within the Content of the BusyIndicator will be disabled.  When the IsBusy property is set to False, the Content re-enables and user interaction can continue.

The Common Problem

The most common problem I see when people are having trouble using the BusyIndicator is that they are doing everything on the UI thread.  Let’s look at an example:

The event handler for the button looks like this:

Now the assumption is that first the BusyIndicator will be shown, then the long running process will occur, and lastly the BusyIndicator will be hidden.  To most people’s surprise it doesn’t work.  The BusyIndicator never shows and the UI is not responsive.  Do you see the problem?  The problem is that everything is running on the UI thread.

Solution

As we have already stated, the long running process must occur on a separate thread.  The UI thread needs to stay responsive while the process is running.  The most common method to place a long running process on a separate thread is to use the BackgroundWorker.

Let’s modify the event handler to utilize a BackgroundWorker.

Examine the code.  First we create an instance of a BackgroundWorker and add delegates for the DoWork and RunWorkerCompleted events.  The DoWork hander is where the long running process should go.  NO DIRECT INTERACTION WITH THE UI IS ALLOWED.  The RunWorkerCompleted handler is code that will run when the long running process has completed.  This is where you can interact with the UI again, meaning that this would be a perfect place to set the IsBusy property to False.  After the long running process has finished.  Now pay special attention to where we are calling RunWorkerAsync.  Just before that call, we are setting the IsBusy property to true.  Then the call to RunWorkerAsync is made.  This will show the BusyIndicator and then start the long running process.  When the process is complete the BusyIndicator is hidden again.  Perfect!

Common Problem 2

The next common problem is dealing with using data that is generated on the background thread in the UI.  Well if you read my post on multi-threading then you should already know how to solve this one.  If you haven’t, I will show you again.  This scenario requires that our UI have a ListBox control that is populated with items on a background thread.  While the items are being populated, the BusyIndicator should show the user something is happening and that they need to be patient.  Let’s modify our UI and our code behind to support his new scenario:

This is similar to what the problem cases look like.  This code will most definitely fail.  Remember, you cannot access any UI elements on a separate thread.  Now let’s modify this code to make it run correctly.

Solution

First we had to remove any reference to a UI element from the DoWork handler.  Now in order to propagate the generate list of strings back to the ListBox we enlist the help of the Dispatcher.  The Dispatcher will take the collection of strings, and in a thread safe way, give them to the ListBox for consumption.  Our BusyIndicator will be shown while the collection is being generated, and then be hidden when the process has been completed.

That about wraps it up.  These are the most common troubles developers have had using the BusyIndicator control.  If you have different problems that you haven’t been able to solve, feel free to post your question in the Discussions page of the project site.  You never know, it may be worth blogging about.

Calculator

The Calculator is a control used for performing mathematical calculations.

It provides basic math functions, memory functions, as well as mouse and keyboard support.

CalculatorUpDown

The CalculatorUpDown provides a TextBox with button spinners that allow incrementing and decrementing numeric values by using the spinner buttons, keyboard up/down arrows, or mouse wheel. It also provides a Calculator dropdown which allows you to perform mathematical calculations.

ColorCanvas

The ColorCanvas allows you to select a color either using an advanced color canvas, by setting the HexadecimalString, or by setting the ARGB values.  This control has also been merged with the ColorPicker to provide advanced color editing abilities.

DateTimePicker

Get the best of both worlds. The DateTimePicker provides a DateTimeUpDown control as well as a dropdown with a calendar and a TimePicker.

DecimalUpDown

The DecimalUpDown control provides a TextBox with button spinners that allow incrementing and decrementing Nullable<Decimal> values by using the spinner buttons, keyboard up/down arrows, or mouse wheel.

When using the DecimalUpDown in data binding scenarios, bind your object’s value to the Value property. You can specify how much to increment the value by setting the Increment property. You can control the minimum and maximum allowed values by setting the Minimum and the Maximum properties. You can also specify if the user can directly edit the values in the text box by setting the IsEditable property. If you would like to get the actual fromatted string representation of the value, you can use the Text property.

DoubleUpDown

The DoubleUpDown control provides a TextBox with button spinners that allow incrementing and decrementing Nullable<Double> values by using the spinner buttons, keyboard up/down arrows, or mouse wheel.

IntegerUpDown

The IntegerUpDown control provides a TextBox with button spinners that allow incrementing and decrementing Nullable<int> values by using the spinner buttons, keyboard up/down arrows, or mouse wheel.

PropertyGrid

The PropertyGrid is a pure WPF replacement for the WinForm PropertyGrid control.  Currently the PropertyGrid is in beta and still has a lot of work to be done on it.  But it is ready from simple use and testing.

SplitButton

The SplitButton control is a button that can be clicked and also provides a drop down in which you can place any custom content within.

TimePicker

The TimePicker is a control that is specifically for the Time portion of a DateTime property.  It provides a ButtonSpinner as well as a list of times to choose from.  You can also manually type in the time as long as it matches the specified format.

WatermarkTextBox

The WatermarkTextBox is simply a TextBox that allows you to sepcify an object, usually a String, to represent null or missing text.  Don’t think you are limited to just text!  With this control you may use any object as a watermark.  Here is an example using an image with text:

Also, all input controls in the Extended WPF Toolkit now provide a Watermark option.

That’s it for the new controls.  I hope you enjoy version 1.4.0 and be sure to report any bugs or request new features in the Issue Tracker.  As always if you have any questions be sure to ask them in the Discussions.

Lets start things out by outlining the various parts of a web page:

• Title
• Header
• Content
• Footer
• CSS includes
• Script includes
• JavaScript

Typically, without eliciting some tricks, there will be some JavaScript in your page, as there will be some part of the script that is dynamic.  But best case, all of the JavaScript that you need can be put into a separate file.  But even then, if we are talking 5 lines of JavaScript I will probably give you a pass if you keep it in the file.

But what I want to do is encourage best better practices.  CSS is declared at the top, JavaScript at the bottom, html in the middle, code you want to run right after the page loads here.

So here is a typical MasterPage after I’ve made a few modifications:

   1: <%@ Master Language="C#" Inherits="System.Web.Mvc.ViewMasterPage" %>

   2:  

   3: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

   4:  

   5: <html xmlns="http://www.w3.org/1999/xhtml" >

   6: <head runat="server">

   7:     <title><asp:ContentPlaceHolder ID="TitleContent" runat="server" /></title>

   8: </head>

   9: <body>

  10:         <asp:ContentPlaceHolder ID="MainContent" runat="server">

  11:         

  12:         </asp:ContentPlaceHolder>

  13:  

  14:     <%
   1: = Html.IncludeScript("~/Scripts/jquery-1.3.2.min.js") 
%>

  15:     <asp:ContentPlaceHolder ID="ScriptIncludesContent" runat="server">

  16:     

  17:     </asp:ContentPlaceHolder>

  18:  

  19:     <script type="text/javascript">
   1:  

   2:     $(document).ready(MasterLoadPage);

   3:     

   4:     function MasterLoadPage(){

   5:         <asp:ContentPlaceHolder ID="DocumentReadyContent" runat="server">

   6:         

   7:         </asp:ContentPlaceHolder>

   8:     }

   9:     

  10:     
</script>

  20: </body>

  21: </html>

You can see that I’ve added some extra placeholders in the code there. 

But does any of this suck? Yes.  When you add a page that implements this master page, you will get all of the appropriate content areas, but they will all assume that you are going to add html/text to them.    The consequence is that the DocumentReadyContent Content area that is generated cannot help you with any JavaScript/Css intellesense. 

To some extent, that is still ok, as I am looking to minimize the amount of JavaScript and css in my pages…you could say the pain is disserved.    But what would be nice is if we could add a language indicator to the Content element. (hint: Microsoft VS team, I’m looking at you).  

If you also think adding language indicators would be cool, vote here: http://aspnet.uservoice.com/forums/41199-general/suggestions/487773-make-language-specific-contentplaceholders-

Happy hacking.

Invoking private methods is not considered a best practice in general, but there are cases where you have no other option than to fall back on using reflection. The following code snippet shows how one would typically accomplish that.

public class Subject
{
    private String DoSomething(String input)
    {
        return input;
    }
}

// Calling code
var subject = new Subject();
var doSomething = typeof(Subject).GetMethod("DoSomething",
    BindingFlags.Instance | BindingFlags.NonPublic);
var result = doSomething.Invoke(subject, new[] { "Hello Muppets" });
Console.WriteLine(result);  

We all recognize this piece of code as we’ve done this at some point in one of our coding sessions. What I want to share here is a slightly nicer way to accomplish the same without all the usual reflection ugliness.

// Calling code that uses delegates
var subject = new Subject();
var doSomething = (Func<String, String>)
    Delegate.CreateDelegate(typeof(Func<String, String>), subject, "DoSomething");
Console.WriteLine(doSomething("Hello Freggles"));

This code just creates a delegate that matches the signature of the non-public method that we want to call. To me, this approach looks far more elegant. Note that this only works for instance methods and not for static methods.

I hope that this can be of some use.

My original classes were similar to this:

public class MyProgress{
   public virtual Guid Id { get; set; }
   ...
   ...
   public virtual MyStatus Status { get; private set; }
}

public enum MyStatus{
   New,
   InProgress,
   Completed,
   Canceled,
   Failed
}

My new state pattern was similar to this:

public abstract class MyStatus
{
    public static readonly MyStatus New = new NewStatus();
    public static readonly MyStatus InProgress = new InProgressStatus();
    ...
}

public class NewStatus: MyStatus
{
    public override void Start(MyProgress progress)
    {
        progress.SetStatus(InProgress);
    }
    public override void Cancel(MyProgress progress)
    {
        progress.SetStatus(Cancelled);
    }
    public override void Fail(MyProgress progress)
    {
            progress.SetStatus(Failed);
    }
}
...

Here is the problem… My enumeration was persisted as an integer field on the record. Now that I had a state pattern, how should I save my state? I googled the problem and found Derick Bailey’s article on the state pattern and Fluent NHibernate. Derick’s pattern works well, but I felt that creating a lookup table in my database just so I can persist a value in another table was not the path I wanted to traverse – I wasn’t persisting an entity, I was persisting a state value on an entity. Not finding any more love from Google, I asked around and was advised to contact fellow Elegant Coder and Guild3 member, Jason Grundy. Here is Jason’s advice:

“I’ve recently changed from using Enums to an approach outlined by Jimmy Bogard here.  In the Entity I would do something like this:

protected int _orderStatusId;
public virtual OrderStatus OrderStatus
{
    get { return Enumeration.FromValue<OrderStatus>(_orderStatusId); }
    set { _orderStatusId = value.Value; }
}

Then in Fluent NH you can simply map to the protected member.”

I decided to pursue Jason’s advice.  The result is my database tables did not need to change at all. Here is some snippets of the updated classes:

public class MyProgress
{
     public virtual Guid Id {get;set;}
     ...
     protected int _status;
     public virtual MyStatus
     {
         get{ return Enumeration.FromValue<MyStatus>(_status); }
         set{ _status = value.Value; }
     }
     ...
}

public class MyStatus : Enumeration
{
     public static MyStatus New = new NewStatus();
     ...

     private class NewStatus : MyStatus
    {
         public NewStatus() : base (0,"New"){}

         public override void Start(MyProgress progress)
         {
             progress.SetStatus(InProgress);
         }
    }
     ...

Notice that the MyStatus class is no longer abstract.  However, the subclasses are all private nested classes, each with a value and a display name.  I set each subclass value to match the enumeration value it replaced.  I did not need to convert my existing data to a new schema.

And here is the Fluent NHibernate override:

public class MyProgressOverride : IAutoMappingOverride<MyProgress>
{
    public void Override(AutoMapping<MyProgress> mapping)
    {
        mapping.Map(x => x.Status)
            .CustomType(typeof(int))
            .Access.CamelCaseField(Prefix.Underscore);
    }
}

As you can see, we use convention-based automapping with overrides, but this same map could be used in a standard class map.

Thanks to Jimmy, Derick, and Jason for the inspiration and assistance!

Enter the ICollectionView.  “You can think of a collection view as a layer on top of a binding source collection that allows you to navigate and display the collection based on sort, filter, and group queries, all without having to manipulate the underlying source collection itself.”, says the MSDN documentation. The ICollectionView supports filtering, sorting, grouping, selection, and navigation.

Now the most common way this is used is by creating your collection, populating it with data, then creating an ICollectionView instance from your collection, and then start sorting, filtering, grouping, etc.  The following code show some examples of how to use the ICollectionView.

//get the view

List<MyObject> myList = new List<MyObject>();   

ICollectionView view = CollectionViewSource.GetDefaultView(myList);

//filtering

view.Filter = delegate(object item)

{return item.Contains(searchText);};

//sorting

view.SortDescriptions.Add(new SortDescription("LastName", direction));

//grouping

view.GroupDescriptions.Add(new PropertyGroupDescription("State"));

//selection

view.CurrentItem

But I didn’t want to do this every time I had a collection of data I wanted to navigate. I wanted a single generic collection class that encapsulated all this functionality. So I decided to extend the ObservableCollection to allow for this functionality. So the first thing I need to do is create my class, inherit from ObservableCollection, and then create my constructors.

public class MyObservableCollection<T> : ObservableCollection<T>

{

    public MyObservableCollection(List<T> list)

        : base(list)

    {

    }

    public MyObservableCollection(IEnumerable<T> collection)

        : base(collection)

    {

    }

}

Next I want to create my method to return my instance of ICollectionView.

private System.ComponentModel.ICollectionView GetDefaultView()

{

    return System.Windows.Data.CollectionViewSource.GetDefaultView(this);

}

Now, lets create a property to retrieve the currently selected item in the list.

public int CurrentPosition

{

    get

    {

        return GetDefaultView().CurrentPosition;

    }

}

Now lets create our four methods for navigating the items in the collection.

public void MoveFirst()

{

    GetDefaultView().MoveCurrentToFirst();

}

public void MovePrevious()

{

    GetDefaultView().MoveCurrentToPrevious();

}

public void MoveNext()

{

    GetDefaultView().MoveCurrentToNext();

}

public void MoveLast()

{

    GetDefaultView().MoveCurrentToLast();

}

Now, lets use our new collection. First start off by creating and instance of your custom collection.

MyObservableCollection<MyObject> ProgressItemsList = new MyObservableCollection<MyObject>(data);

In this example I am using a WPF Ribbon to hold my navigation controls, and commanding to execute the navigation methods. The center label maintains the current position and the count of the number of items in the collection.

So now, when I click the Next button I first need to check whether or not I can move to the next record in the command’s CanExecute event.

private bool CanMoveNext(object parameter)

{

    bool canExecute = false;

    if (ProgressItemsList != null)

    {

        int currentPosition = ProgressItemsList.CurrentPosition;

        int lastIndex = ProgressItemsList.Count - 1;

        canExecute = currentPosition < lastIndex;

    }

    return canExecute;

}

If I can move to the next record, then execute the Execute method of the command.

private void MoveNext(object sender)

{

    ProgressItemsList.MoveNext();

}

That is it, and because this is an ObservableCollection, all the changes are notified back to the UI for you automatically. Now you can extend your custom collection even more to customize your sorting, filtering and grouping.

But at some point one of the commentors noticed that the var statement was just as fast as the explicitly called out type.  Let me spell something out real quick: Once compiled, there is no difference between var and explicit types.  ‘var’ is a language sort-cut, asking the compiler to figure out the type and inject it.  This is not a runtime feature – ‘var’ is a compile time feature.

Now, how often do I use var in my code?  All the time.  I use it practically everywhere.  Think of it as a refactoring helper.  Sometime I have to change a method from returning a IList to an IEnumerable.  If I use a var and a foreach then none of the rest of my code has to change.  That, to me is flexible code.

I could make my code more performant by replacing the foreach loops with for loops – but I’ll keep the var’s thank-you-very-much.  But most of the time I am not dealing with enough data to make that worth it.  Most of the time I’m working with data to get displayed on web and mobile user interfaces.  In those cases, limiting the amount of data I need to process, and then display, is of upmost importance.  If I’m doing a file import (rare, but it does happen), then I switch to the other techniques.

Now, why bother?  Why not always use the fastest method all the time?  Because I find the foreach with ‘var’s easier to read, more flexable code, and more refactoring friendly.  For the vast majority of my code, that matters a lot more than eking out every last bit of performance.

Also, it is something that needs to be done.

So, can we make exception logging as frictionless as possible?

1. Roll your own logging library.
2. Repeat the same code a lot in your application calling your library.

Kidding. On both fronts.

Extending Exception

Since the problem is just about logging exceptions, adding an extension method to the basic Exception class makes a lot of sense.

   1: public static void Log( this Exception exception )

   2: {

   3:     . . . 

   4: }

Now, using this extension method, logging an exception looks like this:

   1: try

   2: {

   3:     // do something that would throw

   4:     // an exception

   5: }

   6: catch (Exception ex)

   7: {

   8:     ex.Log();

   9: }

Enterprise Library Logging Application Block

Enterprise Library makes what happens inside the extension method an easy implementation, too. The act of logging is simple enough with EntLib, but the real value is in how the configuration story lets an application administrator decide how the logging solution will actually behave at runtime.

For instance, when building a recent application, I asked the client if they wanted to receive email when a significant application error occurred. Their response was, “Just write to the Windows Event log. We have a monitoring application that will email us.”

Fine by me! Windows Event log, text file, email, it’s all the same because the ultimate destination of the log message is a configuration setting.

Anyway, the implementation of the extension method can look as simple as this.

   1: public static void Log( this Exception exception )

   2: {

   3:     var entry = new LogEntry

   4:     {

   5:         Severity = TraceEventType.Warning,

   6:         Title = "Application Exception",

   7:         Message = exception.ToString(),

   8:     };

   9:     Logger.Write(entry);

  10: }

Of course, I ended up with some overloads and other niceties , but the basic approach remains sound.

First lets start with how to get started with multithreading in WPF. If you don’t want to read how this actually works and just want to get the source and start playing ,here is the Source Code.

Your WPF application may need to perform intensive tasks that consume large amounts of time. Executing these tasks on a separate thread allows you to maintain the responsiveness of the UI while the task is performed. Enter the BackgroundWorker. The BackgroundWorker is the recommended way to run time consuming tasks on a separate, dedicated thread, leaving the UI responsive.

Running a Background Process

The RunWorkerAsync method starts the execution of the background process by raising the DoWork event. The code in the DoWork event handler is executed on a separate thread.

int maxRecords = 1000;

BackgroundWorker worker = new BackgroundWorker();

worker.DoWork += delegate(object s, DoWorkEventArgs args)

{

    for (int x = 1; x < maxRecords; x++)

    {

        System.Threading.Thread.Sleep(10);

    }

};

worker.RunWorkerAsync();

Providing Parameters to the Process

Your background process may required one or more parameters, such as the address of a file to download. You can provide a parameter in the RunWorkerAsync method that will be available as the Argument property in the DoWork event handler.

BackgroundWorker worker = new BackgroundWorker();

worker.DoWork += delegate(object s, DoWorkEventArgs args)

{

    string path = (string)args.Argument;

    //do something

};

worker.RunWorkerAsync("c:\\myFile.txt");

Returning a Value from the Process

You might want to return a value from a background process, such as a result from a calculation. You can return a value by setting the Result property of the DoWorkEventArgs in the DoWork event handler. Then, this value can be retrieved from the Result property of the RunWorkerCompletedEventArgs parameter int the RunWorkerCompleted event handler.

BackgroundWorker worker = new BackgroundWorker();

worker.DoWork += delegate(object s, DoWorkEventArgs args)

{

    args.Result = CalculationMethod();

};

worker.RunWorkerCompleted += delegate(object s, RunWorkerCompletedEventArgs args)

{

    object result = args.Result;

};

worker.RunWorkerAsync();

Cancelling the Background Process

You may want to allow the user to cancel a long running process. In order to support this you must first set the WorkerSupportsCancellation to true. You call the CancelAsync mtehod to attempt to cancel the process. When you call the CancelAsync method it sets the CancellationPending property of the BackgroundWorker to true. Then you must check for the value of the CancellationPending property in the DoWork event handler, and if it is true, set the Cancel property of the DoWorkEventArgs parameter to true.

int maxRecords = 1000;

BackgroundWorker worker = new BackgroundWorker();

worker.WorkerSupportsCancellation = true;

worker.DoWork += delegate(object s, DoWorkEventArgs args)

{

    for (int x = 1; x < maxRecords; x++)

    {

        //check if there is a cancelat

        if (worker.CancellationPending)

        {

            args.Cancel = true;

            return;

        }

        System.Threading.Thread.Sleep(10);

    }

};

worker.RunWorkerAsync();

Reporting the Progress of a Background Process

You can report the progress of a background process back to the primary thread by calling the ReportProgress method. This method raises the ProgressChanged event and allows you to pass a parameter that indicated the percentage of progress that has been completed. Make sure you set the WorkerReportsProgess property of the BackgroundWorker to true.

int maxRecords = 1000;

BackgroundWorker worker = new BackgroundWorker();

worker.WorkerReportsProgress = true;

worker.DoWork += delegate(object s, DoWorkEventArgs args)

{

    for (int x = 1; x < maxRecords; x++)

    {

        System.Threading.Thread.Sleep(10);

        worker.ReportProgress(Convert.ToInt32(((decimal)x / (decimal)maxRecords) * 100));

    }

};

worker.ProgressChanged += delegate(object s, ProgressChangedEventArgs args)

{

    int percentage = args.ProgressPercentage;

};

worker.RunWorkerAsync();

Using the Dispatcher to Access Controls on Another Thread

At times, you may want to change the user interface from a worker thread. For example, you may want to enable or disable buttons, or show a modal ProgressBar that provides more detailed progress information than is allowed by the ReportProgress method. The WPF threading model provides the Dispatcher class for cross thread calls. By using the Dispatcher, you can safely update your user interface from background worker threads.

You can get a reference to the Dispacther object for a UI element from its Dispatcher property.

System.Windows.Threading.Dispatcher aDisp = Button1.Dispatcher;

Dispatcher provides two main methods that you will use; Invoke and BeginInvoke. Both methods allows you to call a method safely on the UI thread. The BeginInvoke method allows you to call a method asynchronously, and the Invoke method allows you to call a method synchronously.

Putting It All Together

Lets say I have a time consuming task in my application.  I want to execute this time consuming task on a background thread, but I also want to show a modal progress dialog that shows a message and the percent of the completed task. I also want to allow the user to cancel the process at anytime. So the first thing I need to do is create my progress dialog window that has a label to display my percent completed, a progress bar to graphically show the progress, and a cancel button so the user can cancel the process.

<Window x:Class="MultiThreading.ProgressDialog"

    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

    Title="ProgressDialog" Height="115" Width="300" WindowStyle="ToolWindow" WindowStartupLocation="CenterOwner">

    <Grid>

        <StackPanel>

            <Label x:Name="lblProgress" Content="0%"/>

            <ProgressBar x:Name="progress" Height="25" IsIndeterminate="False"></ProgressBar>

            <StackPanel Orientation="Horizontal" HorizontalAlignment="Right">

                <Button x:Name="btnCancel" Click="btnCancel_Click">Cancel</Button>

            </StackPanel>

        </StackPanel>

    </Grid>

</Window>

I need to expose two properties; ProgressText to set my label, and ProgressValue to set the progress bar value. I also need to expose an event so when the user hits the cancel button the process will stop.

   1: public string ProgressText

   2: {

   3:     set

   4:     {

   5:         this.lblProgress.Content = value;

   6:     }

   7: }

   8:  

   9: public int ProgressValue

  10: {

  11:     set

  12:     {

  13:         this.progress.Value = value;

  14:     }

  15: }

  16:  

  17: public event EventHandler Cancel = delegate { };

  18:  

  19: private void btnCancel_Click(object sender, RoutedEventArgs e)

  20: {

  21:     Cancel(sender, e);

  22: }

Now on my main application I need a button to execute this long running process and show my progress dialog.

<Button Height="23" Name="btnDispacther" Click="btnDispacther_Click">Using Dispatcher</Button>

Now lets code the background worker.

//our bg worker

BackgroundWorker worker;

//our progress dialog window

ProgressDialog pd;

private void btnDispacther_Click(object sender, RoutedEventArgs e)

{

    int maxRecords = 1000;

    pd = new ProgressDialog();

    //hook into the cancel event

    pd.Cancel += CancelProcess;

    //get our dispatcher

    System.Windows.Threading.Dispatcher pdDispatcher = pd.Dispatcher;

    //create our background worker and support cancellation

    worker = new BackgroundWorker();

    worker.WorkerSupportsCancellation = true;

    worker.DoWork += delegate(object s, DoWorkEventArgs args)

    {

        for (int x = 1; x < maxRecords; x++)

        {

            if (worker.CancellationPending)

            {

                args.Cancel = true;

                return;

            }

            System.Threading.Thread.Sleep(10);

            //create a new delegate for updating our progress text

            UpdateProgressDelegate update = new UpdateProgressDelegate(UpdateProgressText);

            //invoke the dispatcher and pass the percentage and max record count

            pdDispatcher.BeginInvoke(update, Convert.ToInt32(((decimal)x / (decimal)maxRecords) * 100), maxRecords);

        }

    };

    worker.RunWorkerCompleted += delegate(object s, RunWorkerCompletedEventArgs args)

    {

        pd.Close();

    };

    //run the process then show the progress dialog

    worker.RunWorkerAsync();

    pd.ShowDialog();

}

//our delegate used for updating the UI

public delegate void UpdateProgressDelegate(int percentage, int recordCount);

//this is the method that the deleagte will execute

public void UpdateProgressText(int percentage, int recordCount)

{

    //set our progress dialog text and value

    pd.ProgressText = string.Format("{0}% of {1} Records", percentage.ToString(), recordCount);

    pd.ProgressValue = percentage;

}

void CancelProcess(object sender, EventArgs e)

{

    //cancel the process

    worker.CancelAsync();

}

That’s it. See, I told you it wasn’t that bad. Now that you have a basic understanding of multithreading, try to see how creative you can get on implementing it in your WPF application.