Dela via

Program-objekt i Power Apps

  • Artikel

Gäller: Arbetsyteappar Modellbaserade program

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.

App-objektet i trädfönstret.

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.

Kommentar

  • ConfirmExit fungerar inte i program som är inbäddade i, till exempel Power BI och SharePoint.
  • Nu kan egenskaperna endast referera till den första skärmen om förhandsgranskningsfunktion fördröjd inläsning är aktiverad (som är standard för nya appar). Om en referens görs visas Power Apps Studio inte ett felmeddelande, men den resulterande publicerade programmet öppnas inte i Power Apps Mobil eller i en webbläsare. Vi arbetar aktivt med att lyfta den här begränsning. Under tiden kan du inaktivera Fördröjd inläsning i Inställningar>Kommande funktioner (under Förhandsgranskning).

ConfirmExit

ConfirmExit är en boolesk egenskap som när den är true ö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.

Kommentar

Appobjekt har ytterligare två egenskaper OnMessage och BackEnabled experimentella. Dessa egenskaper tas då bort från appobjektet. Vi rekommenderar att du inte gör det använder dessa egenskaper i produktionsmiljön.

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.

    Generisk bekräftelsedialogruta.

  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.

    Dialogrutan för formulärspecifik bekräftelse.

Konfigurera instrumenteringsnyckeln 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 bestämmer formler värdet för kontrollegenskaper. 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 ett hörn av appen som tillverkaren förser med, en förändring som någon annan har gjort och som kan vara svårt att hålla reda på.

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 finns risken att viss kod oväntat ändrar ett värde, men denna svårfelsökta situation är inte möjlig med namngivna formler.
  • 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 räknar om automatiskt på samma sätt som celler i ett kalkylblad och det gör även kontrollegenskaper.

Namngivna formeln definieras, en efter en i egenskapen Formler, som båda slutar med ett semikolon. Typen av formel härleds från typerna av element i formeln 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.

Användardefinierade funktioner

Viktigt

Power Fx innehåller en lång lista med inbyggda funktioner, till exempel If, Text och Set. Med användardefinierade funktioner kan du skriva egna funktioner som tar parametrar och returnerar ett värde, precis som de inbyggda funktionerna gör. Du kan tänka på användardefinierade funktioner som ett tillägg till namngivna formler som lägger till parametrar och stöder beteendeformler.

Du kan till exempel definiera en namngiven formel som returnerar skönlitterära böcker från ett bibliotek:

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" );

Utan parametrar skulle vi behöva definiera separata namngivna formler för varje genre. Men låt oss i stället parametrisera vår namngivna formel:

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

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

Nu kan vi anropa LibraryGenre( "Fiction" ), LibraryGenre( "Reference" ) eller filtrera på andra genrer med en enda användardefinierad funktion.

Syntaxen är:

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

  • FunctionName – Krävs. Namnet på den användardefinierade funktionen.
  • ParameterName(s) – Valfritt. Namnet på en funktionsparameter.
  • ParameterType(s) – Valfritt. Namnet på en typ, antingen ett inbyggt datatypsnamn, ett namn på en datakälla eller en typ som definierats med funktionen Typ.
  • ReturnType – Krävs. Typen av returvärde från funktionen.
  • Formula – obligatoriskt. Formeln som beräknar funktionens värde baserat på parametrarna.

Varje parameter och utdata från den användardefinierade funktionen måste vara typade. I det här exemplet, SelectedGenre: Text definieras den första parametern till vår funktion som av typen Text och SelectedGenre är namnet på parametern som används i brödtexten för åtgärden Filter. Se Datatyper för de typnamn som stöds. Funktionen Typ används för att skapa en aggregerad typ för vårt bibliotek, så att vi kan returnera en tabell med böcker från vår funktion.

Vi definierade LibraryType som en tabelltyp med flera poster. Om vi vill skicka en enda bok till en funktion kan vi extrahera typen av post för den här tabellen med funktionen RecordOf:

BookType := Type( RecordOf( LibraryType ) );

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

Matchning av poster för funktionsparametrar är striktare än i andra delar av Power Fx. Fälten i ett postvärde måste vara en korrekt delmängd av typdefinitionen och får inte innehålla ytterligare fält. Till exempel kommer IsGenre( { Title: "My Book", Published: 2001 }, "Fiction" ) att resultera i ett fel.

Observera att rekursion ännu inte stöds av användardefinierade funktioner.

Användardefinierade funktioners beteende

Namngivna formler och de flesta användardefinierade funktioner stöder inte beteendefunktioner med sidoeffekter, till exempel Ange eller Meddela. I allmänhet är det bäst att undvika att uppdatera tillstånd om du kan, utan i stället förlita dig på funktionella programmeringsmönster och låta Power Fx automatiskt beräkna om formler efter behov. Men det finns fall där det är oundvikligt. Om du vill inkludera beteendelogik i en användardefinierad funktion omsluter du brödtexten inom klammerparenteser:

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

