0

I'm trying to bring FontAwesome to UWP and found the SymbolIcon-Class, which does this for the in-built Segoe UI Symbol font.

The class is inherited from IconElement and looks promising, but I can't derive from that class, because VS is telling me that "IconElement does not take a constructor that takes 0 arguments".

The problem: I don't know what I should implement and neither VS or Resharper gave me any insights. Even a decompile of the SymbolIcon didn't enlighten me.

What do I miss?

VS

Edit:

The base() was just a test to see if there are any arguments on the IconElements constructor.

But I still don't get why I can't simply derive from IconElement - it works without any problems from FrameworkElement:

Larger Example

Robert Muehsig
  • 5,206
  • 2
  • 29
  • 33

2 Answers2

1

I think that :

public foo() : base()
{

}

is not accepted, because simply the class IconElement doesn't have an explicit constructor, so calling : base() is just redundant as Resharper hints to :

enter image description here

Why it is redundant ? Because you can't even inherit from that 'IconElement' class, why ? because :

If a class contains no instance constructor declarations, a default instance constructor is automatically provided. That default constructor simply invokes the parameterless constructor of the direct base class.

Update :

So the problem is that when the compiler goes to invoke the parameterless constructor of the direct base class ('IconElement' in this case), it simply doesn't find any parameterless constructor (the IconElement doesn't have one, the compiler gives a default one to it, and it invokes its parent's, FrameworkElement's) hence it generates the CS1729 Error.

AymenDaoudi
  • 7,811
  • 9
  • 52
  • 84
  • I updated my question - the base() was just a test. But what is so special on the IconElement that I can't simply derive from that. It works from FrameworkElement without any problems. – Robert Muehsig Jan 27 '16 at 05:59
  • @RobertMuehsig : yes it works from FrameworkElement without a problem, because FrameworkElement has a defined parameterless constructor that is accessible to to classes that derives from it (because it is protected) – AymenDaoudi Jan 27 '16 at 08:28
  • I was missing the point that IconElement has an internal ctor. Thanks for your help! – Robert Muehsig Jan 27 '16 at 08:30
  • @RobertMuehsig : Welcome – AymenDaoudi Jan 27 '16 at 08:49
1

IconElement doesn't have any public (or protected) constructors. A derived class needs to call a base constructor, therefore you can't create a derived class. FrameworkElement on the other hans has a default parameterless protected constructor that you can call from a derived class, therefore you can create a derived class.

For the SymbolIcon class to be able to derive from IconElement class, it still needs an accessible constructor in IconElement class. Obviously there is an internal constructor available in IconElement class that it can access, because it is in the same assembly.

You can recreate the same scenario yourself. Create a class with only a single parameterless constructur that is internal.

public class BaseClass()
{
    internal BaseClass() { }
}

You can now create a derived class in the same assembly (it will be able to call this internal constructor), but you will not be able to do it from another assembly referencing this one (there will be no accessible constructors on the base class).

I'm not sure why exactly you want to derive from IconElement class, but you won't be able to do it. Even the IIconElement interface it implements is internal, so you won't be able to implement it yourself either.

Also, all of these classes are implemented natively, therefore you can't really decompile them. There's only managed metadata available in *.winmd files that you can see if you try decompiling a class in e.g. ReSharper.

Damir Arh
  • 17,637
  • 2
  • 45
  • 83
  • Thanks! Makes perfect sense now. For my actual problem I found another class that seems to be fine for my usecase: [FontIcon](https://msdn.microsoft.com/en-us/library/windows/apps/windows.ui.xaml.controls.fonticon) – Robert Muehsig Jan 27 '16 at 07:30