Rob Windsor's Weblog : DevCenter

TechEd Developer 2008

windsor — Sat, 17 May 2008 11:47:00 GMT

The spring conference season keeps on chugging along. The MVP Summit and DevTeach just finished and TechEd is just around the corner.

It will be interesting to see what effect splitting the conference into a developer week and an IT Pro week will have. I've been spending a lot of time with SharePoint lately and that's a topic that has firm roots on both sides. I'm sure there are many other disciplines (SQL Server and VSTS come to mind) that are in the same boat.

This year I'll be taking it easier on the "networking" than I have in the past. I'm moderating a Birds-of-a-Feather (BoF) session and co-presenting an early-morning TLC talk and want to do so with a clear head. I'll also still be in the process of upgrading ObjectSharp's ASP.NET course from 2.0 to 3.5 which will be delivered for the first time the week following the conference.

I went through the session builder earlier and there are a ton of things I want to see. I had two or three (sometimes even more) sessions per time slot that I wanted to see. This morning I deleted all those and later this weekend I'm going to go through and pick the sessions that I absolutely don't want to miss (my sessions for example) and put those in Outlook. Everything else will be done spur of the moment at the conference.

For those of you who are attending the conference for the first time, you might want to check out my Guide to Attending TechEd or PDC.

I'll be Twittering (http://twitter.com/rob_windsor) and hopefully blogging from the conference. If you're there feel free to look me up or better yet drop by one of my sessions.

WIN07-TLC Strategies for Moving Microsoft Visual Basic 6 Applications to Microsoft .NET
Wednesday, June 4 8:30 AM - 9:45 AM
Blue Theatre 1

BOF806 Strategies for Moving Your Microsoft Visual Basic 6 Investments to .NET
Thursday, June 5 1:00 PM - 2:15 PM
S330 E

Technorati Tags: [TechEd, Visual Basic, VB]

Talking WCF on Devcasting

windsor — Sat, 12 Apr 2008 14:26:00 GMT

While I was in Vegas for Un-Mix 08, I sat down with Derek Hatchard to record a show for Devcasting. About a week later Derek decided to repave his machine but unfortunately, he forgot to backup the recording of the interview. We got together over Skype to re-record a couple weeks ago. What started out as an interview on WCF turned into a 90 minute conversation on all things geek.

Derek's done some editing and has extracted the WCF interview part into a show which you can check out at the link below. Stay tuned for part two where we talk about Mix, WPF, and more.

http://devcasting.com/index.php/2008/04/10/devcasting-10-wcf-with-rob-windsor/

Happy listening.

TechEd BOF Session: Strategies for Moving Your Microsoft Visual Basic 6 Investments to .NET

windsor — Sat, 29 Mar 2008 03:02:00 GMT

If you're not familiar with the concept, a Birds-of-a-Feather (BOF) session is an open discussion lead by a moderator who is not a Microsoft employee. The sessions are not presentations, there are no projectors. Unlike the Keynotes and Breakout sessions which are mostly one to many communication, Birds-of-a-Feather sessions are many to many communication and don't necessarily focus on Microsoft products or technology. They are about people talking with people - connecting, sharing, networking, and creating community.

This year I'd like to do a BOF session at TechEd Developer. From my expereince with the community at user groups and conferences it's pretty clear that there are lots of developers who still work with classic VB code at least part of the time. Many are still questioning what to do with this legacy code and how to move it forward or integrate it with .NET. So I've proposed the following:

Strategies for Moving Your Microsoft Visual Basic 6 Investments to .NET: For years Visual Basic 6 (VB 6) was used by organizations world-wide to build key line-of-business applications and components. Now they have thousands to millions of lines of code representing a significant organizational investment. Many have struggled in the past trying to move this legacy code base to .NET, many are just starting that journey. The path from VB 6 to .NET has not always been clear - there are options but there is no one size fits all approach. One option is to rewrite your applications so you can re-architect and take advantage of all the features .NET has to offer. Another is to migrate the applications so automated tools like the Code Advisor and the Migration Wizard can assist you. Finally, you can use COM Interop and the Interop Forms Toolkit to continue leveraging existing working assets while phasing in new features built on the .NET Framework. In this session we will discuss all three options and explore the pros and cons of each. The goal is raise awareness of the choices and the tools available so you will be able to pick the best strategy for your organization going forward.

