On some generic functions, it seems that accessing a function on mainform directly from the usercontrol is easier than raising an event. For example: A function on main form that displays one desired usercontrol centered and tweaked.

Making this function static, or access this function by reference from the user control to its parent, rather then raising an event, seems very convenient. Like this:

usercontrol_A uc_a = new usercontrol_A();
MainForm mainform_functions = (MainForm)Parent;

Raising an event seems more complex in such cases - I need to declare all new userControl_B's events (which also includes initiating usercontrol_C and displaying it) inside the event that shows (and initiates) userControl_B:

  userControl_A.ShowUserControl_B+= (s,e) =>
 usercontrol_B uc_b = new usercontrol_B();   DisplayControl(uc_b);
    uc_b.show_uc_c += (s2,e2) => {usercontrol_C uc_c = new usercontrol_C(); DisplayControl(uc_c); }

too much clutter here.

That's hard to code and to read later. (In addition, passing parameters to another usercontrol is a nightmare like this - I need to save the parameter artificially on the sender usercontrol class and then cast it back later inside the event)

What is your opinion? Is it a completely "prohibited" to code like this, at least on generic functions like I mentioned? Isn't clearer code that needs some small tweaking for reuse preferable?

  • 3
    If it's at all possible to know all possibly displayable controls on a form, it is a better practice to have them all created by default and you merely flip their visibility flags and move their locations where necessary. If it's a completely dynamic number of controls however ignore this comment. Oct 22, 2012 at 14:11
  • Can you please post more code? I don't want to be making assumptions here.
    – CodeART
    Oct 30, 2012 at 23:33
  • @CodeWorks - I added more code, if it's still not clear please let me know, as I see people aren't responding to this post (from some reason..?)
    – BornToCode
    Oct 31, 2012 at 0:37

2 Answers 2


This is why creational patterns exist, often times creation of types can be tricky as you have run into.

I think you want an abstract factory here (caveat: not true if user control A/B/C have basically identical attributes, if they're identical you just need a single method that will create a control with the desired configuration which can be treated as control A, B, or C)

public interface IControlCreator
    Control CreateControl();

public class ControlFactory<T> where T : IControlCreator, new
        return (new T()).CreateControl();

public ControlACreator : IControlCreator
    Control CreateControl()
        Control controlA = new Control();
        controlA.show_uc_b += (s,e) => new ControlFactory<ControlBCreator>().CreateControl();

public ControlBCreator : IControlCreator
    Control CreateControl()
        Control controlB = new Control();
        controlB.show_uc_c += (s,e) => new ControlFactory<ControlCCreator>().CreateControl();

Then anytime you want a control, it will have the appropriate events tied on in by it's Creator class, all you need to call to get one is new ControlFactory<ControlWhateverCreator>().CreateControl();

Please, someone let me know if I got something wrong here; I've actually never written an abstract factory before. It's a lot of overhead so I tend to avoid facotries, but it seems the right approach based on the problem scope the OP detailed.


Could you please just state conceptually what you are trying to achieve? The limited explanation and code make it hard to judge about the grander picture which is going to be important here.

However, to answer your initial question more generally:

On some generic functions, it seems that accessing a function on mainform directly from the usercontrol is easier than raising an event.

Depending on your scenario:

  • It is not prohibited if your user control always has to be located within that specific parent. In that case I would pass the parent (or an interface which the parent implements) to the constructor of the user control (constructor injection). This makes it impossible for the parent to be anything else than the correct expected type.
  • If it's at all possible to reuse that user control in different parents, casting to the specific parent would make that impossible. That's where the events would come in handy. This allows for a lot more loosely coupled code.

However, judging from your given code I would say probably the events are the way to go. It seems you are hard coding a lot stuff like userControl_A.ShowUserControl_B. Perhaps you could handle this conceptually in your parent by linking them together there instead? I'm thinking of creating an abstract user control class which has something along a Closed event which the parent class handles after which it shows the next user control.

  • Oops ... made this community wiki accidentally. Oh well, hope it helps! Nov 30, 2012 at 1:32
  • conceptually what I try to achieve - An application with plenty of 'screens'. Each screen is a usercontrol. A main form 'hosts' these usercontrols. Whenever I want to display a certain usercontrol, I pass it to a function on mainform, this function is in charge of expanding that usercontrol, centering it according to client's resolution and dispose older usercontrols. The 'navigation' between usercontrols will also be like this - a button on usercontrol_A will make usercontrol_B appear etc. (if I use events than on each usercontrol 'display' event I must declare ALL its 'navigations')
    – BornToCode
    Dec 2, 2012 at 15:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.