Objet App dans Power Apps

S’applique à : Applications canevas

Obtenez des informations sur l’application en cours d’exécution et contrôlez le comportement de l’application.

Description

Comme un contrôle, l’objet App possède des propriétés qui identifient l’écran qui s’affiche et vous invitent à enregistrer les modifications afin de ne pas les perdre. Chaque application a un objet de type Application.

Écrivez des formules pour certaines propriétés de l’objet App . Au sommet du volet Arborescence, sélectionnez l’objet appli comme vous le feriez pour tout autre contrôle ou écran. Pour afficher ou modifier l’une des propriétés de l’objet, sélectionnez-la dans la liste déroulante à gauche de la barre de formule.

Cet article décrit les propriétés d’objet d’application suivantes :

• ActiveScreen : écran actuellement affiché.
• BackEnabled : comment l’application répond au mouvement de retour de l’appareil.
• ConfirmExit et ConfirmExitMessage : avertit l’utilisateur avant de fermer l’application.
• Chaîne de connexion : configurez la journalisation Application Insights.
• Formules : définissez des formules nommées, des fonctions définies par l’utilisateur et des types définis par l’utilisateur.
• OnError : gérez les erreurs globalement.
• OnStart : exécutez la logique au démarrage de l’application.
• StartScreen : définissez l’écran affiché en premier lorsque l’application se charge.
• StudioVersion : retournez la version Power Apps Studio qui a publié l’application.

Propriété ActiveScreen

La propriété ActiveScreen identifie l’écran actuellement affiché.

Cette propriété renvoie un objet d’écran. Utilisez-la pour référencer les propriétés de l’écran actuel, telles que le nom avec la formule App.ActiveScreen.Name. Vous pouvez également comparer cette propriété à un autre objet d’écran, comme avec la formule de comparaison App.ActiveScreen = Screen2 pour vérifier si Screen2 est l’écran actif.

Utilisez la fonction Back ou Navigate pour changer l’écran affiché.

Propriété BackEnabled

La propriété BackEnabled modifie la façon dont l’application répond au mouvement précédent de l’appareil (balayez ou utilisez le bouton Précédent matériel sur les appareils Android, ou balayez à partir de la gauche sur les appareils iOS) lors de l’exécution dans Power Apps mobile. Lorsqu’il est activé, le mouvement back de l’appareil revient à l’écran qui a été le plus récemment affiché, ce qui est similaire à la formule Précédent . En cas de désactivation, le mouvement de retour de l’appareil amène l’utilisateur à la liste des applications.

Propriétés ConfirmExit

Personne ne veut perdre des modifications non enregistrées. Utilisez les propriétés ConfirmExit et ConfirmExitMessage pour avertir l’utilisateur avant de fermer votre application.

Note

• ConfirmExit ne fonctionne pas dans les applications incorporées dans, par exemple, Power BI et SharePoint.
• ConfirmExit n’est pas pris en charge dans les pages personnalisées.
• À présent, ces propriétés peuvent référencer des contrôles uniquement sur le premier écran si la fonctionnalité d’aperçu de chargement différée est activée (qu’elle est par défaut pour les nouvelles applications). Si vous référencez d’autres écrans, Power Apps Studio n’affiche pas d’erreur, mais l’application publiée ne s’ouvre pas dans Power Apps Mobile ou un navigateur. Microsoft travaille à lever cette limitation. En attendant, désactivez la charge retardée dans lesfonctionnalités à venir des > (sous Préversion).

ConfirmExit

ConfirmExit est une propriété booléenne qui, lorsque la valeur est true, ouvre une boîte de dialogue de confirmation avant la fermeture de l’application. Par défaut, cette propriété est false et aucune boîte de dialogue n’apparaît.

Lorsque l’utilisateur peut avoir des modifications non enregistrées dans l’application, utilisez cette propriété pour afficher une boîte de dialogue de confirmation avant de quitter l’application. Utilisez une formule qui vérifie les variables et les propriétés de contrôle (par exemple, la propriété Unsaved du contrôle De formulaire Edit ).