~~So, if you're going to TechEd and you'd like to join in on the discussion, please head on over to the~~ ~~BOF voting page~~ ~~and add your vote. Voting closes on April 7.~~

Update:
The BOF was selected. It's running on Wednesday, June 4 from 8:30 to 9:45 AM. I think to room is S330 EF but I'm not positive. If you're planning on attending please let me know the subject(s) you'd like to discuss by adding a comment.

Update (April 28, 2008):
The BOF was selected. It's BOF806 and is running Thursday, June 5 from 1:00 to 2:15 pm. If you're planning on attending please let me know the subject(s) you'd like to discuss by adding a comment.

See you then.

Visual Studio 2008 to be Released on November 15th?

windsor — Sun, 11 Nov 2007 16:37:00 GMT

Don Box hints that it may be so.

http://www.pluralsight.com/blogs/dbox/archive/2007/11/10/49001.aspx

Visual Studio 2008 "How Do I" Videos

windsor — Tue, 16 Oct 2007 01:56:00 GMT

If you're interested in seeing some of the new features of Visual Studio 2008 in action, you should check out the series of "How Do I" videos at http://www.visualstudio2008beta.com/videos.htm. There are 13 up there now and more will be added every week. If you want to play along, head on over to http://msdn2.microsoft.com/en-us/vstudio/aa700831.aspx and download a copy of Beta 2 for yourself.

Using a Splash Screen from an External Assembly in Visual Basic 2005

windsor — Sat, 18 Aug 2007 21:08:00 GMT

This issue came up on one of email lists I'm involved in and I though the solution was worth sharing. The developer wanted to know how to use a splash screen from an external assembly (i.e. a DLL) in a Visual Basic 2005 Windows application. If you look at the Applications tab of the project properties, there is dropdown to pick the splash screen but it will only show forms in the current project.

To use a splash screen from an external assembly click the View Application Events button to get the partial class for the application and then override the OnCreateSplashScreen method. The code should look something like this.

   19 Partial Friend Class MyApplication
   20     <Global.System.Diagnostics.DebuggerStepThroughAttribute()> _
   21     Protected Overrides Sub OnCreateSplashScreen()
   22         Me.SplashScreen = New ClassLibrary1.SplashScreen1()
   23     End Sub
   24 End Class

Application Settings Made Easy with My and Visual Basic 2005

windsor — Sun, 28 Jan 2007 08:56:20 GMT

Most applications require some configuration settings that could change over time. Classic examples would be a connection string to a database, the URL to your company web site, or the path to a log file. These settings could be stored in the application itself but this would mean that, should the setting change, the application would have to be modified, recompiled, and redeployed. A better approach would be to store the values of these settings in some external data store; traditionally this has been an INI file, a “plain” XML file, or the Windows registry.

When .NET was introduced it included built in support for configuration files which, amongst other things, could store application settings. To store settings you have to add specific XML tags and values into the configuration file so that associated classes in the Framework will be able to access them. For example, if you wanted to add a setting called AppBackColor you would include the following in your configuration file:

You would then be able to access the setting using:

Imports System.Configuration
Private Sub Form1_Load(...) Handles MyBase.Load
    Dim backColor As String
    backColor = ConfigurationSettings.AppSettings("AppBackColor")
    Me.BackColor = Color.FromName(backColor)
End Sub

There are three main issues with this procedure. First, you need to know the format of XML that’s needed in the configuration file. Second, you access the individual settings by passing their name as a string to the AppSettings object. And third, the setting value comes back to you as a string.

This means you have three potential points of failure that will all rear their ugly heads at runtime. You could potentially put improperly formatted XML in the configuration file, you could type the name of the setting incorrectly when trying to access it, and you could give the setting an invalid value (in the example above that would be something that is not a know color to .NET).

In Visual Basic 2005 you have another option. Microsoft has added both Visual Studio designers and new .NET Framework classes to make management and use of settings much, much easier. To add a new setting or to change an existing one, open your project properties, select the Settings tab, and you will be presented with the settings editor grid (see Figure 1).

Figure 1 – Settings Grid with an application setting

Each setting now has four properties instead of just the two used previously. The Name and Value are there as before but now you also have a Type and a Scope. The Type property allows us to strongly type the setting, meaning that you cannot set an initial Value that is not of the correct type and when you use the setting in code you will not have to cast or convert it from a string. The final property is Scope which can be set to Application or User. Application scoped settings are read-only and serve the same function as settings in previous versions of Visual Basic while user scoped settings are specific to an individual user and can be modified in code. User scoped settings will be discussed later in this article.

