Program-objekt i Power Apps

Gäller för: Arbetsyteappar Modellbaserade appar

Tillhandahåller information om programmet som körs och kontroll över programmets beteende.

Beskrivning

Precis som en kontroll tillhandahåller objektet Program egenskaper som identifierar vilken skärm som visas och uppmanar användaren att spara ändringar så att de inte går förlorade. Varje program har ett program-objekt.

Du kan skriva formler för vissa egenskaper i Program-objekt. Längst upp i fönstret Trädvy, välj Program-objekt som med någon annan kontroll eller skärm. Visa och redigera en av objektets egenskaper genom att markera det i listrutan till vänster om formelfältet.

Egenskapen ActiveScreen

ActiveScreen-egenskapen identifierar den skärm som visas.

Egenskapen returnerar ett skärmobjekt. Använd den om du vill referera till egenskaperna för det visade fönstret, till exempel namnet med formeln App.ActiveScreen.Namn. Du kan också jämföra den här egenskapen med ett annat skärmobjekt, till exempel med jämförelseformeln App.ActiveScreen = Screen2 för att testa om Screen2 är den skärm som visas för tillfället.

Använd funktionen Back eller Navigate för att ändra skärmen som visas.

Egenskapen BackEnabled

Egenskapen BackEnabled ändrar hur appen svarar på enhetens bakåtgest (svep eller använd hårdvaruknappen bakåt på Android-enheter, svep från vänster på iOS-enheter) när de körs i Power Apps mobil. När den är aktiverad navigerar enhetens bakåtgest tillbaka till skärmen som senast visades, vilket liknar formeln Tillbaka. När den är inaktiverad återför enhetens bakåtgest användaren till applistan.

Egenskaper för ConfirmExit

Ingen vill förlora ändringar som inte har sparats. Använd egenskaperna ConfirmExit och ConfirmExitMessage för att varna användaren innan de stänger programmet.

ConfirmExit

ConfirmExit är en boolesk egenskap som, när den är sann, öppnar en bekräftelsedialogruta innan appen stängs. Som standard är den här egenskapen false och ingen dialogruta visas.

I situationer där användaren kan ha osparade ändringar i appen använder du den här egenskapen för att visa en bekräftelsedialogruta innan du avslutar appen. Använd en formel som kan kontrollera variabler och kontrollegenskaper t.ex. egenskapen Unsaved för kontrollen Edit form.

Dialogrutan för bekräftelse visas i alla situationer där data kan gå förlorade, t.ex. i följande exempel:

• Kör funktionen Exit.
• Om programmet körs i en webbläsare:
  • Stänger webbläsaren eller webbläsaren som programmet körs i.
  • Välj Bakåt-knappen i webbläsaren.
  • Kör funktionen Launch med LaunchTarget av Self.
• Om appen körs i Power Apps Mobile (iOS eller Android):
  • Svep för att växla till ett annat program i Power Apps Mobile.
  • Välja bakåt knappen på en Android-enhet.
  • Kör funktionen Launch för att starta en ny arbetsyteapp.

Det exakta utseendet på en bekräftelse dialogruta kan vara mellan olika enheter och versioner av Power Apps.

Bekräftelsedialogrutan visas inte i Power Apps Studio.

ConfirmExitMessage

Som standard visas ett allmänt meddelande i bekräftelse dialogrutan, till exempel "Du kanske har osparade ändringar". på användarens språk.

Använd ConfirmExitMessage för att ange ett anpassat meddelande i bekräftelse dialogrutan. Om den här egenskapen är blank används standardvärdet. Anpassade meddelanden trunkeras vid behov så att de passar i bekräftelse dialogrutan så se till att meddelandet alltid innehåller några rader.

I en webbläsare kan bekräftelse dialogrutan visas med ett allmänt meddelande från webbläsaren.

Exempel

1. Skapa ett program som innehåller två Form-kontrollen, AccountForm och ContactForm.

2. Ange Program objekt egenskap ConfirmExit till följande uttryck:

   AccountForm.Unsaved Or ContactForm.Unsaved
   

   Den här dialogrutan visas om användaren ändrar data i något av formulären och sedan försöker stänga appen utan att spara ändringarna.

   

3. Ange App objekt egenskap ConfirmExitMessage till följande formel:

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

   Den här dialogrutan visas om användaren ändrar data i kontoformulären och sedan försöker stänga programmet utan att spara ändringarna.

   

Konfigurera instrumentationsnyckel för Application Insights

Om du vill exportera systemgenererade apploggar till Application Insights måste du konfigurera instrumentationsnyckeln för arbetsyteappen.

1. Öppna appen för redigering i Power Apps Studio.
2. Välj objektet App i trädvyn i det vänstra navigeringsfönstret.
3. Ange Instrumentationsnyckeln i egenskapsfönstret.

Om data inte skickas till App Insights kontaktar du din Power Platform-administratör och kontrollera att App Insights är inaktiverat på klientorganisationsnivå.

Egenskapen Formel