La boîte de dialogue de confirmation s’affiche dans n’importe quelle situation où les données peuvent être perdues, telles que :

• Exécutez la fonction Exit .
• Si l’application s’exécute dans un navigateur :
  • Fermez le navigateur ou l’onglet du navigateur dans lequel l’application s’exécute.
  • Sélectionnez le bouton Précédent du navigateur.
  • Exécutez la fonction Launch avec launchTarget of Self.
• Si l’application s’exécute dans Power Apps Mobile (iOS ou Android) :
  • Balayez pour basculer vers une autre application dans Power Apps Mobile.
  • Sélectionnez le bouton Précédent sur un appareil Android.
  • Exécutez la fonction Launch pour lancer une autre application canevas.

L’apparence exacte de la boîte de dialogue de confirmation peut varier entre les appareils et les versions de Power Apps.

La boîte de dialogue de confirmation ne s’affiche pas dans Power Apps Studio.

ConfirmExitMessage

Par défaut, la boîte de dialogue de confirmation affiche un message générique, tel que « Vous avez peut-être des modifications non enregistrées. » dans la langue de l’utilisateur.

Utilisez ConfirmExitMessage pour fournir un message personnalisé dans la boîte de dialogue de confirmation. Si cette propriété est blank, la valeur par défaut est utilisée. Les messages personnalisés sont tronqués selon les besoins de la boîte de dialogue de confirmation, donc conservez le message sur quelques lignes au maximum.

Dans un navigateur, la boîte de dialogue de confirmation peut afficher un message générique à partir du navigateur.

Exemple

1. Définissez la propriété ConfirmExit de l’objet appli à cette expression :

   AccountForm.Unsaved Or ContactForm.Unsaved
   

   La boîte de dialogue s’affiche si l’utilisateur modifie les données dans l’un ou l’autre formulaire, puis tente de fermer l’application sans enregistrer ces modifications.

   

2. Définissez la propriété ConfirmExitMessage de l’objet appli à cette formule :

   If( AccountForm.Unsaved,
       "Accounts form has unsaved changes.",
       "Contacts form has unsaved changes."
   )
   

   La boîte de dialogue affiche un message spécifique au formulaire lorsque l’utilisateur modifie les données dans l’un ou l’autre formulaire, puis tente de fermer l’application sans enregistrer ces modifications.

   

Propriété de chaîne de connexion

Utilisez la propriété chaîne de connexion pour exporter les journaux d’application générés par le système vers Application Insights.

Pour définir la chaîne de connexion :

1. Ouvrez votre application pour la modifier dans Power Apps Studio.
2. Sélectionner objet Application depuis l’arborescence sur la arborescence de gauche.
3. Entrez la chaîne de connexion dans le volet propriétés.

Si les données ne sont pas envoyées à Application Insights, contactez votre administrateur Power Platform et vérifiez si Application Insights est désactivé au niveau du locataire.

Propriété des formules

Utilisez la propriété Formulas pour définir une logique réutilisable dans votre application. La propriété Formulas prend en charge trois constructions :

• Formules nommées : attribuez un nom à une formule et réutilisez la valeur dans l’application.
• Fonctions définies par l’utilisateur : formules nommées qui prennent des paramètres et retournent une valeur.
• Types définis par l’utilisateur : les types nommés que vous pouvez réutiliser dans les formules et les signatures de fonction.

Formules nommées

Utilisez des formules nommées dans la propriété Formulas pour définir une formule que vous pouvez réutiliser dans votre application.

Dans Power Apps, les formules déterminent la valeur des propriétés de contrôle. Par exemple, pour définir la couleur d’arrière-plan de manière cohérente sur une application, définissez la propriété Fill pour chaque contrôle sur une formule commune :

Label1.Fill: ColorValue( Param( "BackgroundColor" ) )
Label2.Fill: ColorValue( Param( "BackgroundColor" ) )
Label3.Fill: ColorValue( Param( "BackgroundColor" ) )

Avec tant d’endroits où cette formule apparaît, elle devient fastidieuse et sujette à des erreurs pour les mettre à jour toutes si une modification est nécessaire. Au lieu de cela, créez une variable globale dans OnStart pour définir la couleur une seule fois, puis réutilisez la valeur dans l’application :