The data you’ve entered in the settings grid is saved in the configuration file as before, it’s just done for us by the designer. You don’t have to know which tags are required and what their attributes are nor do you have to worry about spelling or capitalization mistakes. Entering the settings shown in Figure 1 will result in this being added to the configuration file:

<configuration>

<applicationSettings>
    <SettingsDemo.My.MySettings>
      <setting name="AppBackColor" serializeAs="String">
        <value>AntiqueWhite</value>
      </setting>
    </SettingsDemo.My.MySettings>
</applicationSettings>
</configuration>

Now that the new setting has been configured, it can be used in your code. In this case you could use it to initialize the background color of the main form. The setting is accessed using the My namespace (which is a major addition to Visual Basic 2005) and is much cleaner than our previous example.

Private Sub Form1_Load(...) Handles MyBase.Load
Me.BackColor = My.Settings.AppBackColor
End Sub

It’s important to note that AppBackColor has become a property of the Settings class. When your application starts, Visual Basic reads the settings from the configuration file and builds these properties dynamically. Because your setting is now a property you don’t have to worry about typing the name incorrectly (you’ll get a compiler error if you do) and you get the benefits of strong typing. That is the value of the AppBackColor property is a Color, not a string that needs to be converted to a Color.

You can see that these new features address the issues found in the older settings architecture and greatly ease the process of managing and using application settings. But wait, there’s more! There’s still user scoped settings to cover.