Använd namngivna formeln i egenskapen Formler för att definiera en formel som kan återanvändas i hela programmet.

I Power Apps styrs egenskaper av formeln. Om du till exempel vill ange en konsekvent bakgrundsfärg i ett program kan du ange egenskapen Fill för varje till en gemensam formel:

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

På så många platser där formeln kan visas blir det svårare och svårare att uppdatera alla om det behövs. Du kan skapa en global variabel i OnStart om du vill ange färgen en gång och sedan återanvända värdet i programmet:

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

Även om den här metoden är bättre beror den också på OnStart som körs innan värdet för BGColor upprättas. BGColor kan också manipuleras i något hörn av appen som tillverkaren inte är medveten om, en ändring som gjorts av någon annan och som kan vara svår att spåra.

Namngivna formeln utgör ett alternativ. Precis som vi ofta skriver kontrollegenskap = uttryck, kan vi i stället skriva namn = uttryck och sedan återanvända namn i programmet för att ersätta uttryck. Definitionerna för dessa formeln görs med egenskapen Formel:

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

Fördelarna med att använda namngivna formeln är:

• Formelns värde är alltid tillgängligt. Det finns inget tidsberoende, ingen OnStart som måste köras först innan värdet har angetts, ingen tid då formelns värde är felaktigt. Namngivna formeln kan referera till varandra i vilken ordning som helst, så länge de inte skapar en cirkelreferens. De kan beräknas samtidigt.
• Formelns värde är alltid uppdaterat. Formeln kan göra en beräkning som är beroende av kontrollegenskaper eller databasposter och när de ändras uppdateras formelns värde automatiskt. Du behöver inte uppdatera värdet manuellt på samma sätt som med en variabel. Och formeln beräknas bara om när det behövs.
• Formelns definition är oföränderlig. Definitionen i Formler är den enda sanningens källa och värdet kan inte ändras i programmet. Med variabler är det möjligt att en viss kod oväntat ändrar ett värde, men detta är inte möjligt med namngivna formeln.
• Formelns beräkning kan skjutas upp. Eftersom värdet är oföränderligt kan det alltid beräknas när det behövs, vilket innebär att det inte behöver beräknas förrän det behövs. Formelvärden som inte används förrän skärm2 i ett program visas behöver inte beräknas förrän skärm2 visas. Om du avser detta arbete kan tiden för appbelastningen förbättras. Namngivna formeln är deklarativa och tillhandahåller möjligheter för systemet att optimera hur och när de beräknas.
• Namngivna formeln är ett Excel-koncept. Power Fx används Excel-begrepp när det är möjligt eftersom så många känner till Excel. Namngivna formeln motsvarar namngivna celler och namngivna formeln i Excel, hanterade med namnhanteraren. De beräknas om automatiskt som ett kalkylblad, precis som med kontrollegenskaper.

Namngivna formeln definieras, en efter en i egenskapen Formler, som båda slutar med ett semikolon. Formelns typ utgår från uttryckstyperna, som baseras på elementtyperna i uttrycken och hur de används tillsammans. Dessa namngivna formeln hämtar till exempel användbar information om den aktuella användaren från 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' );

Om formeln för UserTitle måste uppdateras går det enkelt att göra det på den här platsen. Om UserPhone inte behövs i programmet görs inte samtalen till tabellen Användare i Dataverse. Ingen anledning att ta med en formeldefinition som inte används.

Vissa begränsningar för namngivna formeln:

• De kan inte använda beteendefunktioner eller på annat sätt orsaka biverkningar i programmet.
• De kan inte skapa en cirkelreferens. Att ha a = b; och b = a; i samma program är inte tillåtet.

Egenskapen OnError

Använd OnError för att vidta åtgärder när ett fel har identifierats. Det ger en global möjlighet att skapa en felbanderoll innan den visas för slutanvändaren. Den kan även användas för att logga ett fel med funktionen Trace eller skriva till en databas eller webbtjänst.

Resultatet av varje formelutvärdering kontrolleras för att ett fel uppstår. Om det är ett fel kommer OnError utvärderas med samma FirstError and AllErrors omfattningsvariabler som skulle ha funnits om hela formeln var insvept i en IfError funktion.

Om OnError är tom visas en standardfelbanderoll med FirstError.Message för felet. Om du definierar OnError formel åsidosätts detta beteende och skaparen kan hantera felrapporteringen som den passar. Standardfunktionen kan begäras i OnError genom att ange felet igen med Error funktion. Det här är användbart om vissa fel ska filtreras bort eller hanteras på ett annat sätt, medan andra ska skickas vidare.

OnError kan inte ersätta ett fel i beräkningar på samma sätt som IfError kan. På den punkten att OnError anropas, har felet redan inträffat och det har redan bearbetats genom formelberäkningar. *OnError* styr endast felrapportering.

OnError-formler utvärderas samtidigt och det är möjligt att utvärderingen av dem överlappar bearbetningen av andra fel. Till exempel, om du ställer in en global variabel överst i en OnError och läs det senare i samma formel, kan värdet ha ändrats. Använd funktionen With vill skapa ett namngivet värde som är lokalt i formeln.

