Access One User Control From Another User Control

**edit**

I have it working now by doing the following:

1. create a public event EventHandler eventhandlername in uc1
2. in the button click method, I added the following:

if (eventhandlername != null) { eventhandlername(this, EventArgs.Empty); }

3. Following InitializeComponent() for uc1, I added:

btnShow.Click+= new EventHandler(btnShow_click);

4. Then back on form1, I created a method that I would like to be called when btnShow on uc1 is clicked,

private void uc1_eventhandlername(object sender, EventArgs e) { uc2.Show(); }

5. Finally, I registered uc1_eventhandlername as a listener

uc1.eventhandlername += new EventHandler(uc1_eventhandlername);

Is this the correct way to handle this task?

You say the "method I am attempting to call". Is the method public or private?


Your latest question is a little vague, so if my understanding is incorrect then we need clarification of what you are asking.

I seem to be missing something that is holding the implementation of this up.  On uc1, I have created a delegate with a signature that matches the existing delegate.  However, when I plug in the method that I would like this delegate to call, I receive a message stating that the method is inaccessible due to its protection level.  The method I am attempting to call is located in form1, what is the missing piece that will allow me to call this method from the newly added delegate located on uc1?

Does the delegate need to be added in form1, as in,

this.uc1.btnShow.Click+=new System.EventHandler(this.ShowUC2);

The protection level of ShowUC2 would not matter, but, btnShow.Click located on uc1 is not visible now either.

I appreciate the clarifications from both of you.  I am looking into creating a public event in the user control that the form can subscribe to, which I believe is the right direction.

Yes, Zoran; that sounds good to me.

Yes, that was my point too - every control is contained in another control that I was referring as owner and parent interchangeably. Anyway, every component (not only user controls, but also general objects) should communicate to its owner, and then owner would decide what to do with information given.

Here is an application that I'm coding right now. I have a left pane on the form containing a tree structure with a hierarchy of different objects. Some of the objects are just directories, others have content that can be edited by 3-4 other specific controls. Now, I have a SelectedObjectChanged event of the tree control, and that event is handled by the containing control, which is in this case form. Then, form decides which control is specialized to edit particular object which has been selected, and then shows that control on the right and gives it the object to edit. That is in my view proper way to pass information between controls. Tree control doesn't know and should not know which other control is used for which kind of object. Tree control doesn't even know if particular object is editable at all. Its job is to show tree with directories and items in the directories in a way that is pleasant to the user. Thinking about internals of items is other control's job.

Examples that show opposite point - like having controls at the same level communicate directly with each other - are very rare and limited to very simple situations.

Zoran, I think what you are saying is consistent with what I am saying. You say "make the control owner decide what to do with those events" and I think agree; you say owner and I say parent but I assume they are essentially the same in this context.

I highly disagree with "best practices would consist of having the user controls communicate with the form". If a UserControl uc1 contains another UserControl uc2 then uc2 should interface with only uc1. Or to put it another way, uc2 should interface only with it's parent. If the form or some other UserControl needs to communicate with uc2, then it should be done through uc1. So if you want uc2 to be shown or hidden in uc1, then the form or another UserControl should call a method or maybe set a property in uc1, and then uc1 would do the show or hide.

When you use designer to drop controls on the form, designer actually creates code in a partial class which sets properties to values shown in each control's properties. So it's all the same whether you allocate and initialize controls by yourself or let the designer do it for you.

My practice is to use designer for forms and to avoid it in user controls. Also, I'm never deriving control classes from UserControl but rather from Control directly. But both practices have come after years of practicing, so for novice and intermediate levels I'd say that designer is a better choice - less things to screw.

With that in mind, is it safe to assume that best practices would also consist of initializing the user controls in the code, as opposed to dropping them on the form?

Exactly like that. When coding one control, do not bother with activities of other controls - those controls might not be present on the form at all! Rather keep focused on the states of control you're coding. This means - raise events that show control's state changes. Then make the control owner decide what to do with those events.

So best practices would consist of having the user controls communicate with the form, such as uc1 telling form1 to show uc2 as well as hide uc1?

I've shown you how to allow controls to send data among each other. However, in most cases, I do not allow controls to communicate directly, but rather let the parent control (e.g. form) subscribe to their events and then pass on the data to destination control.

