App-objekt i Power Apps

Gjelder for: Lerretsapper

Få informasjon om appen som kjører for øyeblikket, og kontroller virkemåten til appen.

Beskrivelse

I likhet med en kontroll har App-objektet egenskaper som identifiserer hvilket skjermbilde som vises, og ber deg om å lagre endringer slik at du ikke mister dem. Hver app har et app-objekt.

Skriv formler for enkelte egenskaper for App-objektet . Øverst i Trevisning-ruten velger du app-objektet, på samme måte som andre kontroller eller skjermer. Hvis du vil vise eller redigere en av objektets egenskaper, velger du den i rullegardinlisten til venstre for formellinjen.

Denne artikkelen dekker følgende egenskaper for appobjekter :

• ActiveScreen – skjermen som for øyeblikket vises.
• BackEnabled – hvordan appen reagerer på enhetens tilbakebevegelse.
• ConfirmExit og ConfirmExitMessage – advar brukeren før du lukker appen.
• Tilkoblingsstreng – konfigurere logging av programinnsikter.
• Formler – definer navngitte formler, brukerdefinerte funksjoner og brukerdefinerte typer.
• OnError – behandle feil globalt.
• OnStart – kjør logikk når appen starter.
• StartScreen – angi skjermen som vises først når appen lastes inn.
• StudioVersion – returner Power Apps Studio-versjonen som publiserte appen.

ActiveScreen-egenskapen

ActiveScreen-egenskapen identifiserer skjermen som for øyeblikket vises.

Denne egenskapen returnerer et skjermobjekt. Bruk den til å referere til egenskapene for gjeldende skjerm, for eksempel navnet med formelen App.ActiveScreen.Name. Du kan også sammenligne denne egenskapen med et annet skjermobjekt, for eksempel med sammenligningsformelen App.ActiveScreen = Screen2 for å kontrollere om Screen2 er gjeldende skjerm.

Bruk tilbake- eller navigeringsfunksjonen til å bytte skjermen som vises.

Egenskapen BackEnabled

BackEnabled-egenskapen endrer hvordan appen reagerer på enhetens tilbakebevegelse (sveip eller bruk tilbakeknappen for maskinvaren på Android-enheter, eller sveip fra venstre på iOS-enheter) når du kjører i Power Apps Mobile. Når den er aktivert, går tilbakebevegelsen for enheten tilbake til skjermen som sist ble vist, som ligner på Tilbake-formelen . Når den er deaktivert, tar enheten tilbake-bevegelsen brukeren til applisten.

ConfirmExit-egenskaper

Ingen ønsker å miste ulagrede endringer. Bruk egenskapene ConfirmExit og ConfirmExitMessage til å advare brukeren før du lukker appen.

ConfirmExit

ConfirmExit er en boolsk egenskap som åpner en bekreftelsesdialogboks før appen lukkes når sann. Som standard er denne egenskapen usann, og det vises ingen dialogboks.

Når brukeren kan ha endringer som ikke er lagret i appen, kan du bruke denne egenskapen til å vise en bekreftelsesdialogboks før du avslutter appen. Bruk en formel som kontrollerer variabler og kontrollegenskaper (for eksempel egenskapen Ulagret for redigeringsskjemakontrollen ).

Bekreftelsesdialogboksen vises i enhver situasjon der data kan gå tapt, for eksempel:

• Kjør exit-funksjonen .
• Hvis appen kjører i en nettleser:
  • Lukk nettleseren eller nettleserfanen der appen kjører.
  • Velg tilbakeknappen for nettleseren.
  • Kjør Start-funksjonen med en LaunchTarget of Self.
• Hvis appen kjører i Power Apps Mobile (iOS eller Android):
  • Sveip for å bytte til en annen app i Power Apps Mobile.
  • Velg tilbake-knappen på en Android-enhet.
  • Kjør Start-funksjonen for å starte en annen lerretsapp.

Det nøyaktige utseendet på bekreftelsesdialogboksen kan variere på tvers av enheter og versjoner av Power Apps.

Bekreftelsesdialogboksen vises ikke i Power Apps Studio.

ConfirmExitMessage

Bekreftelsesdialogboksen viser som standard en generisk melding, for eksempel Du har kanskje ulagrede endringer." på brukerens språk.