Även om varje fel bearbetas individuellt av OnError kanske inte standardfelbanderollen visas för varje fel individuellt. Om du vill undvika att för många felbanderoller visas samtidigt, utlöser inte samma fel en ny felbanderoll om den nyligen visas.

Exempel

Överväg en Label kontroll och Slider som är bundna samman med formeln:

Label1.Text = 1/Slider1.Value

Reglaget har som standard 50. Om reglaget flyttas till 0 visar Label1 inget värde och en felbanderoll visas:

Nu ska vi se vad som har hänt:

1. Användaren flyttade bilden till vänster och egenskapen Slide1.Value ändrades till 0.
2. Label1.Text omvärderades automatiskt. En delning med noll inträffade och genererade ett fel.
3. Det finns ingen IfError i den här formeln. Divisionsfelet med noll returneras av formelutvärderingen.
4. Label1.Text kan inte visa något för det här felet, så det visar ett tomt tillstånd.
5. OnError anropas. Eftersom det inte finns någon hanterare visas standardfelbanderollen med felinformation.

Om det behövs kan vi också ändra formeln till Label1.Text = IfError( 1/Slider1.Value, 0 ). Detta resulterar inte i något fel eller felbanderoll. Det går inte att ändra värdet för ett fel i OnError eftersom det redan har inträffat ett fel, utan det är bara en fråga om hur det ska rapporteras.

Om vi lägger till en OnError hanteraren kommer det inte att ha någon inverkan före steg 5, men det kan påverka hur felet rapporteras:

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

Med detta på plats kommer det inte att finnas några fel utifrån appanvändarens perspektiv. Felet läggs dock till i Övervaka spårning, tillsammans med källan till felinformationen från FirstError:

Om vi också ville ha samma standardfelsbanner visad utöver spårningen, kan vi kasta om felet med funktionen Error ater att Trace anropar som om Trace inte var där:

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

OnStart egenskap

Egenskapen OnStart körs när användaren startar programmet. Denna egenskap används ofta för att utföra följande uppgifter:

• Hämta och cachelagra data i samlingar med hjälp av funktionen Collect.
• Ange globala variabler med hjälp av funktionen Set.

Den här formeln utvärderas innan den första skärmen visas. Ingen skärm visas och du kan inte ange processvariabler med funktionen UpdateContext. Däremot kan du överföra variabler med funktionen Navigate.

När du har ändrat egenskapen OnStart testar du den genom att hovra över objektet Program i rutan Trädvy, välja ellipsen (...) och sedan välja Run OnStart. Till skillnad från när programmet laddas för första gången, kommer befintliga samlingar och variabler redan att anges. Om du vill börja med tomma samlingar använder du funktionen ClearCollect i stället för funktionen Collect.

Egenskapen StartScreen

Egenskapen StartScreen avgör vilken vy som ska visas först. Denna utvärderas en gång när programmet läses in och returnerar det vyobjekt som ska visas. Som standard kommer egenskapen att vara tom, och den första vyn i trädvyn för Studio Tree visas först.

StartScreen är en dataflödesegenskap som inte kan innehålla beteendefunktioner. Alla dataflödesfunktioner är tillgängliga, särskilt med hjälp av dessa funktioner och signaler för att avgöra vilken vy som ska visas först:

• Param-funktion för att läsa parametrar som används för att starta appen.
• Användarfunktion för att läsa information om den aktuella användaren.
• LookUp, Filter, CountRows, Max och andra funktioner som läser från en datakälla.
• Alla API-anrop via en anslutning, men var försiktig så att det returnerar snabbt.
• Signaler som till exempel Anslutning, Kompass och Program.

Om StartScreen returnerar ett fel visas den första vyn i Studio Tree som om StartScreen inte har angetts. Använd funktionen IfError för att fånga upp eventuella fel och omdirigera till lämplig felvy.

När du har ändrat StartScreen i Studio testar du det genom att hovra över objektet App i rutan Trädvy, välja ellipsen (...) och sedan Navigera till StartScreen. Vyn ändras som om programmet redan hade lästs in.

Exempel

Screen9

Anger att Screen9 ska visas först när appen startar.

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

Kontrollerar om "adminläget" i Param har angetts av användaren och använder det för att avgöra om startvyn eller adminvyn ska visas först.

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

Kontrollerar om en deltagare i en konferens ingår i personalen och dirigerar denne till rätt vy vid start.

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

Dirigerar programmet baserat på ett API-anrop till antingen ForestScreen eller OceanScreen. Om API:et misslyckas av någon anledning används ErrorScreen istället.

StudioVersion-egenskap

Använd egenskapen StudioVersion om du vill visa eller logga den version av Power Apps Studio som användes för att publicera en app. Det kan vara användbart vid felsökning och för att säkerställa att appen har publicerats på nytt med en ny version av Power Apps Studio.

StudioVersion returneras som text. Textformatet kan ändras med tiden och ska behandlas som en helhet undvik att extrahera enskilda delar.