App.OnStart: Set( BGColor, ColorValue( Param( "BackgroundColor" ) ) )
Label1.Fill: BGColor
Label2.Fill: BGColor
Label3.Fill: BGColor

Bien que cette méthode soit meilleure, elle dépend aussi de l’exécution de OnStart avant la définition de la valeur BGColor. BGColor peut également être manipulé dans un recoin de l’application que le fabricant ignore, une modification apportée par un tiers et qui peut être difficile à retrouver.

Les formules nommées offrent une alternative. Tout comme vous écrivez généralement control-property = expression, vous pouvez à la place écrire le nom = expression , puis réutiliser le nom dans toute votre application pour remplacer l’expression. Définissez ces formules dans la propriété Formulas :

App.Formulas: BGColor = ColorValue( Param( "BackgroundColor" ) );
Label1.Fill: BGColor
Label2.Fill: BGColor
Label3.Fill: BGColor

Les avantages de l’utilisation de formules nommées incluent :

• La valeur de la formule est toujours disponible. Il n’y a pas de dépendance temporelle, aucun OnStart qui doit s’exécuter avant que la valeur ne soit définie, aucun moment où la valeur de la formule est incorrecte. Les formules nommées peuvent se référer les unes aux autres dans n’importe quel ordre, tant qu’elles ne créent pas de référence circulaire. Elles peuvent être calculées en parallèle.
• La valeur de la formule est toujours à jour. La formule peut effectuer un calcul qui dépend des propriétés de contrôle ou des enregistrements de base de données, et à mesure qu’ils changent, la valeur de la formule est automatiquement mise à jour. Vous n’avez pas besoin de mettre à jour manuellement la valeur comme vous le faites avec une variable. Et les formules ne se recalculent que lorsque cela est nécessaire.
• La définition de la formule est immuable. La définition dans Formules est la seule source de vérité et la valeur ne peut pas être modifiée ailleurs dans l’application. Avec des variables, certains codes peuvent changer de façon inattendue une valeur, mais cette situation difficile à déboguer n’est pas possible avec des formules nommées.
• Le calcul de la formule peut être différé. Parce que sa valeur est immuable, elle peut toujours être calculée en cas de besoin, ce qui signifie qu’elle n’a pas besoin d’être calculée tant qu’elle n’est pas nécessaire. Les valeurs de formule qui ne sont pas utilisées jusqu’à ce que screen2 d’une application soit affiché n’ont pas besoin d’être calculées jusqu’à ce que screen2 soit visible. Différer ce travail peut améliorer le temps de chargement de l’application. Les formules nommées sont déclaratives et permettent au système d’optimiser comment et quand elles sont calculées.
• Les formules nommées sont un concept Excel. Power Fx utilise les concepts Excel dans la mesure du possible, car de nombreuses personnes connaissent bien Excel. Les formules nommées sont l’équivalent des cellules nommées et des formules nommées dans Excel, gérées avec le gestionnaire de noms. Elles recalculent automatiquement comme le font les cellules d’une feuille de calcul et les propriétés de contrôle.

Définissez les formules nommées l’une après l’autre dans la propriété Formulas , chacune se terminant par un point-virgule. Le type de la formule est déduit des types des éléments qu’elle contient et de la façon dont ils sont utilisés ensemble. Par exemple, ces formules nommées récupèrent des informations utiles sur l’utilisateur actuel à partir de Dataverse :

UserEmail = User().Email;
UserInfo = LookUp( Users, 'Primary Email' = User().Email );
UserTitle = UserInfo.Title;
UserPhone = Switch( UserInfo.'Preferred Phone', 
                    'Preferred Phone (Users)'.'Mobile Phone', UserInfo.'Mobile Phone',
                    UserInfo.'Main Phone' );

Si la formule de UserTitle doit être mise à jour, vous pouvez facilement la mettre à jour à cet emplacement. Si UserPhone n’est pas nécessaire dans l’application, alors ces appels à la table Utilisateurs dans Dataverse ne sont pas faits. Il n’y a pas de pénalité pour inclure une définition de formule qui n’est pas utilisée.