Bruk ConfirmExitMessage til å lage en egendefinert melding i bekreftelsesdialogboksen. Hvis denne egenskapen er tom, brukes standardverdien. Egendefinerte meldinger avkortes etter behov for å passe inn i bekreftelsesdialogboksen, så hold meldingen til noen få linjer på det meste.

I en nettleser kan bekreftelsesdialogboksen vise en generell melding fra nettleseren.

Eksempel

1. Sett App-objektets ConfirmExit-egenskap til dette uttrykket:

   AccountForm.Unsaved Or ContactForm.Unsaved
   

   Dialogboksen vises hvis brukeren endrer data i begge skjemaer, og deretter prøver å lukke appen uten å lagre disse endringene.

   

2. Sett App-objektets ConfirmExitMessage-egenskap til denne formelen:

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

   Dialogboksen viser en skjemaspesifikk melding når brukeren endrer data i begge skjemaer, og deretter prøver å lukke appen uten å lagre disse endringene.

   

Tilkoblingsstrengegenskap

Bruk egenskapen Tilkoblingsstreng til å eksportere systemgenererte programlogger til Application Insights.

Slik angir du tilkoblingsstreng:

1. Åpne appen åpen for redigering i Power Apps Studio.
2. Velg App-objektet fra trevisningen i venstre navigasjon.
3. Skriv inn tilkoblingsstrengen i egenskapsruten.

Hvis data ikke sendes til Application Insights, kontakter du Power Platform-administratoren og kontrollerer om Application Insights er deaktivert på leiernivå.

Formler-egenskapen

Bruk egenskapen Formler til å definere gjenbrukbar logikk på tvers av appen. Egenskapen Formler støtter tre konstruksjoner:

• Navngitte formler – tilordne et navn til en formel og bruk verdien på nytt i hele appen.
• Brukerdefinerte funksjoner – navngitte formler som tar parametere og returnerer en verdi.
• Brukerdefinerte typer – navngitte typer du kan bruke på nytt i formler og funksjonssignaturer.

Navngitte formler

Bruk navngitte formler i egenskapen Formler til å definere en formel som du kan bruke på nytt i hele appen.

I Power Apps bestemmer formler verdien av kontrollegenskaper. Hvis du for eksempel vil angi bakgrunnsfargen konsekvent på tvers av en app, angir du fyllegenskapen for hver kontroll til en felles formel:

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

Med så mange steder der denne formelen vises, blir den kjedelig og feilutsatt for å oppdatere dem alle hvis en endring er nødvendig. Opprett i stedet en global variabel i OnStart for å angi fargen én gang, og bruk deretter verdien på nytt i hele appen:

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

Selv om denne metoden er bedre, avhenger den også av at OnStart kjører før verdien for BGColor etableres. BGColor kan også manipuleres i en del av appen som oppretteren ikke er klar over, en endring som er gjort av andre, og som kan være vanskelig å spore.

Navngitte formler er et alternativ. Akkurat som du ofte skriver kontroll-egenskap = uttrykk, kan du i stedet skrive navn = uttrykk og deretter bruke navnet på nytt i hele appen for å erstatte uttrykk. Definer disse formlene i egenskapen Formler :

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

Fordelene ved å bruke navngitte formler er følgende:

• Formelens verdi er alltid tilgjengelig. Det finnes ingen tidsberegningsavhengighet, ingen OnStart som må kjøre før verdien angis, og ikke noe tidspunkt da formelens verdi er feil. Navngitte formler kan referere til hverandre i en hvilken som helst rekkefølge så lenge de ikke oppretter en sirkelreferanse. De kan beregnes parallelt.
• Formelens verdi er alltid oppdatert. Formelen kan utføre en beregning som er avhengig av kontrollegenskapene eller databaseoppføringene, og etter hvert som de endres, oppdateres formelens verdi automatisk. Du trenger ikke oppdatere verdien manuelt slik du gjør med en variabel. Og formler beregnes bare på nytt ved behov.
• Definisjonen av formelen er uforanderlig. Definisjonen i Formler er den eneste sannhetskilden, og verdien kan ikke endres et annet sted i appen. Med variabler kan det hende at en kode uventet endrer en verdi, men denne vanskelige feilsøkingssituasjonen er ikke mulig med navngitte formler.
• Beregningen av formelen kan utsettes. Siden verdien er uforanderlig, kan den alltid beregnes ved behov, noe som betyr at den ikke må beregnes før det er nødvendig. Formelverdier som ikke brukes før screen2 i en app vises, behøver ikke beregnes før screen2 vises. Appen kan lastes inn raskere hvis du utsetter dette arbeidet. Navngitte formler er deklarative og gir systemet muligheter for å optimalisere hvordan og når de beregnes.
• Navngitte formler er et Excel-konsept. Power Fx bruker Excel-konsepter der det er mulig, siden mange folk kjenner Excel godt. Navngitte formler tilsvarer navngitte celler og navngitte formler i Excel, administrert med Navnebehandling. De beregnes automatisk på nytt som celler i et regneark og kontrollegenskaper.

