Question

We have a button click event that starts a long running task that updates the status bar labels and progress control to give user feedback. Before we moved the task to a seperate thread we noticed the status labels {label.text = “some message”; }(in general) would update immediately while the progress bar and some custom controls often would not update until the function finished and the main UI thread started sending messages again ( which we realized makes sense considering the main UI thread).
But this lead us to wonder – Do some windows controls repaint directly instead of being issued a WM_Paint message?

Answer 1

Your findings are pretty contradictory from what I know about .NET controls. The common rule is that changing the Text property or altering a property like ForeColor or BackColor merely causes the Invalidate() method to be called. Which ultimately causes a WM_PAINT message to be delivered when the UI thread starts pumping messages again. You can call the control’s or the Form’s Update() method to force any pending paints to be performed before entering the slow code. This is all entirely standard Windows behavior.

A special case is the ProgressBar control. The native Windows implementation for it updates the bar length directly. That’s compat behavior, this control often is used in code that doesn’t pump properly.

TextBox has special painting behavior, it partly paints directly to the window instead of going through the WM_PAINT message handler. That’s legacy behavior way back from Windows 2 when it needed to work reasonably on a 386SUX machine. But that’s not relevant in this case.

Of course, rather than fretting about this you should just never get yourself in a place where any of this matters.