ToolStripStatusLabel not behaving like other typelike controls

Question

Im having some trouble with a ToolStripStatusLabel in Winforms application. To better explain i have some code here

bottomLbl.Text = "Adding file(s) to list...";
this.Text = "Adding file(s) to list...";

listAllFiles(carrier, type, chkListBox, withDestSystem, listBox, cmbBox);

bottomLbl.Text = "Done!";
this.Text = "Done";

What i dont get is, that this.Text does change to "Adding files.." but not bottomLbl even though i set it to do so before this.text. Both controls get the "Done!" text after the listAllFiles function has been run.

But is there something special i have to do on a ToolStripStatusLabel ?

Answer 1

You need to refresh the form before calling the function

bottomLbl.Text = "Adding file(s) to list...";
this.Text = "Adding file(s) to list...";
this.Refresh();

listAllFiles(carrier, type, chkListBox, withDestSystem, listBox, cmbBox);

bottomLbl.Text = "Done!";
this.Text = "Done";

Answer 2

It looks to me like you're setting up a condition where we can't reliably predict which of the UI updates will be displayed to the screen before the final UI updates get displayed.

You're doing some UI updates (e.g. label1.Text = ...) before performing a time-consuming process (listAllFiles()). After that completes, you're doing some more (final) UI updates.

One or more of the "early" UI updates gets queued to be displayed as soon as the main thread (the UI thread) has some time to refresh the window.

What we don't necessarily know is which types of controls (ToolStripStatusLabel versus Label, for instance) internally consider the setting of their Text property to be something that can't wait to be displayed.

It sort of sounds like one of those types will allow its Text property to be updated without waiting until it gets displayed (that's a non-blocking call) while the other type will ensure that the change gets displayed before proceeding (that's a blocking call).

Even if you determine what their behavior is through testing, it could change in the future or in different environments.

Optionally, you could customize one or more of those types to specify whether to block or not. You could do this by either calling Refresh() or Invalidate(). But I recommend an alternative approach:

Keep the load of tasks performed in the UI thread to a minimum. This way, the UI is more responsive to the user and you can have more confidence that your UI updates will be displayed quickly.

Generally, this means we should perform all time-consuming work in a different thread, asynchronously, and we can update the UI with the status of that work as frequently as we like. To accomplish this, I recommend looking into the BackgroundWorker type. Its purpose is to perform time-consuming work asynchronously while maintaining a responsive UI.