Certaines limitations des formules nommées :

• Elles ne peuvent pas utiliser les fonctions de comportement ou provoquer des effets secondaires dans l’application.
• Elles ne peuvent pas créer de référence circulaire. Avoir a = b; et b = a; dans la même application n’est pas autorisé.

Fonctions définies par l’utilisateur

Power Fx inclut une longue liste de fonctions intégrées, telles que If, Text et Set. En utilisant des fonctions définies par l’utilisateur, vous pouvez écrire vos propres fonctions qui prennent des paramètres et retournent une valeur, comme les fonctions intégrées. Considérez les fonctions définies par l’utilisateur comme une extension aux formules nommées qui ajoutent des paramètres et prennent en charge les formules de comportement.

Par exemple, vous pouvez définir une formule nommée qui renvoie les livres de fiction d’une bibliothèque :

Library = [ { Title: "The Hobbit", Author: "J. R. R. Tolkien", Genre: "Fiction" },
            { Title: "Oxford English Dictionary", Author: "Oxford University", Genre: "Reference" } ];

LibraryFiction = Filter( Library, Genre = "Fiction" );

Sans paramètres, vous devez définir des formules nommées distinctes pour chaque genre. Mais au lieu de cela, paramétrez votre formule nommée :

LibraryType := Type( [ { Title: Text, Author: Text, Genre: Text } ] );

LibraryGenre( SelectedGenre: Text ): LibraryType = Filter( Library, Genre = SelectedGenre );

Vous pouvez maintenant appeler LibraryGenre( "Fiction" ), LibraryGenre( "Reference" )ou filtrer sur d’autres genres à l’aide d’une fonction définie par l’utilisateur unique.

La syntaxe est la suivante :

FunctionName( [ ParameterName1 : ParameterType1 [ , ParameterName2 : ParameterType2 ... ] ] ) : ReturnType =  ;

• FunctionName : obligatoire. Nom de la fonction définie par l’utilisateur.
• ParameterNames – Facultatif. Nom d’un paramètre de fonction.
• ParameterType(s) : facultatif. Nom d’un type, soit un nom de type de données intégré, un nom de source de données, soit un type défini à l’aide de la fonction Type .
• ReturnType : obligatoire. Type de la valeur de retour de la fonction.
• Formule – Obligatoire. Formule qui calcule la valeur de la fonction en fonction des paramètres.

Vous devez taper chaque paramètre et la sortie de la fonction définie par l’utilisateur. Dans cet exemple, SelectedGenre: Text définit le premier paramètre de la fonction à être de type Text et SelectedGenre est le nom du paramètre utilisé dans le corps de l’opération De filtre. Voir Types de données pour les noms de type pris en charge. La fonction Type est utilisée pour créer un type d’agrégation pour la bibliothèque, afin de pouvoir retourner une table de livres à partir de la fonction.

Vous définissez LibraryType comme une table d’enregistrements pluriel. Si vous souhaitez passer un seul livre à une fonction, vous pouvez extraire le type de l’enregistrement pour cette table à l’aide de la fonction RecordOf :

BookType := Type( RecordOf( LibraryType ) );

IsGenre( Book: BookType, SelectedGenre: Text ): Boolean = (Book.Genre = SelectedGenre);

La correspondance des enregistrements pour les paramètres de fonction est plus stricte que dans d’autres parties de Power Fx. Les champs d’une valeur d’enregistrement doivent être un sous-ensemble approprié de la définition de type et ne peuvent pas inclure de champs supplémentaires. Par exemple, IsGenre( { Title: "My Book", Published: 2001 }, "Fiction" ) génère une erreur.

La récursivité n’est pas encore prise en charge par les fonctions définies par l’utilisateur.

Fonctions de comportement définies par l'utilisateur

Les formules nommées et la plupart des fonctions définies par l’utilisateur ne prennent pas en charge les fonctions de comportement avec des effets secondaires, comme Set ou Notify. En général, évitez de mettre à jour l’état si vous le pouvez. Au lieu de cela, utilisez des modèles de programmation fonctionnels et autorisez Power Fx à recalculer automatiquement les formules. Mais, il y a des cas où c’est inévitable. Pour inclure la logique de comportement dans une fonction définie par l’utilisateur, entourez le corps d’accolades :

