How do I halt outdated UI updates?

Question

Let's say I have a C# program with a GUI, and the update/refresh/display of the GUI takes 0.2 seconds.

Say, while it is still computing the display process (within this 0.2 seconds), a new update request is given, so the current one is outdated. How can I make it stop doing this meaningless outdated work to start computing for the new request?

It might not be only about UI update too. Perhaps, for any function call, how can I make it so it will become "If another of the same call is issued, abandon the current work and go with the new data/situation instead"?

Thanks.

Answer 1

You're talking about some fairly advanced threading issues. Using the built-in system control structure, there's no way to prevent the message loop from completing any more than there is a method for interrupting (gracefully) another method.

Now, if this capability is very important to you, you COULD build all custom controls and within your control's painting code you could check (in a thread-safe manner, of course) a boolean value indicating whether or not painting should continue.

But if I can take a stab in the dark, I'm going to guess that you're not actually explicitly doing any multithreading. If this is the case, then the scenario that you describe can't ever actually happen, as the process of refreshing the GUI is going to complete before another one can begin (namely, this anonymous process you're describing that calls for another refresh or deems the current one stale). Because code on the same thread executes sequentially, there's really no opportunity for an unrelated piece of code to cause an update.

The semantics of how and when repaints take place (the difference between Invalidate() and Refresh(), and their respective impacts on this logic, for example) is a topic that's probably really not of interest to you. Just know that if you're...

• Doing multithreading, then you'll have to implement your own code for checking whether or not the current operation should continue (for the UI, this means custom controls with this logic in the paint logic)
• Not doing multithreading, then what you describe can never happen.

Hope this is helpful!

Answer 2

One possible way is to start off a thread that updates the GUI and abort it and start another. This is generally not a recommended practice because of the horrible state of thread management in C# but you should be able to get around it without worrying.

public static class ControlExtensions
{
  public static TResult InvokeEx<TControl, TResult>(this TControl control,
                                            Func<TControl, TResult> func)
    where TControl : Control
  {
    if (control.InvokeRequired)
      return (TResult)control.Invoke(func, control);
    else
      return func(control);
  }
}

public partial class Form1 : Form
{
  public Form1()
  {
    InitializeComponent();
  }

  Thread guiUpdateThread = null;
  public void BeginLongGuiUpdate(MyState state)
  {
    if (guiUpdateThread != null && guiUpdateThread.ThreadState != ThreadState.Stopped)
    {
      guiUpdateThread.Abort();
      guiUpdateThread.Join(); // wait for thread to abort
    }

    guiUpdateThread = new Thread(LongGuiUpdate);
    guiUpdateThread.Start(state);
  }

  private void LongGuiUpdate(object state)
  {
    MyState myState = state as MyState;
    // ...
    Thread.Sleep(200);
    this.InvokeEx(f => f.Text = myState.NewTitle);
    // ...
  }
}

Answer 3

Perhaps, for any function call, how can I make it so it will become "If another of the same call is issued, abandon the current work and go with the new data/situation instead"?

Why would you want that? You would lose all provability in your code. You would never be able to ensure a consistent state in your system. If you want to simulate it, just mess with the PC. Design a program that arbitrarily pushes the PC back to the top of any method that it is in. You would quickly see the system devolve.

Answer 4

I don't knwo if this maps to what you need, but here goes. One way to achieve this kind of behavior is to reverse the problem and delay the actual rendering.

Any time you get a request or change, fire off a timer. Every request coming in will either start or restart the time. When the timer actually elapses, carry out the rendering. It does not do exactly what you describe, but it might actually do what you need in the end, which is not to render for each request because rendering takes too long.

If you do not have continuous requests, this works fairly well. Obviously, if you do, you never get anything displayed...