Definer navngitte formler etter hverandre i egenskapen Formler , som hver slutter med et semikolon. Formeltypen utledes fra typene til elementene i formelen og hvordan de brukes sammen. Disse navngitte formlene henter for eksempel nyttig informasjon om gjeldende bruker fra 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' );

Hvis formelen for UserTitle må oppdateres, kan du enkelt oppdatere den på én plassering. Hvis UserPhone ikke er nødvendig i appen, blir ikke disse kallene til Brukere-tabellen i Dataverse utført. Det er ingen ulemper ved å inkludere en formeldefinisjon som ikke brukes.

Noen begrensninger for navngitte formler:

• De kan ikke bruke atferdsfunksjoner eller på andre måter forårsake sideeffekter i appen.
• De kan ikke opprette en sirkelreferanse. Det er ikke tillatt å ha a = b; og b = a; i samme app.

Brukerdefinerte funksjoner

Power Fx inneholder en lang liste med innebygde funksjoner, for eksempel Hvis, Tekst og Angi. Ved hjelp av brukerdefinerte funksjoner kan du skrive dine egne funksjoner som tar parametere og returnerer en verdi, akkurat som de innebygde funksjonene. Tenk på brukerdefinerte funksjoner som en utvidelse til navngitte formler som legger til parametere og støtter virkemåteformler.

Du kan for eksempel definere en navngitt formel som returnerer skjønnlitterære bøker fra et 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" );

Uten parametere må du definere separate navngitte formler for hver sjanger. Men i stedet kan du parametere den navngitte formelen:

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

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

Nå kan du ringe LibraryGenre( "Fiction" ), LibraryGenre( "Reference" )eller filtrere etter andre sjangere ved hjelp av en enkelt brukerdefinert funksjon.

Syntaksen er:

FunksjonNavn( [ ParameterNavn1: ParameterType1 [ , ParameterNavn2: ParameterType2 ... ] ] ) : ReturnType = Formula;

• FunctionName – obligatorisk. Navnet på den brukerdefinerte funksjonen.
• Parameternavn – Valgfritt. Navnet på en funksjonsparameter.
• ParameterType(s) – valgfritt. Navnet på en type, enten et innebygd datatypenavn, et datakildenavn eller en type som er definert ved hjelp av Type-funksjonen .
• ReturnType – obligatorisk. Typen til returverdien fra funksjonen.
• Formel – Obligatorisk. Formelen som beregner verdien av funksjonen basert på parametrene.

Du må skrive inn hver parameter og utdataene fra den brukerdefinerte funksjonen. I dette eksemplet definerer du den første parameteren til funksjonen som skal være av typen Tekst, SelectedGenre: Text og SelectedGenre er navnet på parameteren som brukes i brødteksten for filteroperasjonen. Se Datatyper for typenavnene som støttes. Type-funksjonen brukes til å opprette en mengdetype for biblioteket, slik at du kan returnere en tabell med bøker fra funksjonen.

Du definerer LibraryType som en flertallstabell med oppføringer. Hvis du vil sende én enkelt bok til en funksjon, kan du trekke ut posttypen for denne tabellen ved hjelp av RecordOf-funksjonen:

BookType := Type( RecordOf( LibraryType ) );

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

Oppføringssamsvar for funksjonsparametere er strengere enn i andre deler av Power Fx. Feltene i en postverdi må være et riktig delsett av typedefinisjonen og kan ikke inkludere ekstra felt. Resulterer for eksempel IsGenre( { Title: "My Book", Published: 2001 }, "Fiction" ) i en feil.

Rekursjon støttes ennå ikke av brukerdefinerte funksjoner.

Virkemåte: brukerdefinerte funksjoner