Spend( Amount: Number ) : Void = {
    If( Amount > Savings, 
        Error( $"{Amount} is more than available savings" ),
        Set( Savings, Savings - Amount );
        Set( Spent, Spent + Amount) 
    );
}

Vous pouvez maintenant appeler Spend( 12 ) pour vérifier si vous avez 12 dans votre épargne, et si c’est le cas, débitez-le d’ici 12 et ajoutez 12 à la variable Dépenses. Le type de retour de cette fonction est Void car elle ne renvoie pas de valeur.

La syntaxe d’une fonction de comportement définie par l’utilisateur est la suivante :

FunctionName( [ ParameterName1 : ParameterType1 [ , ParameterName2 : ParameterType2 ... ] ] ) : ReturnType = { Formula1 [ ; Formule2 ... ] };

• FunctionName : obligatoire. Nom de la fonction définie par l’utilisateur.
• ParameterNames – Facultatif. Nom d’un paramètre de fonction.
• ParameterType(s) : facultatif. Nom d’un type, qu’il s’agisse d’un nom de type de données intégré, d’un nom de source de données ou d’un type défini avec la fonction Type.
• ReturnType : obligatoire. Type de la valeur de retour de la fonction. Utilisez Void si la fonction ne renvoie pas de valeur.
• Formules – Obligatoire. Formule qui calcule la valeur de la fonction en fonction des paramètres.

Comme pour toutes les formules Power Fx, l’exécution ne se termine pas lorsqu’une erreur se produit. Une fois la fonction Error appelée, la fonction If empêche les modifications apportées aux économies et dépenses. La fonction IfError peut également être utilisée pour empêcher toute exécution ultérieure après une erreur. Même si elle renvoie Void, la formule peut toujours renvoyer une erreur en cas de problème.

Types définis par l'utilisateur

Utilisez des formules nommées avec la fonction Type pour créer des types définis par l’utilisateur. Utilisez := au lieu de = pour définir un type défini par l’utilisateur, par exemple Book := Type( { Title: Text, Author: Text } ). Voir la fonction Type pour obtenir plus d’informations et des exemples.

Propriété OnError

Utilisez OnError pour prendre des mesures lorsqu’une erreur se produit n’importe où dans l’application. Il offre une opportunité globale d’intercepter une bannière d’erreur avant de l’afficher à l’utilisateur final. Vous pouvez également l’utiliser pour consigner une erreur à l’aide de la fonction Trace ou écrire dans une base de données ou un service web.

Dans les applications canevas, le résultat de chaque évaluation de formule est vérifié pour rechercher une erreur. Si une erreur se produit, OnError est évalué avec les mêmes variables d’étendue FirstError et AllErrors que l’application utilise si la formule entière est encapsulée dans une fonction IfError.

Si OnError est vide, une bannière d’erreur par défaut affiche firstError.Message de l’erreur. La définition d’une formule OnError remplace ce comportement, afin que le créateur puisse gérer les rapports d’erreurs si nécessaire. Vous pouvez demander le comportement par défaut dans OnError en réexécisant l’erreur à l’aide de la fonction Error. Utilisez l’approche de rethrowing si vous souhaitez filtrer ou gérer certaines erreurs différemment, mais laissez les autres passer.

OnError ne peut pas remplacer une erreur de calcul de la façon dont IfError peut le faire. Si OnError est appelé, l’erreur s’est déjà produite et est déjà traitée par le biais de calculs de formule comme IfError ; OnError contrôle uniquement les rapports d’erreurs.

Les formules OnError sont évaluées simultanément et il est possible que leur évaluation puisse chevaucher le traitement d’autres erreurs. Par exemple, si vous définissez une variable globale en haut d’un OnError et que vous la lisez ultérieurement dans la même formule, la valeur peut avoir changé. Utilisez la fonction With pour créer une valeur nommée locale à la formule.

