Application.LoadComponent Méthode

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)

Paramètres

Attributs

OverloadAttribute

Remarques

LoadComponent existe principalement pour l’infrastructure. Vous pouvez voir LoadComponent dans le cadre de la logique InitializeComponent générée qui intègre les classes partielles d’une page XAML et son code-behind.

LoadComponent est parfois cité dans une pile d’appels pour une exception qui est finalement due au fait que votre application tente d’analyser un code XAML incorrect. Dans ce cas, le code d’application ne peut rien faire pour modifier la façon dont LoadComponent est utilisé, et la façon de résoudre le problème consiste à case activée votre source XAML dans un éditeur XML et à le résoudre. Ce qui peut être utile dans le message de trace de pile est de confirmer le fichier XAML qui ne se charge pas. Dans les scénarios où vous avez fusionné des ressources ou d’autres sources XAML multiples en cours de combinaison, ce n’est pas toujours le CODE XAML évident au niveau de la page qui ne parvient pas à l’analyse.

La plupart des scénarios d’application qui impliquent le chargement du contenu XAML et la production d’une arborescence d’objets doivent utiliser XamlReader.Load à la place.

Optimisation du chargement des ressources dans Windows 8.1

À compter de Windows 8.1, il existe une optimisation du chargement des ressources activée par le modèle d’application et l’analyseur XAML Windows Runtime. LoadComponent est impliqué dans ce scénario, car il est appelé en interne pour charger en fait n’importe quel dictionnaire de ressources provenant d’un fichier XAML, y compris ceux de MergedDictionaries. Pour Windows 8, l’analyseur XAML a chargé des ressources à partir d’app.xaml et a créé chacune d’entre elles en tant qu’objets dans le cadre du démarrage. Ce n’était pas très efficace s’il y avait de grands dictionnaires là-bas. En outre, ces ressources comprenaient les éléments qui étaient nécessaires aux trois thèmes, et deux des trois thèmes ne seraient même pas actifs. À compter de Windows 8.1, l’analyseur XAML crée les ressources uniquement lorsqu’elles sont spécifiquement demandées. La demande peut provenir d’autres ressources ou d’une application ou d’une page XAML au fur et à mesure que chacune d’elles est chargée. Ce comportement de l’analyseur réduit le temps nécessaire à la lecture du dictionnaire au niveau de l’application au moment du démarrage et permet à la première page d’application de se charger plus rapidement dans la plupart des cas. Les ressources nécessaires à d’autres thèmes actuellement inactifs sont chargées uniquement si ce thème est choisi pour devenir le thème actif par l’utilisateur. À ce moment-là, toute ressource où l’extension de balisage {ThemeResource} a été utilisée pour la requête est recalculée en fonction du thème nouvellement actif.

Comportement de Windows 8

Windows 8 n’avait pas les optimisations décrites ci-dessus. ResourceDictionary pour Application.Resources a dû terminer l’analyse avant qu’une page autre que l’écran de démarrage puisse se charger dans la fenêtre de l’application. Pour cette raison, vous pouvez voir des différences dans le moment où vous reciblez votre application pour Windows 8.1. L’application doit être chargée plus rapidement, mais il n’est peut-être pas possible d’isoler cette amélioration par rapport aux autres modifications que vous avez apportées au code de votre application dans le cadre du reciblage. Certains des endroits où vous pouvez voir des preuves de changements de minutage en raison du chargement optimisé des ressources incluent lorsque les constructeurs sont appelés par l’analyseur, pour des objets tels que des objets Application , des convertisseurs ou d’autres classes personnalisées. Les applications qui ont été compilées pour Windows 8, mais qui sont exécutées dans Windows 8.1, continuent d’appliquer le comportement Windows 8.

Pour plus d’informations sur les performances et la factoring des ressources XAML, consultez Optimiser votre balisage XAML.

Voir aussi

• LoadComponent(Object, Uri, ComponentResourceLocation)

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)

Paramètres

Attributs

OverloadAttribute

Voir aussi

• LoadComponent(Object, Uri)