Nu kan vi anropa Spend( 12 ) för att kontrollera om vi har 12 i vårt sparande, och i så fall debitera det med 12 och lägga till 12 till spenderade variabel. Returtypen för den här funktionen är Annullera eftersom den inte returnerar något värde.

Syntaxen för en beteendeanvändardefinierad funktion är:

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

  • FunctionName – Krävs. Namnet på den användardefinierade funktionen.
  • ParameterName(s) – Valfritt. Namnet på en funktionsparameter.
  • ParameterType(s) – Valfritt. Namnet på en typ, antingen ett inbyggt datatypsnamn, ett namn på en datakälla eller en typ som definierats med funktionen Typ.
  • ReturnType – Krävs. Typen av returvärde från funktionen. Använd Annullera om funktionen inte returnerar något värde.
  • Formula(s) – obligatoriskt. Formeln som beräknar funktionens värde baserat på parametrarna.

Precis som med alla Power Fx-formler avslutas inte körningen när ett fel påträffas. När funktionen Fel har anropats förhindrar If att ändringar Besparingar och Använda sker. Funktionen IfError kan också användas för att förhindra ytterligare körning efter ett fel. Även om den returnerar Annullera kan formeln fortfarande returnera ett fel om det uppstår ett problem.

Användardefinierade typer

Viktigt

Namngivna formler kan användas med funktionen Type för att skapa användardefinierade typer. Använd := i stället för = för att definiera en användardefinierad typ, till exempel Book := Type( { Title: Text, Author: Text } ). Mer information och exempel finns i funktionen Typ.

Egenskapen OnError

Använd OnError för att vidta åtgärder när ett fel inträffar var som helst i appen. 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.

I arbetsyteappen kontrolleras resultatet av varje formelutvärdering för att ett fel uppstår. Om ett fel uppstår utvärderas OnError 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. Använd omkastningsmetoden 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 som IfError kan. Om OnError anropas har felet redan inträffat och har redan bearbetats genom formelberäkningar som IfError; OnError kontrollerar endast felrapportering.

OnError formler utvärderas samtidigt och det är möjligt att utvärderingen överlappar med 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, kommer inte samma felbanner inte att visas igen om den nyligen har visats.

Exempel

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

Label1.Text = 1/Slider1.Value

Label- och slider kontroll bundna genom 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:

Slider-kontroll flyttas till 0, vilket resulterar i en division med noll fel och en felbanderoll.

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 omutvärderas igen 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ågonting för felet, så ett tomt tillstånd visas.
  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 ). Användning av IfError 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}" )

App.OnError formeluppsättning för att generera ett spår.

Med denna OnError-hanterare på plats kommer appanvändaren inte att märka av något fel. Felet läggs dock till i Övervaka spårning, tillsammans med källan till felinformationen från FirstError:

Slider-kontroll flyttas till 0, vilket resulterar i en division med noll fel och ingen felbanderoll.

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

Kommentar

Om egenskapen OnStart används kan det orsaka prestandaproblem när ett program läses in. Vi håller på att skapa alternativ till de två främsta orsakerna till att använda egenskapen att cachelagra data och konfigurera globala variabler. Vi har redan skapat ett alternativ för att definiera den första vyn som ska visas med Navigate. Beroende på sammanhanget kan egenskapen komma att inaktiveras som standard. Om du inte ser den men behöver använda den kan du kontrollera programmets avancerade inställningar för att hitta ett reglage för att aktivera den. Egenskapen OnVisible för en vy kan också användas. När den icke-blockerande OnStart-regeln är aktiverad tillåter den som standard att OnStart-funktionen körs samtidigt med andra appregler. Så om variabler som refereras i andra appregler initieras i OnStart-funktionen kanske de inte har initierats helt ännu. Dessutom finns det en möjlighet att en skärm kan renderas och bli interaktiv innan funktionerna Screen.OnVisible eller App.OnStart har slutförts, särskilt om de tar lång tid att slutföra.

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.

Snabbmeny för programobjekt för Kör OnStart

Kommentar

  • Användning av funktionen Navigate i egenskapen OnStart har dragits in. Befintliga program fortsätter att fungera. Under en begränsad tid kan du fortsätta aktivera funktionen i appinställningarna (finns under Indraget). Om du använder Navigera på detta sätt kan det emellertid medföra fördröjningar i programmets inläsning eftersom systemet tvingas att utvärdera OnStart helt och hålet innan den första vyn visas. Använd egenskapen StartScreen istället för att beräkna den första vy som visas.
  • Det kasserade reglaget kommer att vara avstängd för appar som skapades före mars 2021, där du lade till Navigate to OnStart mellan mars 2021 och nu. När du redigerar sådana program i Power Apps Studio kan ett felmeddelande visas. Slå på det kasserade reglaget för att rensa felet.

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:

  • Funktionen Param för att läsa parametrar som används för att starta appen.
  • Funktionen User 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.

Kommentar

Globala variabler och samlingar, även de som har skapats i OnStart, är inte tillgängliga i StartScreen. Namngivna formler är tillgängliga och är ofta ett bättre alternativ för återanvändning av formler i hela appen.

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.

Navigera till StartScreen

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.