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;
mainform_functions.DisplayControl(uc_a);
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
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
{
GetControl()
{
return (new T()).CreateControl();
}
}
public ControlACreator : IControlCreator
{
Control CreateControl()
{
Control controlA = new Control();
DisplayControl(controlA);
controlA.show_uc_b += (s,e) => new ControlFactory<ControlBCreator>().CreateControl();
}
}
public ControlBCreator : IControlCreator
{
Control CreateControl()
{
Control controlB = new Control();
DisplayControl(controlB);
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.
2