Application.LoadComponent Method

Definition

Namespace:

Windows.UI.Xaml

Overloads

LoadComponent(Object, Uri)	Loads a XAML file that is located at the specified relative location, and converts it to an instance of the object that is specified by the root element of the XAML file.
LoadComponent(Object, Uri, ComponentResourceLocation)	Loads a XAML file that is located at the specified relative location, and converts it to an instance of the object that is specified by the root element of the XAML file.

LoadComponent(Object, Uri)

Loads a XAML file that is located at the specified relative location, and converts it to an instance of the object that is specified by the root element of the XAML file.

public:
 static void LoadComponent(Platform::Object ^ component, Uri ^ resourceLocator);

/// [Windows.Foundation.Metadata.Overload("LoadComponent")]
 static void LoadComponent(IInspectable const& component, Uri const& resourceLocator);

[Windows.Foundation.Metadata.Overload("LoadComponent")]
public static void LoadComponent(object component, System.Uri resourceLocator);

function loadComponent(component, resourceLocator)

Public Shared Sub LoadComponent (component As Object, resourceLocator As Uri)

Parameters

component

Object

Platform::Object

IInspectable

An object of the same type as the root element of the XAML content to be loaded.

resourceLocator

Uri Uri

An object describing the Uniform Resource Identifier (URI) path to the resource to load.

Attributes

OverloadAttribute

Remarks

LoadComponent exists mainly for infrastructure. You can see LoadComponent as part of the generated InitializeComponent logic that integrates the partial classes of a XAML page and its code-behind.

LoadComponent sometimes is cited in a call stack for an exception that is ultimately because your app is trying to parse bad XAML. In this case there's nothing that app code can do to change how LoadComponent is used, and the way to fix the problem is to check your XAML source in an XML editor and fix it. What might be helpful from the stack trace message is confirming which XAML file is not loading. In scenarios where you have merged resources or other multiple XAML sources being combined, it's not always the obvious page-level XAML that is failing to parse.

Most app scenarios that involve loading XAML content and producing an object tree should use XamlReader.Load instead.

Resource loading optimization in Windows 8.1

Starting with Windows 8.1, there's a resource loading optimization that's enabled by the app model and the Windows Runtime XAML parser. LoadComponent is involved in this scenario because it's invoked internally to actually load any resource dictionary that comes from a XAML file, including those for MergedDictionaries. For Windows 8, the XAML parser loaded resources from app.xaml and created each of them as objects as part of startup. That wasn't very efficient if there were big dictionaries there. Also, those resources included the items that were needed by all three themes, and two of the three themes wouldn't even be active. Starting with Windows 8.1, the XAML parser only creates the resources when they're specifically requested. The request might come from other resources or from app or page XAML as each is loaded. This parser behavior minimizes the time it takes to read the app-level dictionary at startup time, and enables the first app page to load faster in most cases. Resources needed by other currently inactive themes are only loaded if that theme is chosen to become the active theme by the user. At that time, any resource where the {ThemeResource} markup extension was used for the request is recalculated based on the newly active theme.

Windows 8 behavior

Windows 8 didn't have the optimizations described above. The ResourceDictionary for Application.Resources had to finish parsing before any page other than the splash screen could load into the app's Window. Because of this you might see some differences in timing when you retarget your app for Windows 8.1. The app should be loading faster, however it may not be possible to isolate this improvement versus other changes you've made to your app code as part of retargeting. Some of the places where you might see evidence of timing changes due to optimized resource loading include when the constructors are called by the parser, for objects like Application objects, converters, or other custom classes. Apps that were compiled for Windows 8 but running on Windows 8.1 continue to use the Windows 8 behavior.

For more info on performance and XAML resource factoring, see Optimize your XAML markup.

See also

• LoadComponent(Object, Uri, ComponentResourceLocation)

LoadComponent(Object, Uri, ComponentResourceLocation)

Loads a XAML file that is located at the specified relative location, and converts it to an instance of the object that is specified by the root element of the XAML file.

public:
 static void LoadComponent(Platform::Object ^ component, Uri ^ resourceLocator, ComponentResourceLocation componentResourceLocation);

/// [Windows.Foundation.Metadata.Overload("LoadComponentWithResourceLocation")]
 static void LoadComponent(IInspectable const& component, Uri const& resourceLocator, ComponentResourceLocation const& componentResourceLocation);

[Windows.Foundation.Metadata.Overload("LoadComponentWithResourceLocation")]
public static void LoadComponent(object component, System.Uri resourceLocator, ComponentResourceLocation componentResourceLocation);

function loadComponent(component, resourceLocator, componentResourceLocation)

Public Shared Sub LoadComponent (component As Object, resourceLocator As Uri, componentResourceLocation As ComponentResourceLocation)

Parameters

component

Object

Platform::Object

IInspectable

An object of the same type as the root element of the XAML content to be loaded.

resourceLocator

Uri Uri

An object describing the Uniform Resource Identifier (URI) path to the resource to load.

componentResourceLocation

ComponentResourceLocation

A value of the enumeration.

Attributes

OverloadAttribute

See also

• LoadComponent(Object, Uri)