Designer and .NET Framework support for user scoped settings, or per-user settings, is wholly new to Visual Basic 2005 (For information on how to accomplish this in previous versions of Visual Basic.NET, see Rocky Lhotka’s article entitled Storing User Configurations which can be found at http://shrinkster.com/c3x). User settings are used in much the same way as application settings but the effect is quite different.

You add a user setting in exactly the same way as an application setting but you set the Scope to User. Figure 2 shows a user setting called UserFont with an initial value of Microsoft Sans Serif, 8.25pt.

Figure 2 – Settings Grid with an application and a user setting

This new setting will update the configuration file to look like this:

<configuration>

<userSettings>
    <SettingsDemo.My.MySettings>
      <setting name="UserFont" serializeAs="String">
        <value>Microsoft Sans Serif, 8.25pt</value>
      </setting>
    </SettingsDemo.My.MySettings>
</userSettings>
<applicationSettings>
    <SettingsDemo.My.MySettings>
      <setting name="AppBackColor" serializeAs="String">
        <value>AntiqueWhite</value>
      </setting>
    </SettingsDemo.My.MySettings>
</applicationSettings>
</configuration>

And, as before, the new setting can now be used in code.

Private Sub Form1_Load(...) Handles MyBase.Load
Me.BackColor = My.Settings.AppBackColor
Me.Font = My.Settings.UserFont
End Sub

This, however, is where the similarities end. As mentioned previously, user settings are specific to a user and can be modified at runtime. So what happens when you change a setting for a user? Let’s assume you have a menu option that lets the user change the font for the main form of our application. If the user does change the font, you’ll likely want to save their choice so that you can restore it the next time the application runs. To do this you will use the UserFont setting.

When the application closes you will set UserFont to the font of the main form and then save the setting.

Private Sub Form1_FormClosed(...) Handles Me.FormClosed
My.Settings.UserFont = Me.Font
My.Settings.Save()
End Sub

When you do this a user specific configuration file called user.config will be created in a folder under the Documents and Settings for the person currently logged in to Windows. This file will store the setting data specific to that user.

Nice? It gets even better. You can actually achieve the same result without any code. The Windows Forms designer supports binding user settings to properties of forms or controls. For example, you could bind the UserFont setting to the Font property of our application’s main form (Form1). In the Properties Window for Form1 find (ApplicationSettings) and expand it. Then select (PropertyBinding) and click the button with the ellipses to open the binding editor form (see Figure 3). Finally, select the Font property, click the dropdown, and select UserFont from the list.

Figure 3 – Binding a user setting to a property

With this done you no longer need to set the Font property in the Form’s Load event and you don’t need to set UserFont in the FornClosed event either. The data binding handles this for us.

The last thing to mention is the call to My.Settings.Save which you saw in the FormClosed event. This actually wasn’t necessary, it was added it for completeness. If you look in the Application tab of your Project Properties you’ll see a CheckBox with the caption “Save My.Settings on Shutdown” (see Figure 4). If this is checked (and it is by default) then Visual Basic will automatically save user settings just before the application terminates. The combination of this option and the visual tools to bind settings to form and control properties give you a no-code solution for implementing user settings.

Figure 4 – Enabling the automatic saving if user settings.

As you’ve seen, the addition of My to Visual Basic 2005, new classes to the .NET Framework 2.0 and new designers to Visual Studio 2005 vastly improves our ability to manage and use application and user specific settings in our applications.

Some Specifics on Generics

windsor — Wed, 03 Jan 2007 09:07:56 GMT

Generics are the most significant language addition to .NET 2.0. They allow for code re-use in ways not previously available and make it much easier to write type-safe, better performing code. That is, they help you turn runtime exceptions into compile-time errors while making your application run faster. Sound good?

What’s the Problem?
The classic example used to demonstrate the problem Generics solve is the general purpose collection. In .NET 1.1 collection classes like the ArrayList and HashTable are object based so they can store data of any type. Unfortunately this benefit has a cost, the lack of type safety. The user of the ArrayList cannot restrict the types it stores, which can potentially lead to runtime errors.

Dim al As New ArrayList()

al.Add(11)

al.Add(42)

al.Add(18.0)  ' will cause a runtime error in the for loop

Dim sum As Integer = 0

For i As Integer = 0 To al.Count

    sum += CInt(al(i))

Next

ArrayList al = new ArrayList();

al.Add(11);

al.Add(42);

al.Add(18.0);  // will cause a runtime error in the for loop

int sum = 0;

for (int i = 0; i < al.Count; i++) { sum += (int)al; }

The solution to this problem in .NET 1.1 is to create a strongly-type collection class by inheriting from CollectionBase (or DictionaryBase is you want HashTable like functionality). While this task is not difficult it is tedious and leads to code bloat. You have to write almost exactly the same code for each and every type which requires a strongly-typed collection.

Public Class IntCollection

    Inherits CollectionBase

    Default Public Property Item(ByVal index As Integer) As Integer

Get

            Return (CType(List(index), Integer))

        End Get

        Set(ByVal Value As Integer)

            List(index) = Value

        End Set

    End Property

    Public Function Add(ByVal value As Integer) As Integer

        Return (List.Add(value))

    End Function

    Public Function IndexOf(ByVal value As Integer) As Integer

        Return (List.IndexOf(value))

    End Function

    Public Sub Insert(ByVal index As Integer, ByVal value As Integer)

        List.Insert(index, value)

    End Sub

    Public Sub Remove(ByVal value As Integer)

        List.Remove(value)

    End Sub

End Class

public class IntCollection : CollectionBase

    public int this[int index]

        get { return ((int)List[index]); }

        set { List[index] = value; }

    public int Add(int value)

        return (List.Add(value));

    public int IndexOf(int value)

        return (List.IndexOf(value));

    public void Insert(int index, int value)

        List.Insert(index, value);

    public void Remove(int value)

        List.Remove(value);

A second problem is performance. Value types need to be boxed when being added to the collection and the unboxed when they are retrieved. This is a “double whammy” because not only do you pay the penalty for boxing but you also add more and more work to the garbage collection mechanism as the collection grows. Even if you’re storing reference types there is still some penalty for casting.

Using Generics
Generics are designed to address the issues stated above without sacrificing developer productivity. The idea is to allow classes to be parameterized by the types they store and manipulate. The type parameter or parameters, which are enclosed in angle brackets and separated by commas, can be added to a class or method declaration. The type parameter acts as a placeholder for the actual type that will be used at runtime. For example you could create a generic Stack class:

Public Class Stack(Of T)

    Private _items As New List(Of T)

    Public Sub Push(ByVal item As T)

        _items.Add(item)

    End Sub

    Public Function Pop() As T

        If _items.Count = 0 Then

            Throw New InvalidOperationException("Stack is empty")

        End If

        Dim index As Integer = _items.Count - 1

        Dim item As T = _items(index)

        _items.RemoveAt(index)

        Return item

    End Function

End Class

public class Stack<T> {

    private List<T> _items = new List<T>();

    public void Push(T item) { _items.Add(item); }

    public T Pop() {

        if (_items.Count == 0) {

            throw new InvalidOperationException(“Stack is empty”);

        int index = _items.Count – 1;

        T item = _items[index];

        _items.RemoveAt(index);

        return item;

In this case the type parameter is T (it is common practice to use a single capital letter as the name for a type parameter but you are free to use more descriptive names if you choose) so the type would be know as “Stack of T”. T is used as the type for the regular parameter to Push and the return type of Pop. It is interesting to note that it is also used as the type argument in the construction of the internal List of items. The type argument defines the specific type you wish to use for that instance of the generic class.

The .NET Framework 2.0 adds several new generic collection classes in the System.Collections.Generic namespace, the most commonly used being List<T> (the generic version of ArrayList) and Dictionary<K, T> (the generic version of HashTable).

Dim al As New List(Of Integer)

al.Add(11)

al.Add(42)

al.Add(18.0)  ' will cause a complie time error

Dim sum As Integer = 0

For i As Integer = 0 To al.Count

    sum += al(i)  ' no cast or unboxing required

Next

List<int> al = new List<int>();

al.Add(11);

al.Add(42);

al.Add(18.0);  //will cause a complie time error

int sum = 0;

for (int i = 0; i < al.Count; i++) {

    sum += al; // no cast or unboxing required

Generic Methods
You have seen adding type parameters to classes, you can do the same thing for methods. This can be done even if the class itself is not generic. To do this you use the same syntax style as with classes, adding the type parameter after the name of the method but before the regular parameter list.

Private Class Utility

    Public Function Max(Of T)(ByVal a As T, ByVal b As T) As T

        If a > b Then

            Return a

        End If

        Return b

    End Function

End Class

' usage of Max

Public Sub MaxTest()

    Dim u As New Utility()

    Dim i As Integer = u.Max(Of Integer)(7, 11)

    ' Use type inference

    Dim d As Double = u.Max(10.0, 42.42)

End Sub

private class Utility

    public T Max<T>(T a, T b)

        if (a > b) { return a; }

        return b;

// usage of Max

public void MaxTest()

    Utility u = new Utility();

    int i = u.Max<int>(7, 11);

    double d = u.Max(10.0, 42.42);  //OK, uses type inference

When using generic methods, the C# compiler is able to infer the type arguments from the types of the regular parameters passed so you do not have to explicitly state them.

Constraints
Time to “fess up”, the code for the Max method in the example directly above does not compile. The condition (a > b) causes a compiler error because it does not have meaning for all possible values of T. To get it to work you need to modify the code somewhat.

Public Class Utility

    Public Function Max(Of T)(ByVal a As T, ByVal b As T)

        If a.CompareTo(b) > 0 Then

            Return a

        End If

        Return b

    End Function

End Class

public class Utility

    public T Max<T>(T a, T b)

        if (a.CompareTo(b) > 0) { return a; }

        return b;

OK, it still doesn’t compile. Using CompareTo is a valid solution but it requires that the type assigned to T implement the IComparable interface. You need to indicate this constraint to the C# compiler. This requires one additional code change.

Public Class Utility

    Public Function Max(Of T As IComparable(Of T)) _

        (ByVal a As T, ByVal b As T)

        If a.CompareTo(b) > 0 Then

            Return a

        End If

        Return b

    End Function

End Class

public class Utility

    public T Max<T>(T a, T b) where T : IComparable<T>

        if (a.CompareTo(b) > 0) { return a; }

        return b;

Other common constraints are: requiring a particular base type for the type argument, indicating that the type argument must be a reference type or value type, and indicating that the type argument must have a default constructor.

Conclusion
Generics are better for you than Broccoli (assuming that easier to write, type-safe, performant code is important to you, if not the please do a Google search for Ruby to find material more to your taste). As you work with .NET 2.0 you will begin to get the “Zen of Generics” and then you will see that the immediate benefits of strongly-typed collections are really just the tip of the Iceberg<T> where T : Big, ICold.

Keep Client Applications Responsive with the BackgroundWorker

windsor — Thu, 09 Nov 2006 09:58:00 GMT

Many applications need to perform some kind of long-running task like downloading a file, performing a complex calculation, or retrieving data from a database. Executing these tasks can make your application become unresponsive and end up making your users anxious. Take too long performing the task and the user will be looking for the Task Manager to kill your application.

The solution to this problem is to execute the long-running task on a second (or background) thread. This allows the user interface thread to continue working keeping your application responsive, but it presents you with a new problem. Creating multi-threaded applications is difficult - well actually it’s easy - it’s doing so properly, following all the rules, and not coding yourself into an all night debugging session that’s truly hard.

To help address this issue Microsoft added the BackgroundWorker component to .NET 2.0. This component is easy to use and understand and makes programming multi-threaded applications (without explicitly creating and managing threads) much safer for the developer. The exploration of the BackgroundWorker will be done through the creation of a demo application.

For a more comprehensive discussion of the topics covered in this article and to see how to achieve the same results using previous versions of .NET, see Chris Sells three-part series entitled Safe, Simple Multithreading in Windows Forms (http://shrinkster.com/ddm).

Let's assume you have a simple application with a Button and a ProgressBar. The code below will simulate a long-running task by putting the user interface thread to sleep, one half second at a time, in a loop. The loop is used to allow the program to report progress back to the user via the ProgressBar.

Private Sub Button1_Click(...) Handles Button1.Click
Button1.Enabled = False
For i As Integer = 1 To 10
ProgressBar1.Value = i * 10
Threading.Thread.Sleep(500)
Next
MessageBox.Show("Done", "Demo")
Button1.Enabled = True
End Sub

As it stands, clicking the Start Button will begin the long-running task and, while the ProgressBar will be updated as we iterate through the loop, the rest of the application will be unresponsive. You will not be able to move or resize the form until the loop completes. The remainder of this post will discuss how to convert this code to run the loop on a background thread via the BackgroundWorker component. It will also show how to upgrade the application to allow the long-running task to be cancelled.

First, declare a private field for the BackgroundWorker. Then in the Form’s Load event handler, create the instance of the BackgroundWorker and set its WorkerReportsProgress and WorkerSupportsCancellation properties to True. These properties are set to False by default as a performance optimization.

Private WithEvents _worker As BackgroundWorker
Private _working As Boolean
Private Sub Form1_Load(...) Handles MyBase.Load
_worker = New BackgroundWorker
_worker.WorkerReportsProgress = True
_worker. WorkerSupportsCancellation = True
End Sub

Create an event hander for the BackgroundWorker’s DoWork event and copy the existing code from the Button’s Click event hander to the newly created method. The Button is going to be used to both start the long-running task as well as cancel it. In the Click event handler check if the BackgroundWorker is currently busy; if it is signal a request to cancel the task by calling CancelAsync otherwise begin the task by calling RunWorkerAsync. It is important to note that the call to CancelAsync does not immediately terminate the task, it just signals a request to cancel. The code running the task must check for the request and handle it appropriately (see below).

Private Sub Button1_Click(...) Handles Button1.Click
If _worker.IsBusy Then
    _worker.CancelAsync()
Else
    Button1.Text = "Cancel"
    _worker.RunWorkerAsync()
End If
End Sub

The code copied to the DoWork event handler needs to be modified slightly. The code in this event handler executes on a background thread so it cannot safely update the user interface, thus the line that originally set the Value property of the ProgressBar has to be changed. Replace this line with a call to the ReportProgress method of the BackgroundWorker passing the percent completed as a parameter. This will trigger the ProgressChanged event where we can safely update the ProgressBar. In addition, this code has to check for a request from the user to cancel the task which can be done by inspecting the CancellationPending property of the BackgroundWorker.

Private Sub _worker_DoWork(...) Handles _worker.DoWork
For i As Integer = 1 To 10
    _worker.ReportProgress(i * 10)
    Threading.Thread.Sleep(500)
    If _worker.CancellationPending Then
      e.Cancel = True
      Exit For
    End If
Next
End Sub

Private Sub _worker_ProgressChanged(...) Handles _worker.ProgressChanged
ProgressBar1.Value = e.ProgressPercentage
End Sub

Finally, the BackgroundWorker raises the RunWorkerCompleted event to notify the user interface that long-running task is done, either because it completed normally or because it was cancelled.

Private Sub _worker_RunWorkerCompleted(...) Handles _worker.RunWorkerCompleted
Dim msg As String = "Done"
If e.Cancelled Then
msg = "Cancelled"
End If
Button1.Text = "Start"
MessageBox.Show(msg, "Demo")
End Sub

This short example demonstrates the basic use of the BackgroundWorker. That is executing a long-running task on a background thread, showing progress, and allowing the user to cancel.