By hidden source code file…
A hidden source code file is auto-generated for each WPF XAML file. The names used for this file and for the class it contains are based off the XAML file’s filename. In a C# application, the file MyWindow.xaml will have a hidden code-behind file named MyWindow.g.cs containing a class named MyWindow.
…containing a class…
The contained class inherits from the WPF core class corresponding to the associated XAML file’s root element. If the root element in the XAML file is <Window>, the class in the hidden code-behind file will inherit from Window.
public partial class MyWindow : System.Windows.Window, System.Windows.Markup.IComponentConnector
The contained class is defined as a partial class, allowing the programmer to add code to the class without modifying the auto-generated hidden file. Microsoft Visual Studio encourages this practice by creating a non-hidden code-behind file each time a new XAML file is added to a WPF project. In the case of MyWindow.xaml, the corresponding non-hidden code-behind file will be named MyWindow.xaml.cs.
…that loads the XAML as a component…
In most cases (with the most notable exception being the case of App.xaml), the auto-generated class contains code loading the XAML file into the application as a component via a call to System.Windows.Application’s static method LoadComponent(..).
private bool _contentLoaded; [System.Diagnostics.DebuggerNonUserCodeAttribute()] public void InitializeComponent() { if (_contentLoaded) { return; } _contentLoaded = true; System.Uri resourceLocater = new System.Uri("/WPFXAMLExecution;component/MyWindow.xaml", System.UriKind.Relative); #line 1 "..\..\MyWindow.xaml" System.Windows.Application.LoadComponent(this, resourceLocater); #line default #line hidden }
…and connects named controls to instance variables.
In most cases, this class also contains code wiring up named controls (controls whose defining XAML specifies a x:Name or Name attribute) to instance variables. If MyWindow.xaml defines <TextBox x:Name=”FirstName” />, this wire-up allows that TextBox control to be accessed from code via MyWindow’s FirstName property (e.g. myWindowInstance.FirstName.Text = “Joe”;)
#line 5 "..\..\MyWindow.xaml" internal System.Windows.Controls.TextBlock FirstName; #line default #line hidden [System.ComponentModel.EditorBrowsableAttribute(System.ComponentModel.EditorBrowsableState.Never)] [System.Diagnostics.CodeAnalysis.SuppressMessageAttribute("Microsoft.Design", "CA1033:InterfaceMethodsShouldBeCallableByChildTypes")] void System.Windows.Markup.IComponentConnector.Connect(int connectionId, object target) { switch (connectionId) { case 1: this.FirstName = ((System.Windows.Controls.TextBlock)(target)); return; } this._contentLoaded = true; }
Differs from Windows Forms
Those of you with a Windows Forms background may have noticed a significant difference in the content of WPF’s hidden code-behind files. In Windows Forms, each form’s hidden code-behind contains a compete representation of the form written in executable code. In WPF, each XAML file’s hidden code-behind contains only the code necessary to wire the XAML file into the executable environment as a component.
—
Related: WPF, Where Is Your “static Main()” Method? – on the auto-generation of the static Main() method in WPF applications.
Hi Ben:
Nice article.
I’m using VS 2012 for desk top applications. I believe myWindow application has different executable environment from the 2010 one.
I wish you’d rewrite your articles related to the coupling between the XAML file and the code-behind.
Thanks.
Mark