UI Wait Method

[Bruce Fox]

Hi Guys,

I have a list of web pages that load into a CheckedListBox at run time.

These pages are user selectable.

Scenario One: Single Selection
The application loads the selected web pages and parse's the content, this could take a short time, or it can take a few minutes. - No problem here. I am using a BackgroundWorker to perform the parse.

Scenario Two: Multiple Selection
My query relates to a method that I can employ to deal with iteration of the CheckedListBox to process the next selected web page back on the UI.

I need to wait till the BW has finished before we can move on to the next page.

To illustrate, I could use something like the following on the UI:

Do Until blnX
    Application.DoEvents()
Loop

For example blnX could be the BW completed.

In summery, I'm sure the above example is not best practice to hold up the UI's iteration of the CheckedListBox, until the current web page is processed.

Ideas?


Cheers.

[Shaggy Hiker]

If you are really using a BackGroundWorker, it will raise an event when it completes, so why not send it on its way, then wait for the event signaling completion. If you have a series of them, then when one finishes, just send the other off. Of course, that could be a bit silly, as you would spend all your time waiting for a background process to finish, which somewhat defeats the purpose.

If you have multiple background workers working on multiple items, then you could just keep a list of which ones have completed, and as each one signals completion, you could remove it from the list. Once the list reaches 0, move on.

[Bruce Fox]

Hi Shaggy_Hiker,

it will raise an event when it completes, so why not send it on its way, then wait for the event signaling completion.

That's what I am currently doing. The problem is I have to tie up the UI while it's waiting.
Not that that matters per se. However the method I am using is the Do.. Loop as described above. I loath to use DoEvents() in the manner I demonstrated in .Net as I don't think it's appropriate - maybe it is?

[formlesstree4]

That's what I am currently doing. The problem is I have to tie up the UI while it's waiting.

Why? Create a dialog that is unable to be closed by the user and close it when the BG Worker Work completed event is raised. Dialogs stop the interface behind it from being modified/used.

[Shaggy Hiker]

I was not understanding that you had to tie up the UI, I was thinking that you were doing it just for fun. If formlesstree4 is correct in assuming that you don't want the user to do anything until the background worker completes, then I would say that I have used that very suggestion in one of my own programs. In fact, I have the dialog cycling through all kinds of colors, so the user gets hypnotized while it is running. The form is shown as a modal form, and the Finished button that will close it is not available until the process completes. Actually, now that I think about it, there is a Cancel button that is always visible, and which will allow the user to cancel the background process (I'm using a thread, not a BackGroundWorker object, but you can cancel either) at any time, but the Finished button doesn't even become visible until the process completes. Canceling will terminate the background process and close the form, while Finished will just close the form (once the process has completed). I seem to remember that the only difference is that the Finished button gives the user feedback to indicate that the process completed successfully.

[Bruce Fox]

Thanks for the feedback Guys.

Actually, the issue isn't with what the user can or can't do or for that matter tying up the UI.
By using the Do-Loop, it isn't tied up.

That said, I was questioning the use of the do-Application.DoEvents()-loop as best practice whils I wait for the BGW to complete. I need to do this as the App in the UI has more pages to process, it is that fact that I have to have that iteration on hold pending the BGW completion.

I hope that clears things up


Cheers.

[formlesstree4]

I'm sorry, but I seem to be confused as to what the BGW does, or what the application does for that matter. Would you mind explaining a bit more clearly what exactly is going on, and what exactly needs to happen to the UI?

[jmcilhinney]

I agree with what's been suggested so far. Have your form display a modal dialogue that cannot be dismissed by the user, which would involve setting ControlBox to False. On that dialogue, set the title to "Please Wait..." or the like and add a ProgressBar. Now you have that dialogue run the BackgroundWorker. That way the dialogue remains responsive, i.e. updates the ProgressBar, so the user is kept informed. If you cannot calculate real progress then set the Style to Marquee.

[Shaggy Hiker]

Doing a perpetual loop is definitely not a good way to do things, but I'm now a bit confused as to why you have it in the first place. I read it that you have some number of items to process. Let's say that there are 4. The background worker is launched on item 1, when if finishes that it starts on 2, then 3, then 4. Right now, it looks like you are waiting for it to finish 1, then starting it again with 2, and so forth. The leaves the question of why I chose 4 as an example, but we can ignore that for now.

