WPF Method to wait for DocumentCompleted Event

Question

I know this has been asked before, but I don't think these solutions are flexible. The DocumentCompleted event should be used to determine when the load has completed, not as a method for performing work. If you need to perform several different tasks that each have to navigate several times, placing the logic in the DocumentCompleted event turns it into a messy switch/case router that is hard to read and maintain.

You need something that can actually wait during your method performing navigation so you can continue your task in the method you are already in. My first though is an actual Wait() method.

I would think something like this is close:

void WaitForLoad()
    {
        isLoading = true;
        while (isLoading)
        {
            if (Application.Current == null) break;
            Dispatcher.CurrentDispatcher.Invoke(DispatcherPriority.Background, (DispatcherOperationCallback)delegate(object unused) { return null; }, null);
        }
    }

And set Isloading to false in the DocumentCompleted event.

You should be able to just call this method after whatever action will cause a pageload. It works, it has some issues.

1) it sends the CPU usage for the app up to 35% until the page has loaded, even if nothing else is happening.

2) if the application tries to close while its running, the loop will keep running and leave the app open with no windows, hence the need for the break when the app is null.

Can this be fixed, or am I coming at this all the wrong way?

Edit: I tried implementing the ManualResetEvent solution below, but it led to several other issues that I am not sure can be resolved without creating a messier situation than the one above. Since the WebBrowser is on the UI, locking the thread stop the entire app. If the work is done on the background thread it can be locked, but then accessing the WebBrowser becomes very difficult.

So you are looking for a way to block a thread while waiting for the document to finish loading? — Tejs, Sep 06 '11 at 17:55
I am not familiar with that term, "block", as applied to a thread. It sounds like what I want, but I am not sure. Searching Google for "Block" is not helpful, as block has a different and much more common meaning in code. — Kyeotic, Sep 06 '11 at 17:58
Blocking a thread means it no longer executes until it is unblocked; aka, the `lock` statement will block all threads and only let one thread through the critical section at a time. Google Thread Blocking. — Tejs, Sep 06 '11 at 18:00
Synchonization events look promising, I will see if I can make this work with a ManualResetEvent. Thank you for the tip. — Kyeotic, Sep 06 '11 at 18:07

score 2 · Accepted Answer · answered Sep 06 '11 at 18:03

2

In your situation, it sounds like you want a specific thread to block while waiting for the document to load. In that case, you would do something like this:

  protected ManualResetEvent _resetEvent = new ManualResetEvent(false);

  public void WaitingThread()
  {
      _resetEvent.WaitOne();

      // Do stuff after the web browser completes. 
  }

  public void LoadWebPage()
  {
      webBrowser.Navigate(new Uri(url));
      webBrowser.DocumentCompleted = (s, e) => { _resetEvent.Set(); };
  }

Basically, when the document completes, you signal the event and any threads waiting on the event unblock and continue executing.

answered Sep 06 '11 at 18:03

Tejs

40,736
10
68
86

Just found ManualResetEvent on msdn, this looks like what I was after. However, since several methods will be navigating, it seems like it might be better to actually have a documentcompleted event, instead of instantiating with a lamba ever time. Am I wrong? – Kyeotic Sep 06 '11 at 18:10
It's all going to depend on what your logic is going to be. – Tejs Sep 06 '11 at 18:13
I'm starting to run into the limitations of this method. The waiting thread can't work on the browser, since the browser exists on the UI thread. If you move it to the background thread, the invoke's start to get messier than the original switch/case routing mess. – Kyeotic Sep 06 '11 at 19:49
You shouldn't be blocking the UI thread; your code on document completed should either go in the document completed event and dispatch events on the Ui thread, or put your code in a separate thread and then wait for the document completed event to be raised. It sounds like you are blocking on the UI thread, which is something you should not do. – Tejs Sep 06 '11 at 20:07
That's my point though. When my code is not on the UI thread, it cannot access the webbrowser, which is on the ui thread. Then you either carve the logic back up into multiple groups, or use invokes to access everything; either way its not any cleaner. – Kyeotic Sep 06 '11 at 21:25

score 0 · Answer 2 · answered Sep 06 '11 at 17:56

I noticed that you use Dispatcher.CurrentDispatcher.Invoke this is good for calling your method that somehow updates UI from another thread. But from code provided, I don't see any code in other thread then UI. So

Run that code on another thread.
On the close event of your application you can make isLoading=false; And more, if the method invoked is kind of long running stuff insert

if(!isLoading) return;

//or in some other app suitable way break an execution

EDIT:

Even better way to handle this in multithreading, then just simply relay on boolean variable, is using some Synchonization object

It was merely a method for sleeping without causing the UI thread to lock. I want the rest of the app to remain usable while the page is loading. — Kyeotic, Sep 06 '11 at 18:04

WPF Method to wait for DocumentCompleted Event

2 Answers2