> > What I meant is that it doesn't have to be a subclass of Container (though > it often probably will be). >
Pretty much has to be for any but the most trivial component, but I understand in principle. Sort of. A XAML file gets compiled to a class instance, and > InitializeComponent() is likely called by some glue code generated by the > compiler. > Which is why I said conceptually, though maybe that's not the best word. From the programmer's naive point of view (i.e., what you might think if you don't look inside the .g file), someone calls new Foo(), at which point the constructor calls InitializeComponent, whose mission is to "go do all that stuff the xaml file says". > It's not exactly the same as deserializing BXML in a constructor. In BXML, > the root element is instantiated by BXMLSerializer, not the new operator. > Yes. But does it have to be that way? I haven't looked at the BXMLSerializer code, so perhaps I'm being naive, but it seems like you could have a different entry point to the code, one that accepts the already-created root class as a parameter rather than creating one only after parsing the root element. In such a world, the class constructor could call BXMLSerializer.InitializeComponent(this, "whatever.bxml"). Then anyone could new the component without needing to know there was a bxml file, and in someone else's bxml file you could treat the custom component on equal footing with any built-in Pivot component, including setting its properties: <my:Foo blinkRate="5" showDetails="true" /> Well, I see from your last remark I can set properties from the include element already, so this last point isn't a big breakthrough. But I think the not needing to know that some component classes are defined with a bxml file and some aren't would be a win. Just a thought.
