Child Controlling Parent Data

[zachattack05]

All parenting jokes aside, I have a general purpose status strip on my parent form that contains a progress bar and a few labels.

Occasionally a child form will execute a command that could be tracked on the status bar so my users don't think that the program is hanging...

I searched around and this topic seems to be open for quite a bit of debate. Some say use delegates, some say to set properties and some say to simply set the value of the control by name.

What's your thoughts? I'm looking for something that will be easy to update and maintain as well as easy to implement as a parent form can have multiple child forms.

Here are the suggestions I have run across so far:

Simply type:

this.ParentForm.Controls["label1"].Text="HI..."

Seems sloppy though and probably a nightmare to keep track of.

The other option, which might be the best -- but not sure, is from the DaniWeb web site: Update label text from another thread.

And finally this:

//IN THE CHILD FORM (MDIChild)

        private void button1_Click(object sender, EventArgs e)
        {
            MDIParent oParent = ParentForm as MDIParent;
            oParent.ChangeParentText = "My cool text";
        }

//IN THE PARENT FORM (MDIParent)

        public string ChangeParentText 
        {
            get
            {
                return label1.Text;
            }
            set 
            {
                label1.Text = value;
            }
        }

Any suggestions? What would be the preferred method for achieving this?

[nick.crane]

I tend to use a global collection that has message objects put in it by MDIChild forms. The message objects have a message and a timeout value.
The MDIparent form then uses a timer to examine the collection and cycle the messages on the status bar and remove messages when the timeout expires.
This has the advantage that many MDIchild forms can send different status messages and no message is lost.

[zachattack05]

I tend to use a global collection that has message objects put in it by MDIChild forms. The message objects have a message and a timeout value.
The MDIparent form then uses a timer to examine the collection and cycle the messages on the status bar and remove messages when the timeout expires.
This has the advantage that many MDIchild forms can send different status messages and no message is lost.

Hmmm....not a bad idea but might be more complex than what I need. Having messages lost isn't a major problem that I can foresee....Though I could be wrong...If two child forms are performing separate tasks at the same time, both of which involve updating the status bar...I don't see it as a big deal. The status bar simple displays messages that are simple such as "Refreshing data..." or "Checking connection..." nothing that a user would need to rely on. It's simply there for piece of mind that the software hasn't taken a dive.

[nick.crane]

I also log the message to a text based log file. That way the user can examing the log for any error messages they may have missed.

Of the two ideas you posted i prefer the second one. However, as it stands, this could give rise to thread conflicts if the text is set from outside the ui thread.

If you are not worried about missing messages then you could simplify my idea and just have a single global string that is tested by the main form and set by the child forms. This will not raise any thread conflicts because the status bar is only set by the main form.

[zachattack05]

I opted to go the route of delegates. Seems more natural for me to do that. Guess it just fits my personal style.