Navngitte formler og de fleste brukerdefinerte funksjoner støtter ikke virkemåtefunksjoner med bivirkninger, for eksempel Angi eller Varsle. Generelt sett bør du unngå å oppdatere tilstand hvis du kan. I stedet kan du stole på funksjonelle programmeringsmønstre og la Power Fx omberegne formler etter behov automatisk. Men det er tilfeller der det er uunngåelig. Hvis du vil inkludere virkemåtelogikk i en brukerdefinert funksjon, pakk brødteksten inn i klammeparenteser:

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

Nå kan du ringe Spend( 12 ) for å sjekke om du har 12 i sparepengene dine, og i så fall debitere den med 12 og legge til 12 i Brukt-variabelen. Returtypen for denne funksjonen er Ugyldig siden den ikke returnerer en verdi.

Syntaksen til en atferdsbrukerdefinert funksjon er:

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

• FunctionName – obligatorisk. Navnet på den brukerdefinerte funksjonen.
• Parameternavn – Valgfritt. Navnet på en funksjonsparameter.
• ParameterType(s) – valgfritt. Navnet på en type, enten et innebygd datatypenavn, et datakildenavn eller en type som er definert med Type-funksjonen.
• ReturnType – obligatorisk. Typen til returverdien fra funksjonen. Bruk Ugyldig hvis funksjonen ikke returnerer en verdi.
• Formler – Obligatorisk. Formelen som beregner verdien av funksjonen basert på parametrene.

Som med alle Power Fx-formler avsluttes ikke kjøringen når det oppstår en feil. Når feilfunksjonen kalles, forhindrer Hvis-funksjonen endringer i Besparelser og Brukt fra å skje. IfError-funksjonen kan også brukes til å forhindre videre kjøring etter en feil. Selv om den returnerer Ugyldig, kan formelen fremdeles returnere en feil hvis det er et problem.

Brukerdefinerte typer

Bruk navngitte formler med Type-funksjonen til å opprette brukerdefinerte typer. Bruk := i stedet for = for å definere en brukerdefinert type, for eksempel Book := Type( { Title: Text, Author: Text } ). Se Type-funksjonen for mer informasjon og flere eksempler.

OnError-egenskapen

Bruk OnError til å iverksette tiltak når det oppstår en feil hvor som helst i appen. Det gir en global mulighet til å fange opp et feilbanner før det vises for sluttbrukeren. Du kan også bruke den til å logge en feil ved hjelp av Trace-funksjonen eller skrive til en database eller nettjeneste.

I lerretsapper blir resultatet av hver formelevaluering kontrollert for feil. Hvis det oppstår en feil, evalueres OnError med de samme FirstError- og AllErrors-omfangsvariablene som appen bruker hvis hele formelen er pakket inn i en IfError-funksjon.

Hvis OnError er tom, viser et standard feilbanner FirstError.Message om feilen. Definering av en OnError-formel overstyrer denne virkemåten, slik at oppretteren kan håndtere feilrapportering etter behov. Du kan be om standard virkemåte i OnError ved å utføre feilen på nytt ved hjelp av feilfunksjonen. Bruk den nye tilnærmingen hvis du vil filtrere ut eller håndtere noen feil på en annen måte, men la andre gå gjennom.

OnError kan ikke erstatte en feil i beregninger slik IfError kan. Hvis OnError aktiveres, har feilen allerede skjedd og er allerede behandlet gjennom formelberegninger som IfError. OnError kontrollerer bare feilrapportering.

OnError-formler evalueres samtidig, og det er mulig at evalueringen kan overlappe med behandlingen av andre feil. Hvis du for eksempel angir en global variabel øverst i en OnError og leser den senere i samme formel, kan verdien ha blitt endret. Bruk With-funksjonen til å opprette en navngitt verdi som er lokal for formelen.

Selv om OnError behandler hver feil enkeltvis, kan det hende at standard feilbanneret ikke vises for hver enkelt feil. Hvis du vil unngå at for mange feilbannere vises samtidig, vises ikke det samme feilbanneret på nytt hvis det nylig ble vist.

Eksempel

La oss si at vi har en Label-kontroll og Slider-kontroll som er bundet sammen via følgende formel:

Label1.Text = 1/Slider1.Value

Standardverdien for glidebryteren er 50. Hvis du flytter glidebryteren til 0, viser Etikett1 ingen verdi, og det vises et feilbanner:

La oss se på hva som skjer i detalj:

1. Du flytter glidebryteren til venstre, og egenskapen Slider1.Value endres til 0.
2. Label1.Text oppdateres automatisk på nytt. Deling med null oppstår, noe som genererer en feil.
3. Det finnes ingen IfError i denne formelen. Feilen med deling på null returneres av formelevalueringen.
4. Label1.Text kan ikke vise noe for denne feilen, så den viser tom tilstand.
5. OnError aktiveres. Siden det ikke finnes noen behandler, vises standard feilbanner med feilinformasjon.

Hvis det er nødvendig, kan du også endre formelen til Label1.Text = IfError( 1/Slider1.Value, 0 ). Hvis du bruker IfError , er det ingen feil eller feilbanner. Du kan ikke endre verdien for en feil fra OnError fordi feilen allerede har oppstått . OnError kontrollerer bare hvordan den rapporteres.

Hvis du legger til en OnError-behandling , påvirker det ikke trinnene før trinn 5, men det endrer hvordan feilen rapporteres:

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

Med denne OnError-behandling ser ikke appbrukeren noen feil. Men feilen legges til i monitorens sporing, inkludert kilden til feilinformasjonen fra FirstError:

Hvis du også vil vise standard feilbanner sammen med sporingen, kan du sette inn feilen på nytt ved hjelp av feilfunksjonen etter sporingskallet , som om sporingen ikke var der:

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

OnStart-egenskapen

OnStart-egenskapen kjører når brukeren starter appen. Bruk denne egenskapen til å:

• Hent og bufre data i samlinger ved hjelp av Collect-funksjonen .
• Konfigurere globale variabler ved hjelp av Set-funksjonen.

Denne formelen kjøres før den første skjermen vises. Ingen skjerm lastes inn, så du kan ikke angi kontekstvariabler med UpdateContext-funksjonen. Du kan imidlertid sende kontekstvariabler med Navigate-funksjonen .

Når du har endret OnStart-egenskapen , tester du den ved å holde pekeren over App-objektet i trevisningsruten , velge ellipsen (...) og deretter velge Kjør OnStart. I motsetning til når appen lastes inn for første gang, er eksisterende samlinger og variabler allerede angitt. Hvis du vil starte med tomme samlinger, bruker du ClearCollect-funksjonen i stedet for Collect-funksjonen.

StartScreen-egenskap

StartScreen-egenskapen angir hvilken skjerm som vises først. Power Apps evaluerer denne egenskapen én gang når appen lastes inn og returnerer skjermobjektet som skal vises. Som standard er denne egenskapen tom, og den første skjermen i Studio Tree-visningen vises først.

StartScreen er en dataflytegenskap som ikke kan inneholde funksjonalitetsfunksjoner. Alle dataflytfunksjoner er tilgjengelige. Bruk disse funksjonene og signalene til å bestemme hvilken skjerm som skal vises først:

• Param-funksjon for å lese parametere som brukes til å starte appen.
• User-funksjonen for å lese informasjon om gjeldende bruker.
• LookUp, Filter, CountRows, Max og andre funksjoner som leser fra en datakilde.
• API-en ringer gjennom en kobling. Kontroller at samtalen kommer raskt tilbake.
• Signaler som Connection, Compass og App.

Hvis StartScreen returnerer en feil, vises den første skjermen i Studio Tree-visningen som om StartScreen ikke er angitt. Bruk IfError-funksjonen til å fange opp eventuelle feil og omdirigere til en feilskjerm.

Når du har endret StartScreen i Studio, kan du teste det ved å holde pekeren over App-objektet i trevisningsruten , velge ellipsen (...), og deretter velge Naviger til StartScreen. Skjermen endres som om appen nettopp ble lastet inn.

Eksempler

Screen9

Screen9 viser først når appen starter.

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

Kontrollerer om Param -administratormodus er angitt og bruker den til å avgjøre om HomeScreen eller AdminScreen vises først.

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

Kontrollerer om en deltaker er en ansatt og dirigerer dem til riktig skjerm ved oppstart.

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

Henviser appen basert på et API-kall til ForestScreen eller OceanScreen. Hvis API-en mislykkes, bruker ErrorScreen appen i stedet.

Egenskapen StudioVersion

Bruk StudioVersion-egenskapen til å vise eller logge versjonen av Power Apps Studio som brukes til å publisere en app. Denne egenskapen hjelper når du feilsøker og kontrollerer at appen publiseres på nytt med en nylig versjon av Power Apps Studio.

StudioVersion returnerer tekst. Formatet på denne teksten kan endres over tid, så behandle den som en helhet og ikke trekke ut enkeltdeler.