Bien qu’OnError traite chaque erreur individuellement, la bannière d’erreur par défaut peut ne pas apparaître individuellement pour chaque erreur. Pour éviter d’avoir trop de bannières d’erreur affichées en même temps, la même bannière d’erreur n’est pas affichée à nouveau si elle a été récemment affichée.

Exemple

Envisagez des contrôles Label et Slider qui sont liés par la formule :

Label1.Text = 1/Slider1.Value

La valeur par défaut du curseur est 50. Si vous déplacez le curseur vers 0, Label1 n’affiche aucune valeur et une bannière d’erreur s’affiche :

Examinons en détail ce qui se passe :

1. Vous déplacez le curseur vers la gauche et la propriété Slider1.Value passe à 0.
2. Label1.Text réévalue automatiquement. La division par zéro se produit, ce qui génère une erreur.
3. Il n’y a pas IfError dans cette formule. L’erreur de division par zéro est renvoyée par l’évaluation de la formule.
4. Label1.Text ne peut rien montrer pour cette erreur, donc il montre un état vide.
5. OnError est invoqué. Puisqu’il n’y a pas de gestionnaire, la bannière d’erreur standard s’affiche avec les informations d’erreur.

Si nécessaire, vous pouvez également modifier la formule en Label1.Text = IfError( 1/Slider1.Value, 0 ). L’utilisation de IfError signifie qu’il n’y a pas d’erreur ou de bannière d’erreur. Vous ne pouvez pas modifier la valeur d’une erreur à partir d’OnError , car l’erreur s’est déjà produite : OnError contrôle uniquement la façon dont elle est signalée.

Si vous ajoutez un gestionnaire OnError , il n’affecte pas les étapes avant l’étape 5, mais modifie la façon dont l’erreur est signalée :

Trace( $"Error {FirstError.Message} in {FirstError.Source}" )

Avec ce gestionnaire OnError , l’utilisateur de l’application ne voit aucune erreur. Toutefois, l’erreur est ajoutée à la trace du moniteur, y compris la source des informations d’erreur de FirstError :

Si vous souhaitez également afficher la bannière d’erreur par défaut avec la trace, relancez l’erreur à l’aide de la fonction Erreuraprès l’appel de trace, comme si la trace n’y était pas :

Trace( $"Error {FirstError.Message} in {FirstError.Source}" );
Error( FirstError )

Propriété OnStart

Note

L’utilisation de la propriété OnStart peut entraîner des problèmes de performances lors du chargement d’une application. Tenez compte de ces alternatives avant d’ajouter une logique à OnStart :

• Pour mettre en cache des données ou configurer des variables globales, utilisez une formule nommée dans la propriété Formulas , le cas échéant.
• Pour définir le premier écran à afficher, utilisez la propriété StartScreen au lieu de Navigate.
• Pour exécuter la logique lorsqu’un écran spécifique est affiché, utilisez la propriété OnVisible de l’écran.

Selon votre contexte, la propriété OnStart peut être désactivée par défaut. Si vous ne le voyez pas et que vous devez l’utiliser, vérifiez les paramètres avancés de l’application pour qu’un commutateur l’active.

Lorsque la règle OnStart non bloquante est activée (valeur par défaut), OnStart s’exécute en même temps que d’autres règles d’application. Par conséquent :

• Les variables initialisées dans OnStart peuvent ne pas être entièrement initialisées lorsque d’autres règles d’application les lisent.
• Un écran peut s’afficher et devenir interactif avant l’exécution d’App.OnStart ou Screen.OnVisible , en particulier si ces fonctions prennent beaucoup de temps.

La propriété OnStart s’exécute lorsque l’utilisateur démarre l’application. Utilisez cette propriété pour :

• Récupérer et mettre en cache des données dans des collections à l’aide de la fonction Collect .
• Paramétrez des variables globales à l’aide de la fonction Set.

Cette formule s’exécute avant l’affichage du premier écran. Aucun écran n’est chargé, vous ne pouvez donc pas définir de variables de contexte avec la fonction UpdateContext. Toutefois, vous pouvez passer des variables de contexte avec la fonction Navigate .

