UI changes are being updated on a thread, and unsure of which thread is performing the update

Question

In a given form, the code is referencing a static element on the main form and updating it.

SomeRandomForm.cs

MainForm.Instance.UpdateSomeLabel("hello world");

Now it isn't obvious if this code that is updating the main form's static instance of a label (or whatever it may be) is on the UI thread or not.

Is it possible for me to wrap this method call (UpdateSomeLabel) somehow to ensure it is being updated on the UI thread only? I want to actually modify the method UpdateSomeLabel to ensure this updated only happends on a UI thread.

Just trying to clean-up this app to make it safe.

FMM · Accepted Answer · 2012-09-12T20:22:13.793

3

You should familiarize yourself with the Invoke(...) and BeginInvoke(...) methods and determine what semantics you need for this cross-thread update. Do you want to fire-and-forget, and not wait for the message pump to get back around to your text update? Use BeginInvoke(...). Do you want the thread to block until the UI update has occurred? Use Invoke(...).

Also, bear in mind that if the form may potentially be disposed, or hasn't been shown yet, you need to check more than just the InvokeRequired flag on the form before calling Invoke(...) or BeginInvoke(...). If there is a potential for this case, your logic should look something like this:

public void DoSomeUpdate(string text)
{
    if(this.IsDisposed || (!this.IsHandleCreated))
    {
        // error condition; run away!
        return;
    }

    if(this.InvokeRequired)
    {
        // BeginInvoke or Invoke here, based on the semantics you need
        return;
    }

    this.UpdateSomeLabel(text);
}

Comment please if anything here is unclear.

Update

There has been some commentary regarding checking for whether the control's handle has been created or if it has been disposed.

Regarding the former case (IsHandleCreated), that's definitely something you can assume beforehand in many cases; however, not all cases. If you're not dynamically creating controls, and your background thread stuff is being triggered via the UI thread, you're probably safe. However...

If there's any hint of a possibility that the background thread task could be in-flight long enough for you to click the 'X' on your form and close it (thereby disposing it), then you'll get a nice exception if you don't check IsDisposed before calling Invoke(...) or BeginInvoke(...). It's similar to (in C) checking for malloc(...) returning something non-zero. It does happen. As tedious as it is, an application author is obligated to care about these potential error cases. This does add complication; however, it's important, especially if you don't want your app to crash. Failing to properly account for IsDisposed and IsHandleCreated when calling Invoke(...) or BeginInvoke(...) exposes you to the possibility of crashing your app. You can avoid that crash with a few extra lines of code.

edited Sep 12 '12 at 20:22

answered Dec 01 '11 at 16:44

FMM

4,289
1
25
44

This is essentially what is suggested by StyxRiver in the post below. The StyxRiver solution wraps this very elegantly. http://stackoverflow.com/questions/661561/how-to-update-gui-from-another-thread-in-c – Eric J. Dec 01 '11 at 17:50
@EricJ.: no, it's not. StyxRiver ignores the possibility of badness happening when the handle hasn't been created yet, or if the form has been disposed. StyxRiver's solution will cause bad things to happen if his method gets called before the form's handle has been created or after the form has been disposed. He also doesn't call out the fact that you need to decide whether to use `Invoke(...)` versus `BeginInvoke(...)` depending on the call semantics you need. – FMM Dec 01 '11 at 18:09
@FMM - The question to the answer that you're referring to is 'what is the simplest way?' Not a single answer to that question took into account those possibilities. That wasn't the question. The simplest way was just that, quick little fire and forget, Invoke or BeginInvoke, which my extensions contain both. That was only a snippet of the code. Simplest, the answer to the question asked. – StyxRiver Sep 10 '12 at 20:33
@StyxRiver: "Simplest" is a tricky term. You could say it's "simplest" to never check the return value from `malloc(...)` as well, but it's also the wrong thing to do =) – FMM Sep 12 '12 at 20:24
@FMM There's always been a pretty distinct difference between simplest and right, especially in what we do. Simple usually remains consistent, right depends on context: how complicated the question or the app, how exposed the API to other devs, etc. Let's say the user asks "what's the simplest way to divide two integers? Simplest would be a basic `double x = y / z;` Right would take into account the possibilities of `DivideByZeroException`, parameter validation, etc. – StyxRiver Sep 13 '12 at 12:22
@FMM But, that may be just differences in the way we both define 'simplest'. Either way, +1 to you, your answer is correct and informative. =) I just prefer extensions for this sort of event so I don't have to repeat my method (DRY principle ) across `x` number of forms or controls. – StyxRiver Sep 13 '12 at 12:28
1

Both the old shoe and the glass bottle are "simple" as well: http://weblogs.asp.net/alex_papadimoulis/archive/2005/05/25/408925.aspx – FMM Sep 14 '12 at 13:49
1

However (and +1 to you) an extension is really handy here; kudos. – FMM Sep 14 '12 at 13:50

StyxRiver · Answer 2 · 2012-09-13T12:29:39.637

FMM had a point with his comment on his answer. I did not take into account the possibility that a handle would not have been created or the control was disposed. The question that was asked (on the other post referred to) was "what is the simplest way?" That extension is pretty simple, don't you agree?

That being said, I also only gave him a small snippet of the extension. A similar 'Invoke' exists as well.

using System;
using System.Windows.Forms;

public static class Extensions
{
    /// <summary>
    /// Executes the Action asynchronously on the UI thread, does not block execution on the calling thread.
    /// </summary>
    /// <param name="this">The control responsible for performing the <param ref="code" /></param>
    /// <param name="code">The Action to be performed on the Control.</param>
    public static void UIThread(this Control @this, Action code)
    {
        // Check for error
        if (@this == null || !@this.IsHandleCreated || @this.IsDisposed)
        { return; }

        // Execute code
        if (@this.InvokeRequired)
        { @this.BeginInvoke(code); }
        else { code.Invoke(); }
    }

    /// <summary>
    /// Executes the Action on the UI thread, blocks execution on the calling thread until Action has been completed.
    /// </summary>
    /// <param name="this">The control responsible for performing the <param ref="code" /></param>
    /// <param name="code">The Action to be performed on the Control.</param>
    public static void UIThreadInvoke(this Control @this, Action code)
    {
        // Check for error
        if (@this == null || !@this.IsHandleCreated || @this.IsDisposed)
        { return; }

        // Execute code
        if (@this.InvokeRequired)
        { @this.Invoke(code); }
        else { code.Invoke(); }
    }
}

It even checks to make sure the Control has been created in the first place, rather than throw a possible NullReferenceException, which can be a possibility with Extensions.

score 1 · Answer 3 · edited May 23 '17 at 12:03

1

The most elegant means I have ever seen to ensure a WinForms method runs on the UI thread is the answer from StyxRiver (not the accepted answer, scroll down) in this post:

How to update the GUI from another thread in C#?

Using the extension method he proposes, you can compactly and elegantly ensure the update happens on the UI thread.

edited May 23 '17 at 12:03

Community

1
1

answered Dec 01 '11 at 16:07

Eric J.

147,927
63
340
553

UI changes are being updated on a thread, and unsure of which thread is performing the update

3 Answers3