For example, suppose that you have one control showing directory tree, and another control showing file content. Tree control can raise event SelectedFileChanged, and viewer can subscribe to that event and then change own content when user selects different file. However, I would rather make parent form subscribe to SelectedFileChanged event, and then implement File property (get/set) in the viewer. Parent form would then, when SelectedFileChanged event is fired, set new value to the viewer's File property, which would force refresh of the viewer's content.

Treating objects as equal is not good in my opinion. I'm always trying to keep strict hierarchy of objects, so that every object reports to a single parent. In that way, data paths are simpler and more under control. Firing events among controls, and especially changing controls states, may lead to unexpected cascade effects and bugs that are hard to trace.

I initially developed the application with a single form, and I was using panels (show/hide) for various aspects of the application.  Upon adding a few features, which added more panels, the form was rather crowded and became difficult to make changes to the individual panels.  I then began converting each panel to a user control.  This allowed me to drop each user control on the form, and I could easily make changes to appropriate user control wherever they were needed.  Essentially, upon converting the panels to user controls, I was hoping I could show and hide specified user controls in a similarly to how I was originally using show and hide with the panels. 

More than 99.99% of the time the way that something such as that is done is for the first UserControl to have the second UserControl in it. Very simple. Also, the normal way to place a UserControl in a form during execution is to add the UserControl to the form's list of controls. Calling UserControl.Show() will just make the control visible; that is the only thing it changes.
 
Putting a UserControl in another UserControl from the form is inconsistent with object-oriented programmming. I don't know what the requirements of your application are but it is likely that experienced developers would use the design that you seem to be using.

Below is the sample code with two instances of one control class. Instance which is receiving event must subscribe to another instance's event, which is controlled by the parent, i.e. by the code which instantiates the two controls. Having that done, one control can raise event and another control can do something about that event.

This code requires reference to System.Drawing to operate. Compile it as console application.

using System;
using System.Drawing;
using System.Windows.Forms;
using System.Collections.Generic;

class Program
{

    class Poly : UserControl
    {

        public event EventHandler ControlHit;

        public Poly()
        {
            DoubleBuffered = true;  // don't flicker
        }

        protected override void OnPaint(PaintEventArgs e)
        {
            base.OnPaint(e);

            Rectangle rect = ClientRectangle;
            List points = new List();

            points.Add(new Point(0, rect.Height / 2));
            points.Add(new Point(rect.Width / 2, 0));
            points.Add(new Point(rect.Width, rect.Height / 2));
            points.Add(new Point(rect.Width / 2, rect.Height));

            e.Graphics.FillPolygon(Brushes.DarkBlue, points.ToArray());

            string hit = _hitPoint.ToString("0");

            SizeF textSize = e.Graphics.MeasureString(hit, this.Font);
            PointF textPoint = new PointF((ClientRectangle.Width - textSize.Width) / 2, (ClientRectangle.Height - textSize.Height) / 2);

            e.Graphics.DrawString(hit, this.Font, Brushes.Yellow, textPoint);

        }

        protected override void  OnMouseDown(MouseEventArgs e)
        {
            base.OnMouseDown(e);
            if (ControlHit != null)
                ControlHit(this, new EventArgs());
        }

        public void SubscribeToOtherClick(Poly p)
        {
            p.ControlHit += new EventHandler(OtherControlClicked);
        }

        private void OtherControlClicked(object sender, EventArgs e)
        {
            _hitPoint++;
            Refresh();
        }

        private int _hitPoint;

    }

    static void Main(string[] args)
    {

        Form f = new Form();

        f.Size = new Size(500, 500);

        Poly poly1 = new Poly();

        poly1.Left = 10;
        poly1.Top = 10;
        poly1.Width = (f.ClientRectangle.Width - 40) / 2;
        poly1.Height = f.ClientRectangle.Height - 20;

        poly1.Anchor = AnchorStyles.None;

        Poly poly2 = new Poly();

        poly2.Left = poly1.Right + 20;
        poly2.Top = 10;
        poly2.Width = (f.ClientRectangle.Width - 40) / 2;
        poly2.Height = f.ClientRectangle.Height - 20;

        poly2.Anchor = AnchorStyles.None;

        poly1.SubscribeToOtherClick(poly2);
        poly2.SubscribeToOtherClick(poly1);

        f.Controls.Add(poly1);
        f.Controls.Add(poly2);

        f.ShowDialog();

    }
}