Objet App dans Power Apps

S’applique à : Applications Canvas

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 qu’elles ne soient pas perdues. 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.

Propriété ActiveScreen

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

Cette propriété renvoie un objet d’écran. Utilisez-le pour référencer les propriétés de l’écran actuel, comme 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.

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 indique si l’utilisateur modifie les données dans l’un ou l’autre formulaire, puis tente de fermer l’application sans enregistrer ces modifications.e les données modifiées dans l’un ou l’autre formulaire, puis tente de fermer l’application sans enregistrer ces modifications.

   [ !div clas1. Définissez la propriété ConfirmExitMessage de l’objet appli à cette formule :

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

   La boîte de dialogue indique si l’utilisateur modifie les données dans le formulaire Compte, puis tente de fermer l’application sans enregistrer ces modifications.

   

Configurer la chaîne de connexion pour Application Insights

Pour exporter les journaux d’application générés par le système vers Application Insights, configurez la chaîne de connexion de votre application canevas.

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 App Insights est désactivé au niveau du locataire.

Propriété des formules

Utilisez des formules nommées, dans la propriété Formules, pour définir une formule qui peut être réutilisée dans toute 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 dans une application, vous pouvez définir la propriété Fill pour chacun sur une formule commune :

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

Avec autant d’endroits où cette formule peut apparaître, il devient fastidieux et risqué en termes d’erreur de toutes les mettre à jour si une modification est nécessaire. Au lieu de cela, vous pouvez créer une variable globale dans OnStart pour définir la couleur une fois, puis réutiliser 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 nous écrivons couramment control-property = expression, nous pouvons écrire à la place name = expression, puis réutiliser name dans notre application pour remplacer expression. Les définitions de ces formules sont faites 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 les variables, il est possible que du code modifie une valeur de manière inattendue, mais cette situation difficile à déboguer n’est pas possible avec les 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.

Les formules nommées sont définies les unes après les autres 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 pour UserTitle doit être mise à jour, cela peut être fait facilement à cet endroit. 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. Les fonctions définies par l’utilisateur vous permettent d’écrire vos propres fonctions qui prennent des paramètres et renvoient une valeur, tout comme le font les fonctions intégrées. Vous pouvez considérer les fonctions définies par l’utilisateur comme une extension des formules nommées qui ajoute des paramètres et prend 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, nous devrions définir des formules nommées distinctes pour chaque genre. Mais au lieu de cela, paramétrons notre formule nommée :

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

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

Maintenant, nous pouvons appeler LibraryGenre( "Fiction" ), LibraryGenre( "Reference" ) ou filtrer sur d’autres genres avec une seule fonction définie par l’utilisateur.

La syntaxe est la suivante :

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

• FunctionName : obligatoire. Nom de la fonction définie par l’utilisateur.
• ParameterName(s) – 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.
• Formula : obligatoire. Formule qui calcule la valeur de la fonction en fonction des paramètres.

Chaque paramètre et la sortie de la fonction définie par l’utilisateur doivent être saisis. Dans cet exemple, SelectedGenre: Text définit le premier paramètre de notre fonction comme étant de type Texte et SelectedGenre est le nom du paramètre utilisé dans le corps pour l’opération Filtrer. 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 notre bibliothèque, afin que nous puissions renvoyer une table de livres à partir de notre fonction.

Nous avons défini LibraryType comme une table plurielle de type d’enregistrements. Si nous souhaitons transmettre un seul livre à une fonction, nous pouvons extraire le type de l’enregistrement de cette table avec 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 correct 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érera une erreur.

Notez que 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, il est préférable d’éviter de mettre à jour l’état si vous le pouvez, au lieu de vous baser sur des modèles de programmation fonctionnels et d’autoriser Power Fx à recalculer automatiquement les formules selon les besoins. 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) 
    );
}

Maintenant, nous pouvons appeler Spend( 12 ) pour vérifier si nous avons 12 dans notre épargne et, si tel est le cas, la débiter de 12 et ajouter 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.
• ParameterName(s) – 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.
• Formule(s) – Obligatoire(s). 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 que la fonction Error a été appelée, la fonction If empêche les modifications apportées à Savings et Spent de se produire. 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

Les formules nommées peuvent être utilisé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. Elle offre une opportunité globale d’intercepter une bannière d’erreur avant qu’elle ne soit affichée à l’utilisateur final. Cela peut être également utilisé pour enregistrer une erreur avec 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 qui auraient été utilisées si la formule entière avait été 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 avec 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 elle a déjà été traitée via des 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 que chaque erreur soit traitée individuellement par OnError, 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 ne déclenchera pas à nouveau si elle a été affichée récemment.

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 le curseur est déplacé vers 0, Label1 n’affichera aucune valeur et une bannière d’erreur s’affichera :

Voyons en détail ce qu’il s’est passé :

1. L’utilisateur a déplacé la diapositive vers la gauche et la propriété Slide1.Value est passée sur 0.
2. Label1.Text a été automatiquement réévaluée. Une division par zéro s’est produite, générant 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 avec la fonction Erreuraprès l’appel de trace, comme si la trace n’était pas là :

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

Propriété OnStart

La propriété OnStart s’exécute lorsque l’utilisateur démarre l’application. Cette propriété est souvent utilisée 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.

Propriété StartScreen

La propriété StartScreen définit l’écran qui s’affiche en premier. Elle est évaluée 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.

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.