Possible threading issue or just bad code?

[UncleRonin]

This is how it stands: I have a program with a main form which has MDI children. The main form includes a status bar and methods for changing the various labels (these methods are public).

Now, I call normal methods on the children forms which use these status methods and a lot of the time the status labels are never updated. I've tried adding MsgBoxes after the calls to the main status methods - the labels update correctly if the MsgBox is displayed.

I really dont get why this happens? Is the window not updating or painting correctly so the labels only display after a certain period or what? I have a child method which updates the status labels in phases and even if a particular phase takes a long time, the label doesn't update. The weird thing is that I update a progress bar at the same time as the labels and this updates correctly.

I am completely lost, this doesn't make any sense. Can anyone help me?

 

[JohnH]

Sounds as you are running continuous processes in mdichilds, an "Application.DoEvents" after the call to update mdiparents label could do the trick. Other than that i don't know, never experienced any particular issues with such mdi setup. The very basic test 'button on mdichild sets text in mdiparent' performs flawlessly, of course.

 

[UncleRonin]

Thanks for the reply. I really dont get this problem. It happens with automatic or manual processes. If I click an update button it is supposed to update the labels BEFORE it does anything but the label still doesn't update (unless I have a MsgBox), whether it had text or is empty.

I had a problem like this a long time ago, also with VS2005 and 2.0, where some events never occurred. Is it possible that these calls never complete or never take place? (This shouldn't be the case but you never know)

*sigh* I'll give the .DoEvents a look at but I'll probably just remobve the status updates and leave the progress bar by itself.

 

[jmcilhinney]

What is happening is that the Text property of the object is being set but the thread is too busy doing something else to update the UI. Displaying the message is forcing the UI to be refreshed. You can call Refresh on the StatusStrip and it will be redrawn. You may be able to call Refresh on the individual labels instead, which would be more effcient than redrawing the whole strip.

 

[JohnH]

Refreshing the StatusStrip will do just fine in this particular case where some text need to be updated in a ToolStripStatusLabel, but the reason this happens is because the main thread is busy, and this means that all other forms and controls suffers the same problem. The ToolStripProgressBar is one of the few if not the only one that actually takes care of this UI issue itself, it may seem strange that it does so, but you wouldn't use one if you didn't want it update UI while processing anyway.. The timespan of all of this does matter, but generally when putting a continuous heavy load on the main thread you would want to take care of the whole applications appearance while it is processing. Try to put some window in front of the application while it processes then hide. When your application window re-appears it will look as it has crashed/froze up, except for the progressbar.. and the label. To take care of all this you use Application.DoEvents 'occationally' to let the windows messages be handled in between and update all UI. Another option would be to create a separate thread to do the heavy load and if necessary disable some or all other UI controls on main thread.