Alternatives to the BackgroundWorker?

[JoePage]

Some of you may remember my thread I posted a couple weeks ago looking for an alternative to application.doevents. For those that don't I foolishly started using application.doevents in my project, to prevent the form from locking up, well it worked great until I started adding more features to the program, then I started getting so many odd bugs, everytime I found a workaround for the bugs, it would cause the program to bug out somewhere else.

So the background worker was suggested, although in my case I can't use it. I have a class and in the class I have a sub that I call from a seperate form. When the sub is called it starts going through a loop that is completing different processes. This class sub has to access controlson this form. Such as a selecting items in a listview, parsing items in a listview, enabling buttons etc, and I also need to keep my parameters on this sub.

So basically I foundout I can't use the background worker. So what is an alternative to this? I need to do something I can't stand seeing the application I worked so hard on having al the bugs from .doevents. Also it would be too much work to go back and restructure the application.

[jmcilhinney]

This issue is simple. You have some work that needs to be done in the background so as to maintain a responsive UI but you also have some UI updates interspersed in that work and they cannot be done in the background. Background work means multi-threading but all UI access must be done on the UI thread. No matter what you end up doing, you're going to need to change your design. The design you have now is obviously bad, and that's the root of your troubles. You say that you have this work going on in a separate class but then that class is directly accessing controls on a form. Not good. If you're accessing controls on the form then everything may as well be in the form because you're not making anything cleaner or easier.

Basically, if you try to keep things the way they are but get them to work then you're in for a world of pain. The best option would be to redesign the whole thing properly. Put the non-visual work into a class dedicated to that work and keep all the visual stuff in the form. Your class can do its work on a separate thread and then raise events whenever the UI needs to be updated. The form can then handle those events and the appropriate updating. An example of a class that does work in the background and raises events for UI updates is... the BackgroundWorker. You can either use a BackgroundWorker inside your class or you can implement your class such that it works in a similar way to the BackgroundWorker. Here is a simple example of such a class:

Public Class AsyncThing
 
    Private context As SynchronizationContext = SynchronizationContext.Current
 
    Public Event DoingSomething As EventHandler
    Public Event DoneSomething As EventHandler
 
    Public Sub DoSomething()
        Dim t As New Thread(AddressOf DoSomethingCore)
 
        t.Start()
    End Sub
 
    Private Sub DoSomethingCore()
        'Do some work.
        Thread.Sleep(5000)
 
        'Raise the DoingSomething event on the thread that created the current instance.
        context.Post(AddressOf RaiseDoingSomething, Nothing)
 
        'Do some work.
        Thread.Sleep(5000)
 
        'Raise the DoingSomething event on the thread that created the current instance.
        context.Post(AddressOf RaiseDoingSomething, Nothing)
 
        'Do some work.
        Thread.Sleep(5000)
 
        'Raise the DoneSomething event on the thread that created the current instance.
        context.Post(AddressOf RaiseDoneSomething, Nothing)
    End Sub
 
    Protected Overridable Sub OnDoingSomething(e As EventArgs)
        RaiseEvent DoingSomething(Me, e)
    End Sub
 
    Protected Overridable Sub OnDoneSomething(e As EventArgs)
        RaiseEvent DoneSomething(Me, e)
    End Sub
 
    Private Sub RaiseDoingSomething(dummy As Object)
        OnDoingSomething(EventArgs.Empty)
    End Sub
 
    Private Sub RaiseDoneSomething(dummy As Object)
        OnDoneSomething(EventArgs.Empty)
    End Sub
 
End Class

[JoePage]

Thanks JMC I was hoping you would come back here. I like the idea of the class example you posted.

So here is my only question. If I was to get rid of the code that accesses the form directly, Would I be able to make a call back to the main form, to an event from this class in the donesomething example you posted. Kind of like this.

I have an event in my form like this

private sub DoneMyClassWork()
button1.enabled = true
button2.enabled = false
end sub

And in my class I call that sub from the doneevents?

Private Sub RaiseDoneSomething(dummy As Object)
        OnDoneSomething(EventArgs.Empty)
        DoneMyClassWork()
    End Sub

Sorry if I got it all wrong. Still kinda new to me.

[jmcilhinney]

That's not an event. It's just a method and you are calling that method from this other class and that's bad design. The point is that the other class simply raises the event and doesn't care beyond that. The form handles the event and then does it's own work. That means that you form has a handler for the DoneSomething event of your object and in that event handler it enables its own Buttons. The UI work is done in the UI, i.e. the form. The object responsible for the background work does ONLY the background work.

[JoePage]

Awesome, I understand now. Thanks for the help.

[JoePage]

I have one question. I moved everything over to my main form, and I am using the background worker now. My UI no longer hangs, but I am having a hard time cancelling the thread when the cancel button is clicked on my UI.

I think the button is working properly, I just don't think it is shutting down the thread quick enough. I would like for it to abort the thread right when the button is clicked. The thread isnt too extensive so I am not sure why it isn't I must be doing something wrong.

I am going to post some examples of the way I am doing it.

Public Sub New()
        InitializeComponent()
 
        bw.WorkerReportsProgress = True
        bw.WorkerSupportsCancellation = True
        AddHandler bw.DoWork, AddressOf bw_DoWork
        ' AddHandler bw.ProgressChanged, AddressOf bw_ProgressChanged
        AddHandler bw.RunWorkerCompleted, AddressOf bw_RunWorkerCompleted
    End Sub

My DoWork event

Private Sub bw_DoWork(ByVal sender As Object, ByVal e As DoWorkEventArgs)
 
        If bw.CancellationPending = True Then
            e.Cancel = True
            WorkEventRunning = False
            
        Else
 
            CheckForIllegalCrossThreadCalls = False
            Dim worker As BackgroundWorker = CType(sender, BackgroundWorker)
            'my long winded event
             ' more of my long winded event.
 
       End if

My Cancel Button code:

Private Sub ToolStripButton2_Click_1(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles ToolStripButton2.Click
        'Stop
        If bw.WorkerSupportsCancellation = True Then
            WorkEventRunning = False
            bw.CancelAsync()
            bw.Dispose()
 
        End If

And my workcompleted

Private Sub bw_RunWorkerCompleted(ByVal sender As Object, ByVal e As RunWorkerCompletedEventArgs)
        If e.Cancelled = True Then
            'canceled
            WorkEventRunning = False
        ElseIf e.Error IsNot Nothing Then
            MsgBox(e.Error.Message)
        Else
            'done
        End If
    End Sub

[jmcilhinney]

First things first, why are you setting CheckForIllegalCrossThreadCalls? There is no reason to be doing so because the only places you should be updating the UI is in the ProgressChanged and RunWorkerCompleted event handlers, which are executed on the UI thread. Your code implies that you might be updating the UI directly from inside the DoWork event handler or a method called from the DoWork event handler. Get rid of that line and run the code again and if you are updating the UI on the wrong thread then an exception will be thrown and you know where you need to change your code.

As for the question, the issue is that you are only checking for cancellation once at the very start of the DoWork event handler. If the user requests cancellation after that it will do them no good because you never check for it. When the user requests a cancellation, that's all that happens: it is requested. It's up to you to check for that request repeatedly because it's only by checking that you will detect and only if you detect can you actually cancel. For instance, if you have a loop then it's up to you to check for a cancellation request on each iteration and, if you detect a request then you must end the loop explicitly. If you don't have a loop then it's up to you to find waypoints in your code that represent logical places for you to check for a cancellation request and end the background process if you find one.