What I was suggesting initially was that you launched the background worker on the first item, and sat around waiting for it to raise the completion event. In the event handler, you would look to see that there were more items to process, and if there were, then you would launch the background worker with the next item, and so forth. I don't see how the wait comes into it other than to waste time and processor cycles.

[Bruce Fox]

What I was suggesting initially was that you launched the background worker on the first item, and sat around waiting for it to raise the completion event. In the event handler, you would look to see that there were more items to process, and if there were, then you would launch the background worker with the next item, and so forth.

That is exactly what needs to happen, and does.

The question is with the Do..Loop on the UI to wait then kick of the next page and then the next... etc.

I'm currently doing it with the Do Loop as previously mentioned.

To clarify: I currently do wait around until the BGW is complete, it is doing that, and there is no issue with the UI freezing or becoming unresponsive.

My question relates to a way to have the UI 'wait' until the BGW has finished, so it can be re-started with the next page for process.

Keep in mind this works. I am just not sure that using the Do-DoEvents()-Loop (in the UI) is the best way <<< That is the concern

I hope that helps.

[formlesstree4]

Ok, so you're just asking if what you're doing is the "best" or "proper way" right? I would just slap a dialog on top of the form and then programatically go to the next 'page' on the completion of the background worker.

[Bruce Fox]

@ JM, I re-read you post. I may be able to work with that as the dialog (as modal) will hold up teh UI until it is closed by the BGW completeing... That is my thought.

[Bruce Fox]

Ok, so you're just asking if what you're doing is the "best" or "proper way" right? I would just slap a dialog on top of the form and then programatically go to the next 'page' on the completion of the background worker.

Concur, I think that is what JM was relating to...

Cheers.

[jmcilhinney]

This is starting to make less sense to me too. You have a Do loop and in that you call DoEvents so that the UI remains responsive. What's the point of that? You're using a BackgroundWorker so the UI will inherently remain responsive. If what you want is a way to know when the background task finishes, that's exactly what the RunWorkerCompleted event is for.

If you actually want the UI to wait, i.e. not let the user do anything, while the background task is processing then what's the DoEvents for? Is it just so the UI can repaint? If so then that's bad because it's going to respond to all events, including user input. In that case you should do as I suggested in my previous post. The UI will remain responsive in that it will continue to paint, but the user cannot perform any other tasks. They are also informed of that fact by the "Please Wait..." message.

EDIT: Hmmm... looks like a lot happened while I was typing.

[Bruce Fox]

EDIT: Hmmm... looks like a lot happened while I was typing.

Cheers


I know it's sometimes hard to articulate a problem in a few paragraphs.
For anyone else, and to show I'm not insane (I know that my be questionable)... Here is a psedo example.

UI:

        For Each itm In Me.clbLinks.CheckedItems

            Me.WebBrowser.Navigate(itm.ToString)

        Next

And

    Private Sub WebBrowser_DocumentCompleted(ByVal sender As Object, ByVal e As System.Windows.Forms.WebBrowserDocumentCompletedEventArgs) Handles WebBrowser.DocumentCompleted
 
        BackgroundWorker.RunWorkerAsync(WebBrowser.Document)

   End Sub

This won't work as the clbLinks.CheckedItems will finish before the first one completes.

I'll post my current way next.

[Bruce Fox]

So, you could do:

        For Each itm In Me.clbLinks.CheckedItems

            Me.WebBrowser.Navigate(itm.ToString)

            Do Until BGW is Complete
                  Applications.DoEvents()
            Loop


        Next

    Private Sub WebBrowser_DocumentCompleted(ByVal sender As Object, ByVal e As System.Windows.Forms.WebBrowserDocumentCompletedEventArgs) Handles WebBrowser.DocumentCompleted
 
        BackgroundWorker.RunWorkerAsync(WebBrowser.Document)

   End Sub

[Bruce Fox]

So my way forward will be to use a Modal Form() with progress etc (bells and whistles) and have the BGW completion close it (and re-open it based on the number of checked items)

This method, will negate the use of the 'bad' Do Loop in the UI.

Happy days - unless I have overlook the obvious