Après avoir modifié la propriété OnStart , testez-la en pointant sur l’objet Application dans le volet Arborescence , en sélectionnant les points de suspension (...), puis en sélectionnant Exécuter OnStart. Contrairement au chargement de l’application pour la première fois, les collections et variables existantes sont déjà définies. Pour commencer avec de nouvelles collections, utilisez la fonction ClearCollect au lieu de la fonction Collect.

Note

• L’utilisation de la fonction Navigate dans la propriété OnStart est supprimée. Les applications existantes fonctionnent toujours. Pendant une durée limitée, vous pouvez l’activer dans les paramètres de l’application (sous Retrait). Mais l’utilisation de Navigate de cette façon peut entraîner des retards de chargement d’application, car il force le système à terminer l’exécution d’OnStart avant d’afficher le premier écran. Utilisez plutôt la propriété StartScreen pour définir le premier écran affiché.
• Le commutateur supprimé est désactivé pour les applications créées avant mars 2021, où vous avez ajouté Navigate to OnStart entre mars 2021 et maintenant. Lorsque vous modifiez ces applications dans Power Apps Studio, une erreur s’affiche. Activez le commutateur retiré pour effacer cette erreur.

Propriété StartScreen

La propriété StartScreen définit l’écran qui s’affiche en premier. Power Apps évalue cette propriété une fois lorsque l’application charge et retourne l’objet d’écran à afficher. Par défaut, cette propriété est vide et le premier écran de l’arborescence studio s’affiche en premier.

StartScreen est une propriété de flux de données qui ne peut pas contenir de fonctions de comportement. Toutes les fonctions de flux de données sont disponibles. Utilisez ces fonctions et signaux pour déterminer l’écran à afficher en premier :

• Fonction Param pour lire les paramètres utilisés pour démarrer l’application.
• Fonction User pour lire les informations sur l’utilisateur actuel.
• Fonctions LookUp, Filter, CountRows, Max et autres qui lisent à partir d’une source de données.
• Appels d’API via un connecteur. Assurez-vous que l’appel retourne rapidement.
• Des signaux tels que Connection, Compass et App.

Note

Les variables et collections globales, y compris celles créées dans OnStart, ne sont pas disponibles dans StartScreen. Des formules nommées sont disponibles et constituent souvent une meilleure alternative pour la réutilisation des formules dans l’application.

Si StartScreen retourne une erreur, le premier écran de l’arborescence de Studio s’affiche comme si StartScreen n’est pas défini. Utilisez la fonction IfError pour intercepter les erreurs et rediriger vers un écran d’erreur.

Après avoir modifié StartScreen dans Studio, testez-le en pointant sur l’objet Application dans le volet Arborescence , en sélectionnant les points de suspension (...), puis en sélectionnant Naviguer vers StartScreen. L’écran change comme si l’application vient de charger.

Exemples

Screen9

Screen9 s’affiche tout d’abord chaque fois que l’application démarre.

If( Param( "admin-mode" ) = 1, HomeScreen, AdminScreen )

Vérifie si le paramètre « mode administrateur » est défini et l’utilise pour décider si HomeScreen ou AdminScreen s’affiche en premier.

If( LookUp( Attendees, User = User().Email ).Staff, StaffPortal, HomeScreen )

Vérifie si un participant est membre du personnel et les dirige vers l’écran approprié au démarrage.

IfError( If( CustomConnector.APICall() = "Forest", 
             ForestScreen, 
             OceanScreen 
         ), 
         ErrorScreen 
)

Dirige l’application en fonction d’un appel d’API vers soit ForestScreen, soit OceanScreen. Si l’API échoue, l’application utilise ErrorScreen à la place.

Propriété StudioVersion

Utilisez la propriété StudioVersion pour afficher ou consigner la version de Power Apps Studio utilisée pour publier une application. Cette propriété permet de déboguer et de vérifier que votre application est republiée avec une version récente de Power Apps Studio.

StudioVersion retourne du texte. Le format de ce texte peut changer au fil du temps, donc le traiter dans son ensemble et ne pas extraire des parties individuelles.