Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
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. –  Jimmy Hoffa Oct 22 '12 at 14:11
    
Can you please post more code? I don't want to be making assumptions here. –  CodeART Oct 30 '12 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 '12 at 0:37
add comment

2 Answers

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.

share|improve this answer
add comment

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.

share|improve this answer
    
Oops ... made this community wiki accidentally. Oh well, hope it helps! –  Steven Jeuris Nov 30 '12 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 '12 at 15:54
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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