Does a window's default constructor have to be public?

Question

I'm working on a dialog window for my WPF application. I know that WPF requires that all controls have a default constructor and I can create all the constructors that take all the parameters that I want. But does the default constructor have to be public? Can I make it internal, or private, or even protected?

without being public, you (or whatever auto-mechanism) cannot create an instance of the class ***outside*** the class, maybe using Reflection can do. — King King, Aug 20 '14 at 15:00
possible duplicate of [Should we always include a default constructor in the class?](http://stackoverflow.com/questions/3692042/should-we-always-include-a-default-constructor-in-the-class) Not an exact duplicate but answerer contains what the OP wants — nsgocev, Aug 20 '14 at 15:01
That depends on the requirement. If you don't want access to default constructor from outside the class then make it private, If you don't want access outside of assembly then make it internal. — Habib, Aug 20 '14 at 15:01
If you don't have a default constructor or if it is not public, you can't instantiate it from `Xaml`. If that's ok for you then go ahead.. — Sriram Sakthivel, Aug 20 '14 at 15:05

thumbmunkeys · Accepted Answer · 2014-08-20T16:59:35.520

6

Controls dont need a default constructor in WPF, unless you want to instantiate the control from XAML.

It's perfectly legal to have a control like this:

public partial class MyUserControl : UserControl
{
      public MyUserControl(string someParameter) : this()
      { 
         InitializeComponent();
      }
}

As shown, the default constructor was removed, you need to make sure that InitializeComponent(); is called, though.

If you instantiate the control from XAML, then the default constructor must be visible by the embedding control

Therefore it can be internal if the embedding control is in the same assembly, or it has to be public otherwise.

edited Aug 20 '14 at 16:59

answered Aug 20 '14 at 15:06

thumbmunkeys

20,606
8
62
110

It's a dialog. It won't be instantiated in XAML in this application. – Tony Vitabile Aug 20 '14 at 16:34
@TonyVitabile then your constructor simply needs to be visible to the calling code. – thumbmunkeys Aug 20 '14 at 16:35
Granted. There are multiple constructors. There is a default constructor that calls `InitializeComponent` because VS built it by default. There's another that takes arguments. The first thing it does is call the default constructor. I just don't want code outside of the class calling that default constructor. Actually, I may be able to remove the default constructor entirely. – Tony Vitabile Aug 20 '14 at 16:55
yes you need to call `InitializeComponent()`. Make the default constructor private and call it from your non default constructors. I think I misunderstood where your question was aimed at. – thumbmunkeys Aug 20 '14 at 16:57
Yep, I know I have to call `IntializeComponent`. If I removed the default constructor, I'd move the call to `InitializeComponent` into the public constructor. It's working fine with the default constructor set to private. I had thought the designer in VS would have a fit if the default constructor didn't exist or wasn't public. – Tony Vitabile Aug 20 '14 at 20:18
When I make my `MainWindow` constructor `internal` I get this error: *System.Windows.Markup.XamlParseException: ''No matching constructor found on type MainWindow. You can use the Arguments or FactoryMethod directives to construct this type.* Even the `MainWindow` class itself is `internal`, and that actually works fine after adding `x:ClassModifier="internal"` to the XAML. This makes it even weirder to why I can't get the constructor working as `internal`. – SportySpice May 06 '17 at 18:17

score 1 · Answer 2 · answered Aug 20 '14 at 15:48

making your constructor internal ensures the type will only ever be instantiated by types within the current assembly, even if it is later decided that the type itself should be public instead of internal. In other words you could decide to change the type's visibility without lifting restrictions on its instantiation.

Making the constructor public has the opposite effect (obviously), and might be sensible if you want for it to be possible to instantiate the type anywhere it is visible.

Does a window's default constructor have to be public?

2 Answers2