Implementert i versjon 8.3.5.1383, 8.3.6.1977.

Moderne tendenser

Nettleserutviklingstrender fører til en stadig økende prosentandel av "asynkroni" i plattformen. Det første steget var. Det er nå asynkrone samtaler for arbeid med kryptografi-utvidelser, arbeid med filer og eksterne komponenter.

Årsaken til det neste steget mot asynkroni var at utviklerne av Google Chrome-nettleseren forlot støtten for den tidligere NPAPI-teknologien (Netscape Plugin Application Programming Interface). Denne teknologien ble brukt til å koble eksterne moduler – utvidelser – til nettleseren.

1C:Enterprise bruker slike utvidelser for å jobbe med kryptografi, for å jobbe med filer og for å koble til eksterne komponenter. Dette er en ganske viktig funksjonalitet. Kryptografi brukes i elektronisk dokumenthåndtering, og takket være eksterne komponenter kan applikasjoner fungere med strekkodeskannere og annet detaljhandelsutstyr.

Og nå, i stedet for den tidligere synkrone NPAPI-teknologien, har Google Chrome-utviklere laget en ny Native Messaging-teknologi. Samtidig anbefalte de på det sterkeste at alle utvidelsesutviklere ikke bruker den gamle teknologien, fordi den ikke vil bli støttet.

Uten å gå i detaljer er den nye teknologien bedre og sikrere. Dette er bra. Men en av de betydelige forskjellene er at den utelukkende gir asynkron interaksjon med nettleserutvidelser. Og dette krever en radikal endring i alle eksisterende metoder for å jobbe med utvidelser og eksterne komponenter i 1C:Enterprise. For de er alle basert på synkron interaksjon.

Asynkrone metoder

Vi løste dette problemet på samme måte som vi løste det modale anropsproblemet. For alle synkrone metoder som bruker NPAPI-teknologi, har vi laget deres asynkrone motstykker. De er hovedsakelig forskjellige i nærvær av prefikset Begynne og det faktum at den første parameteren sendes til dem Beskrivelse Varsler, hvorfra kjøringen av programkoden vil fortsette etter fullføringen av den kalte handlingen.

For eksempel i stedet for metoden Krypter() Vi anbefaler nå å bruke metoden StartEncrypt():

CryptographyManager.Encrypt(<ИсходныеДанные>, <Получатели>) Cryptography Manager.Start Encryption(<ОписаниеОповещения>, <ИсходныеДанные>, <Получатели>)

I stedet for en metode GetFiles() - StartGettingFiles():

GetFiles(<ПолучаемыеФайлы>, <ПолученныеФайлы>, <РасположениеФайлов>, <Интерактивно>) Begynn å motta filer ((<ОписаниеОповещения>, <ПолучаемыеФайлы>, <РасположениеФайлов>, <Интерактивно>)

I stedet for SetExternalComponent()- StartInstallingExternalComponents():

SetExternalComponent(<Местоположение>) Begynn å installere eksterne komponenter (<ОписаниеОповещенияОЗавершении>, <Местоположение>)

Faktisk er alt i det store og hele veldig likt det vi gjorde før da vi kvittet oss med modalitet. Men funksjonen til nye asynkrone metoder har en vesentlig funksjon som metoder som forårsaker ikke-modale dialoger ikke har.

Når vi kaller en modellløs dialog asynkront, forventer vi bare noen brukerreaksjoner, og ingenting mer. I den forstand at ingenting uventet kan skje.

Og i prosessen med å kalle asynkrone metoder for å jobbe med utvidelser og komponenter, kan det oppstå eksepsjonelle situasjoner. Utvidelsen ble ikke installert, komponenten lastet ikke, osv.

Du oppgir vanligvis håndtering av slike unntak i søknadskoden din. Bruke en operatør Prøver... Unntak. Men nå blir dette umulig, fordi på tidspunktet for det asynkrone anropet blir ikke applikasjonskoden utført. Følgelig fungerer ikke operatøren Prøver... Unntak.

• NameProcedureProcessingErrors;
• ErrorProcessingModule.

Hvis noe går galt under et asynkront anrop og det oppstår et unntak, vil prosedyren som disse egenskapene peker på, bli utført. Det er fornuftig å bruke disse to egenskapene bare i asynkrone metoder for å jobbe med utvidelser. Når du kaller opp modellløse dialoger, trenger du ikke disse egenskapene.

Konfigurasjonsegenskap

Som i tilfelle av avvisning av modalitet, må hele søknadsløsningen som helhet vite "hva det er." Enten er det modalt eller ikke-modalt. Enten er den synkron eller asynkron.

Tidligere, for å løse problemet med modalitet, la vi til en spesiell konfigurasjonsegenskap Måte å bruke modalitet på. Nå, for å løse problemet med synkronisitet, har vi lagt til en egenskap som ligner på den Modus for å bruke synkrone anrop til internnummer og eksterne komponenter.

Essensen av bruken er som følger:

• Ikke bruk- dette er en ny, asynkron driftsmåte. For nye konfigurasjoner er dette standardmodusen. Bruk av gamle, synkrone metoder er forbudt. De passerer ikke syntaktisk kontroll, de er ikke i konteksten ledetråd. Å prøve å utføre en synkron metode gir et unntak.
• Bruk med advarsel- denne modusen er beregnet på utvikleren. Det forhindrer ikke bruk av eldre, synkrone metoder. Men hver gang en synkron metode kalles på klienten, produserer den en advarselsmelding. Vi anbefaler å bruke denne modusen i "resirkulering"-konfigurasjoner. Det er praktisk for visuelt å søke etter synkrone anrop og overvåke dem under revisjonsprosessen.
• Bruk- en modus som sikrer kompatibilitet av den nye versjonen av plattformen med gamle konfigurasjoner som bruker synkrone metoder for å jobbe med utvidelser og eksterne komponenter.

Alle metodene og egenskapene som vi har snakket om så langt er implementert i versjonen 8.3.5.1383 . Du kan bruke dem i applikasjonsløsningene dine. Og utviklere vil for eksempel bytte til asynkrone driftsundersystemer som bruker kryptografiverktøy, jobber med filer og eksterne komponenter.

Naturligvis, som med modale samtaler, har du sannsynligvis et spørsmål. Må jeg gjøre om applikasjonsløsningen min? Og generelt, trenger jeg å bruke disse asynkrone metodene i min nye applikasjonsløsning?

Når trengs det?

Svaret på dette spørsmålet er i hovedsak det samme som vi ga tidligere. Da de snakket om å forlate modalitet.

For det første støtter ikke alle versjoner av teknologiplattformen modusen for asynkrone anrop til utvidelser og eksterne komponenter. Denne driftsmodusen eksisterer fra og med versjon 8.3.5.1383. Derfor, hvis du jobber med lavere versjoner av plattformen, trenger du ikke å bekymre deg for å forlate synkrone metoder for nå.

For det andre må ikke alle applikasjonsløsninger nødvendigvis bruke denne modusen. Kritiske applikasjoner er de som skal jobbes med ved bruk av nettklienten i Google Chrome-nettleseren. Slike applikasjoner er i stor grad applikasjoner som kjører . Hvis applikasjonsløsningen din definitivt ikke vil bli brukt i denne modusen, kan du ikke forlate synkrone metoder for nå.

Til tross for det første og andre punktet, er det imidlertid globale trender som kan påvirke planene dine. Vi, 1C-selskapet, utvikler alle standardløsninger basert på at de kan brukes på alle tilgjengelige måter. Derfor vil vi implementere nye applikasjonsløsninger, samt alle bibliotekene som brukes i dem, i en modus uten bruk av synkrone anrop.

Dette betyr at det er bedre for deg å begynne å mestre denne driftsmodusen nå. Selv om applikasjonen din kanskje ikke bruker den ennå, anbefaler vi å starte oversettelsen nå hvis mulig. Vi oppfordrer deg imidlertid til å tilnærme deg denne prosessen kreativt. På samme måte som når man forlater modalitet. Det vil si at det ikke er nødvendig å mekanisk erstatte synkrone metoder med asynkrone. For det første er det nyttig å tenke på om det er mulig å endre algoritmen eller skriptet slik at vi på dette stedet helt forlater bruken av synkrone metoder?

Refaktorering

På den ene siden, hvis konfigurasjonen er stor og det er mange synkrone anrop i den, kan "manuell" omarbeiding av en slik konfigurasjon være en veldig tidkrevende oppgave.

På den annen side, fra og med versjon 8.3.5.1068, har plattformen funksjoner som lar deg konvertere synkrone anrop til deres asynkrone motparter.

Derfor tok vi disse allerede eksisterende verktøyene, utvidet dem og reorienterte dem fra å "bevege seg bort fra modalitet" til "overgang til asynkroni." I kjernen er overgangen til asynkrone metoder lik handlingene som utføres når du forlater modaliteten. Gamle, "umoderne", synkrone (modale) samtaler må erstattes med nye, "moteriktige", asynkrone samtaler ved hjelp av Behandler varsler.

I dette oppdaterte skjemaet har refactoring-verktøy blitt tilgjengelig for deg i versjonen 8.3.6.1977 .

Siden "vekten" av disse verktøyene har skiftet mot asynkroni, har vi gitt nytt navn til noen kommandoer. I stedet for "ikke-modal", brukes nå uttrykket "avviklet synkron":

I tillegg har vi lagt til en ny fane i konfiguratorinnstillingene Refaktorering. Som standard er begge transformasjonene aktivert. Men hvis du trenger det, kan du med dens hjelp utføre bare en av typene transformasjoner under automatisk refactoring.

05.12.2014

Implementert i versjon 8.3.5.1383, 8.3.6.1977.

Moderne tendenser

Nettleserutviklingstrender fører til en stadig økende prosentandel av "asynkroni" i plattformen. Det første trinnet var å forlate modaliteten. Det er nå asynkrone samtaler for arbeid med kryptografi-utvidelser, arbeid med filer og eksterne komponenter.

Årsaken til det neste steget mot asynkroni var at utviklerne av Google Chrome-nettleseren forlot støtten for den tidligere NPAPI-teknologien (Netscape Plugin Application Programming Interface). Denne teknologien ble brukt til å koble eksterne moduler – utvidelser – til nettleseren.

1C:Enterprise bruker slike utvidelser for å jobbe med kryptografi, for å jobbe med filer og for å koble til eksterne komponenter. Dette er en ganske viktig funksjonalitet. Kryptografi brukes i elektronisk dokumenthåndtering, og takket være eksterne komponenter kan applikasjoner fungere med strekkodeskannere og annet detaljhandelsutstyr.

Og nå, i stedet for den tidligere synkrone NPAPI-teknologien, har Google Chrome-utviklere laget en ny Native Messaging-teknologi. Samtidig anbefalte de på det sterkeste at alle utvidelsesutviklere ikke bruker den gamle teknologien, fordi den ikke vil bli støttet.

Uten å gå i detaljer er den nye teknologien bedre og sikrere. Dette er bra. Men en av de betydelige forskjellene er at den utelukkende gir asynkron interaksjon med nettleserutvidelser. Og dette krever en radikal endring i alle eksisterende metoder for å jobbe med utvidelser og eksterne komponenter i 1C:Enterprise. For de er alle basert på synkron interaksjon.

Asynkrone metoder

Vi løste dette problemet på samme måte som det modale anropsproblemet. For alle synkrone metoder som bruker NPAPI-teknologi, har vi laget deres asynkrone motstykker. De er hovedsakelig forskjellige i nærværet av Start-prefikset og i det faktum at den første parameteren er Alert Description, hvorfra utførelsen av programkoden vil fortsette etter fullføringen av den kalte handlingen.

For eksempel, i stedet for Encrypt()-metoden, anbefaler vi nå å bruke StartEncrypt()-metoden:

CryptographyManager.Encrypt(<ИсходныеДанные>, <Получатели>) Cryptography Manager.Start Encryption(<ОписаниеОповещения>, <ИсходныеДанные>, <Получатели>)

I stedet for GetFiles()-metoden - StartGettingFiles():

GetFiles(<ПолучаемыеФайлы>, <ПолученныеФайлы>, <РасположениеФайлов>, <Интерактивно>) Begynn å motta filer ((<ОписаниеОповещения>, <ПолучаемыеФайлы>, <РасположениеФайлов>, <Интерактивно>)

I stedet for InstallExternalComponent() - StartInstallingExternalComponent():

SetExternalComponent(<Местоположение>) Begynn å installere eksterne komponenter (<ОписаниеОповещенияОЗавершении>, <Местоположение>)

Faktisk er alt i det store og hele veldig likt det vi gjorde før da vi kvittet oss med modalitet. Men funksjonen til nye asynkrone metoder har en vesentlig funksjon som metoder som forårsaker ikke-modale dialoger ikke har.

Når vi kaller en modellløs dialog asynkront, forventer vi bare noen brukerreaksjoner, og ingenting mer. I den forstand at ingenting uventet kan skje.

Og i prosessen med å kalle asynkrone metoder for å jobbe med utvidelser og komponenter, kan det oppstå eksepsjonelle situasjoner. Utvidelsen ble ikke installert, komponenten lastet ikke, osv.

Du sørger vanligvis for håndtering av slike unntak i søknadskoden. Bruke operatøren Try... Unntak. Men nå blir dette umulig, fordi på tidspunktet for det asynkrone anropet blir ikke applikasjonskoden utført. Følgelig virker ikke operatøren Forsøk... Unntak.

• ErrorProcedureName;
• Feilhåndteringsmodul.

Hvis noe går galt under et asynkront anrop og det oppstår et unntak, vil prosedyren som disse egenskapene peker på, bli utført. Det er fornuftig å bruke disse to egenskapene bare i asynkrone metoder for å jobbe med utvidelser. Når du kaller opp modellløse dialoger, trenger du ikke disse egenskapene.

Konfigurasjonsegenskap

Som i tilfelle av avvisning av modalitet, må hele søknadsløsningen som helhet vite "hva det er." Enten er det modalt eller ikke-modalt. Enten er den synkron eller asynkron.

Tidligere, for å løse problemet med modalitet, la vi til en spesiell egenskap til konfigurasjonen: Modus for bruk av modalitet. Nå, for å løse problemet med synkronisering, har vi lagt til en egenskap som ligner på den: Modus for bruk av synkrone anrop av utvidelser og eksterne komponenter.

Essensen av bruken er som følger:

• Ikke bruk er en ny, asynkron driftsmåte. For nye konfigurasjoner er dette standardmodusen. Bruk av gamle, synkrone metoder er forbudt. De passerer ikke syntaktisk kontroll, de er ikke i konteksten ledetråd. Å prøve å utføre en synkron metode gir et unntak.
• Bruk med advarsel - denne modusen er beregnet på utvikleren. Det forhindrer ikke bruk av eldre, synkrone metoder. Men hver gang en synkron metode kalles på klienten, produserer den en advarselsmelding. Vi anbefaler å bruke denne modusen i "resirkulering"-konfigurasjoner. Det er praktisk for visuelt å søke etter synkrone anrop og overvåke dem under revisjonsprosessen.
• Bruk - en modus som sikrer kompatibilitet av den nye versjonen av plattformen med gamle konfigurasjoner som bruker synkrone metoder for å jobbe med utvidelser og eksterne komponenter.

Alle metodene og egenskapene vi har snakket om så langt er implementert i versjon 8.3.5.1383. Du kan bruke dem i applikasjonsløsningene dine. Og BSP-utviklere vil for eksempel overføre delsystemer som bruker kryptografiverktøy, jobber med filer og eksterne komponenter til asynkron drift.

Naturligvis, som med modale samtaler, har du sannsynligvis et spørsmål. Må jeg gjøre om applikasjonsløsningen min? Og generelt, trenger jeg å bruke disse asynkrone metodene i min nye applikasjonsløsning?

Når trengs det?

Svaret på dette spørsmålet er i hovedsak det samme som vi ga tidligere. Da de snakket om å forlate modalitet.

For det første støtter ikke alle versjoner av teknologiplattformen modusen for asynkrone anrop til utvidelser og eksterne komponenter. Denne driftsmodusen eksisterer fra og med versjon 8.3.5.1383. Derfor, hvis du jobber med lavere versjoner av plattformen, trenger du ikke å bekymre deg for å forlate synkrone metoder for nå.

For det andre må ikke alle applikasjonsløsninger nødvendigvis bruke denne modusen. Kritiske applikasjoner er de som skal jobbes med ved bruk av nettklienten i Google Chrome-nettleseren. Slike applikasjoner er i stor grad applikasjoner som opererer i tjenestemodellen. Hvis applikasjonsløsningen din definitivt ikke vil bli brukt i denne modusen, kan du ikke forlate synkrone metoder for nå.

Til tross for det første og andre punktet, er det imidlertid globale trender som kan påvirke planene dine. Vi, 1C-selskapet, utvikler alle standardløsninger basert på at de kan brukes på alle tilgjengelige måter. Derfor vil vi implementere nye applikasjonsløsninger, samt alle bibliotekene som brukes i dem, i en modus uten bruk av synkrone anrop.

Dette betyr at det er bedre for deg å begynne å mestre denne driftsmodusen nå. Selv om applikasjonen din kanskje ikke bruker den ennå, anbefaler vi å starte oversettelsen nå hvis mulig. Vi oppfordrer deg imidlertid til å tilnærme deg denne prosessen kreativt. På samme måte som når man forlater modalitet. Det vil si at det ikke er nødvendig å mekanisk erstatte synkrone metoder med asynkrone. For det første er det nyttig å tenke på om det er mulig å endre algoritmen eller skriptet slik at vi på dette stedet helt forlater bruken av synkrone metoder?

Refaktorering

På den ene siden, hvis konfigurasjonen er stor og det er mange synkrone anrop i den, kan "manuell" omarbeiding av en slik konfigurasjon være en veldig tidkrevende oppgave.

På den annen side, fra og med versjon 8.3.5.1068, har plattformen verktøy som lar deg konvertere synkrone anrop til deres asynkrone motparter.

Derfor tok vi disse allerede eksisterende verktøyene, utvidet dem og reorienterte dem fra å "bevege seg bort fra modalitet" til "overgang til asynkroni." I kjernen er overgangen til asynkrone metoder lik handlingene som utføres når du forlater modaliteten. Gamle, "umoderne", synkrone (modale) anrop må erstattes med nye, "moteriktige", asynkrone anrop som bruker varslingsbehandling.

I dette oppdaterte skjemaet ble refactoring-verktøyene tilgjengelige for deg i versjon 8.3.6.1977.

Siden "vekten" av disse verktøyene har skiftet mot asynkroni, har vi gitt nytt navn til noen kommandoer. I stedet for "ikke-modal", brukes nå uttrykket "avviklet synkron":

I tillegg har vi lagt til en ny Refactoring-fane i konfiguratorinnstillingene. Som standard er begge transformasjonene aktivert. Men hvis du trenger det, kan du med dens hjelp utføre bare en av typene transformasjoner under automatisk refactoring:

Artikkelen vil diskutere hovedårsakene til å forlate modaliteten i 1C:Enterprise-plattformen og hovedmetodene for å konvertere kodeseksjoner til en ny asynkron modell.

Anvendbarhet

Artikkelen diskuterer den asynkrone modellen for å bygge forretningslogikk, den ekstra plattformen "1C:Enterprise" utgave 8.3. Informasjonen som presenteres er relevant for gjeldende plattformutgivelser.

Nektelse av å bruke modale vinduer i 1C:Enterprise 8.3-plattformen

Når du utvikler en konfigurasjon på 1C:Enterprise 8-plattformen, oppstår det med jevne mellomrom behov for å pause programmet til brukeren tar en avgjørelse eller utfører en handling.

For eksempel, når du klikker på knappen fyll tabellseksjon, bør brukeren bli spurt om tabellseksjonen må slettes slik at tidligere innlagte data ikke går tapt.

For eksempel kan følgende kode gi denne virkemåten:

&OnClient
Fremgangsmåte Fyll inn produkter(laget)
Svar = Spørsmål ("Borddelen vil bli slettet. Fortsett?", DialogmodusSpørsmål.JaNei);
Hvis svar = Dialog Returkode.Ja Deretter
//fyllingsalgoritme
Slutt om ;
Slutt på prosedyre

Som et resultat av dette kodefragmentet vil kjøringen av programkoden bli suspendert, et spørsmål vil vises på skjermen, applikasjonsgrensesnittet med unntak av dialogen med spørsmålet vil bli utilgjengelig, systemet venter på at brukeren skal lage en beslutning, og utførelse av kode vil fortsette først etter at spørsmålet er besvart.

Å åpne modale vinduer ved å kalle OpenModal()-metoden forårsaker også pauser i kodekjøring og blokkering av grensesnittet.

Når du arbeider med konfigurasjonen i nettklientmodus gjennom en nettleser, åpnes i dette tilfellet et nytt vindu - et popup-vindu som blokkerer ikke bare gjeldende fane, men også hele nettlesergrensesnittet, inkludert andre åpne vinduer og faner.

Popup-vinduer på Internett brukes ofte til å distribuere uønsket reklame, og det er grunnen til at nettlesere inneholder funksjoner for blokkering av popup-vinduer.

I dette tilfellet, for å jobbe med 1C:Enterprise 8-konfigurasjoner gjennom en nettleser, må du deaktivere popup-blokkering.

Det oppstår også problemer ved arbeid på mobile enheter. Modale vinduer støttes for eksempel ikke på iPad.

For å løse disse problemene bør du bruke blokkeringsvinduer i stedet for modale. For brukeren ser alt visuelt likt ut: vinduet blokkerer webklientgrensesnittet.

Imidlertid er blokkeringsvinduet "tegnet" på toppen av hovedvinduet, og bare den gjeldende nettleserfanen der konfigurasjonen er åpen er blokkert, slik at du kan bytte til andre faner, siden modale nettleservinduer ikke brukes.

Dermed åpnes ikke popup-vinduer i nettleseren og fungerer gjennom nettklienten på mobile enheter er sikret.

Rotelementet til konfigurasjonen har en egenskap "Modalitetsmodus", som bestemmer om modale vinduer kan åpnes i konfigurasjonen.

Hvis alternativet "Bruk" er valgt, kan modale vinduer åpnes. Hvis alternativet "Ikke bruk" er valgt, er ikke modale vinduer tillatt. Når du prøver å kalle en metode som åpner et modalt vindu, viser systemet en feilmelding:

Med denne verdien av «Modalitetsbruksmodus»-egenskapen er det kun tillatt å blokkere vinduer.

Hvis alternativet "Bruk med advarsler" er valgt, vises følgende tekst i meldingsvinduet når modale vinduer åpnes:

Dette arbeidsalternativet kan brukes som et mellomliggende ved omarbeiding av konfigurasjonen for å forlate bruken av modale vinduer.

Hovedforskjellen mellom blokkeringsvinduer og modale vinduer er at åpning av et blokkeringsvindu ikke stopper kjøring av kode.

Derfor vil utviklere måtte skrive om programkoden som bruker modale vinduer for å ta hensyn til denne funksjonen.

Koden må deles inn i to deler:

• åpne et blokkerende vindu;
• behandle brukervalg.

Kodefragmentet gitt i begynnelsen av artikkelen må skrives om som følger:

&OnClient
Fremgangsmåte Fyll inn produkter(laget)
Alert = Ny Beskrivelse Varsler(, ThisObject );

DialogmodusSpørsmål.JaNei);
Slutt på prosedyre
&OnClient
Prosedyre (Resultat, Ekstra alternativer) Eksporter
Hvis Resultat = Dialog Returkode.Ja Deretter
//fyllingsalgoritme
Slutt om ;
Slutt på prosedyre

Etter å ha utført ShowQuestion()-prosedyren, stopper ikke systemet, mens du venter på brukerens svar, fortsetter kjøringen av kode.

Brukeren vil kun kunne gjøre et valg etter at hele prosedyren er fullført. I dette tilfellet vil eksportprosedyren FillItemsQuestionComplete() bli kalt. Vi ga navnet til konstruktøren av DescriptionAlerts-objektet.

Prosedyren som vil bli kalt etter å ha gjort et valg kan være plassert i en skjemamodul, en kommandomodul eller en generell ikke-global modul.

I det betraktede eksemplet er den kalte prosedyren plassert i en administrert skjemamodul, så vi sendte inn ThisObject-parameteren.

La oss vurdere å kalle en prosedyre som ligger i en felles modul. For å gjøre dette, legg til en ny felles modul Varslingsbehandling, sett "Client (administrert applikasjon)"-flagget for det, og ikke sett "Global"-flagget. La oss plassere prosedyren Fyll inn produktspørsmål () i denne modulen.

Deretter vil kommandobehandleren for fyll se slik ut:

&OnClient
Fremgangsmåte Fyll inn produkter(laget)
Alert = Ny Beskrivelse Varsler("Fyll inn produktspørsmål",
Behandler varsler);
Spørsmålstekst = "Borddelen vil bli tømt. Fortsette?" ;
ShowQuestion (Alert , Question Text , DialogmodusSpørsmål.JaNei);
Slutt på prosedyre

Etter å ha kalt en metode som åpner et blokkeringsvindu, må prosedyren avsluttes, og koden som kjører neste skal plasseres i en prosedyre som vil bli kalt etter at vinduet er lukket.

For å overføre kontekst (hjelpedata, visse parametere, variabelverdier) fra prosedyren som åpner det modale vinduet til prosedyren som kalles når det er lukket, er det gitt en tredje valgfri parameter for objektkonstruktøren: DescriptionAlerts – Additional Parameters.

Dette objektet (av hvilken som helst type) vil bli sendt til prosedyren beskrevet i Alert Description som siste parameter.

Ved å bruke eksempelet på kodedelen diskutert ovenfor, kan dette gjøres slik:

&OnClient
Fremgangsmåte Fyll inn produkter(laget)
Parameter1 = 0 ;
Parameter2 = 0 ;
Liste over parametere= Ny struktur (“Parameter1, Parameter2″, Parameter1, Parameter2);
Alert = Ny Beskrivelse Varsler("Fyll inn produktspørsmål", Dette objektet ,
Liste over parametere);
ShowQuestion (varsel, "Borddelen vil bli tømt. Fortsett?",
DialogmodusSpørsmål.JaNei);
Slutt på prosedyre
&OnClient
Fremgangsmåte Fyll inn ProductsQuestionCompletion(Resultat , Ekstra alternativer) Eksporter
Hvis Resultat = Dialog Returkode.Ja Deretter
//analysere tilleggsparametere.Parameter1
//analysere tilleggsparametere.Parameter2
Slutt om ;
Slutt på prosedyre

Hvis du trenger å sende bare én verdi, kan du ikke bruke strukturen, men tilordne denne verdien til parameteren Tilleggsparametere til konstruktøren av DescriptionAlerts-objektet.

La oss se på noen eksempler på arbeid med blokkering av vinduer.

Oppgave 1: Åpne et annet skjema

Fra dokumentskjemaet, ved å klikke på "Åpne parametere"-knappen, må du åpne et skjema der det er to avmerkingsbokser Parameter1 og Parameter2, som brukeren må angi. Etter å ha lukket skjemaet, vis parameterverdiene i meldingslinjen.

Vi lager et generelt skjema "ParametersForm", der vi plasserer detaljene Parameter1 og Parameter2, samt CloseForm-kommandoen:

Kommandobehandleren ser slik ut:

Kommandobehandleren ser slik ut: &OnClient
Prosedyre CloseForm (Kommando)
Liste over parametere= Ny struktur ( "Parameter1, Parameter2", Parameter1 , Parameter2 );
Lukk ( Liste over parametere); Slutt på prosedyre

For skjemaet, sett WindowOpenMode-egenskapen til "Blokker hele grensesnittet":

På dokumentskjemaet plasserer vi OpenParameters-kommandoen, hvis behandler er beskrevet som følger:

&OnClient
Fremgangsmåte Åpne Alternativer(laget)
Alert = Ny Beskrivelse Varsler("Åpne alternativer fullfør", ThisObject );
OpenForm ( "GeneralForm.FormParameters", , , , , , Varsling);
Slutt på prosedyre
&OnClient
Fremgangsmåte OpenOptionsComplete(Resultat , Ekstra alternativer) Eksporter
Hvis TypeValue (Result) = Type (“Structure”) Da
For hver nøkkelverdi fra resultatløkke
Melding = Ny Melding til bruker;
Message.Text = "Nøkkel: "" ” + KeyValue.Key + “””, verdi = ”
+ KeyValue.Value;
Melding.Rapport();
EndCycle ;
Slutt om ;
Slutt på prosedyre

I brukermodus, kjører konfigurasjonen under webklienten, får vi følgende resultater:

For å forstørre, klikk på bildet.

Vindusåpningsmodusen kan også spesifiseres i den siste parameteren i OpenForm-prosedyren.

&OnClient
Fremgangsmåte Åpne Alternativer(laget)
Alert = Ny Beskrivelse Varsler("Åpne alternativer fullfør", ThisObject );
OpenForm ( "GeneralForm.FormParameters", , , , , , Varsling
FormWindowOpenMode.LockEntireInterface);
Slutt på prosedyre

Oppgave 2. Spørsmål ved lukking av skjema

Når du lukker et behandlingsvindu, spør brukeren om han virkelig vil lukke vinduet.

Dette problemet kan løses ved å bruke følgende kode i behandlingsskjemamodulen:

&OnClient
Perem Må lukke skjemaet;
&OnClient
Prosedyre før lukking (feil, Standardbehandling)
Hvis ikke Må lukke skjemaet= Sant Da
Avslå = Sant ;
Alert = Ny Beskrivelse Varsler("Før avslutningsavslutning", ThisObject );
ShowQuestion (varsel, "Er du sikker på at du vil lukke vinduet?",
DialogmodusSpørsmål.JaNei);
Slutt om ;
Slutt på prosedyre
&OnClient
Fremgangsmåte Før lukking av ferdigstillelse(Resultat , Ekstra alternativer) Eksporter
Hvis Resultat = Dialog Returkode.Ja Deretter
Må lukke skjemaet= Sant ;
Lukk();
Ellers
Må lukke skjemaet= Udefinert ;
Slutt om ;
Slutt på prosedyre

I BeforeClosing-skjemaprosedyren blir brukeren stilt et spørsmål, Refusal-flagget settes til True, og lukkingen av skjemaet avbrytes.

Etter et bekreftende svar på spørsmålet settes variabelen Need toCloseForm til True, og skjemaet lukkes igjen.

Oppgave 3: Angi en numerisk verdi

Når du klikker på knappen på behandlingsskjemaet, åpner du en standard dialogboks for inntasting av tall.

For å gjøre dette, må du bruke metoden ShowNumberInput() i stedet for EnterNumber(), som åpner et blokkeringsvindu i stedet for et modalt.

&OnClient
Prosedyre for å legge inn tall (kommando)
Alert = Ny Beskrivelse Varsler("EnterNumberComplete", ThisObject );
ShowEnterNumbers(Varsel, 0, "Skriv inn mengde", 15, 3);
Slutt på prosedyre
&OnClient
Fremgangsmåte Skriver inn tall Fullfører(Resultat , Ekstra alternativer) Eksporter

Melding = Ny Melding til bruker;
Message.Text = "Du har lagt inn et antall" + Resultat;
Melding.Rapport();
Slutt om ;
Slutt på prosedyre

Etter å ha lukket nummerinntastingsvinduet, vil en prosedyre kalles, hvor den første parameteren vil være det angitte nummeret eller den udefinerte verdien hvis brukeren nektet å gå inn.

Oppgave 4. Velge en farge

Når du klikker på knappen på behandlingsskjemaet, ved å bruke standard fargevalgsdialog, spesifiserer brukeren ønsket farge. Angi denne fargen for bakgrunnen til den klikkede knappen.

Legg til SelectColor-kommandoen i skjemaet med følgende behandler:

&OnClient
Prosedyre fargevalg (kommando)
Dialog for fargevalg= Ny Dialog for fargevalg;
Alert = Ny Beskrivelse Varsler("Fargevalg fullført", ThisObject );
Dialog for fargevalg. Vis(Alert);
Slutt på prosedyre
&OnClient
Fremgangsmåte ChoiceColorsCompletion(Resultat , Ekstra alternativer) Eksporter
Hvis IKKE resultat = Udefinert da
Elementer.Fargevalg.Bakgrunnsfarge= Resultat ;
Slutt om ;
Slutt på prosedyre

For fargevalgsdialogobjekter (så vel som standard perioderedigeringsdialog, formatlinjekonstruktør, vanlig oppgaveplandialog, dialogboks for skriftvalg), åpner Vis()-metoden et blokkeringsvindu.

Etter å ha lukket vinduet, vil en prosedyre bli kalt, den første parameteren som vil bli sendt til den valgte verdien (farge, skrift, etc.) eller den udefinerte verdien hvis brukeren har nektet valget.

Det skal bemerkes at FileSelectionDialog-objektet ikke har en Show()-metode, i motsetning til farge- eller fontvalgdialoger, siden implementeringen av disse dialogene er vesentlig forskjellig.

For å bruke filvalgsdialogen på nettklienten må du først aktivere filtypen.

Dialogbokser implementert gjennom filtypen skaper ikke de samme driftsproblemene som modale nettleservinduer, så åpning av blokkeringsvinduer for FileSelectionDialog-objektet ble ikke implementert.

Avslutningsvis merker vi oss at fra og med versjon 8.3.10 har støtte for modale vinduer blitt avviklet i webklienten. I dette tilfellet, hvis en modal metode kalles i konfigurasjonen, genereres et unntak. Støtte for grensesnittmodus er også avviklet i webklienten I separate vinduer. I tillegg er det ikke lenger mulig i både tynne klienter og nettklienter å åpne et skjema i et eget vindu (når du arbeider i bokmerke-grensesnittmodus). Slike drastiske skritt gjorde det mulig å forlate grensesnittmodusen, som ikke lenger støttes av alle moderne nettlesere.

Hvilken praktisk konklusjon kan trekkes fra denne informasjonen? Og konklusjonen er ganske enkel - hvis det av en eller annen grunn fortsatt er modale anrop i konfigurasjonen din, vil et vindu med en feilmelding vises på disse stedene i webklienten. Jeg vil advare mot å prøve å "Google" noen raske løsninger på dette problemet, fordi... De fleste rådene kommer ned til denne oppskriften: i konfiguratoren på konfigurasjonsnivået, sett egenskapen "Modalitetsbruksmodus" til "Bruk". Naturligvis, for øyeblikket, vil dette ikke fungere bare fordi moderne nettlesere selv ikke lenger støtter modale anrop.

Og du har bare to måter å løse problemet beskrevet ovenfor:

1. Oppdater plattformen til utgivelse 8.3.10+ (8.3.11), sett konfigurasjonsegenskapen "Kompatibilitetsmodus" til "Ikke bruk" og omskriv kodefragmenter som bruker modale metoder til en asynkron forretningslogikkmodell
2. Anbefal klientene dine å bruke eldre nettlesere som fortsatt støtter modale anrop (Mozilla Firefox versjoner 37 og under, Chrome-versjoner under 37 osv.).

Forresten, fra og med versjon 8.3.11, støttes ikke lenger Microsoft Internet Explorer-nettlesere versjon 8 og 9.

Vi har behandlet nettlesere i lys av modalitet, nå er det på tide å avklare situasjonen med andre kunder.

Fra og med versjon 8.3.5, respekteres Modality Usage Mode-egenskapen i tynne og tykke klienter bare hvis kommandolinjealternativet /EnableCheckModal er spesifisert. Denne parameteren settes automatisk inn i kommandolinjen bare når applikasjonen startes fra konfiguratoren. Hvis denne parameteren ikke er spesifisert, genereres ingen unntak og tilsvarende advarsler vises ikke. De. i praksis, når du bruker en tykk og tynn klient, observeres ingen grunnleggende endring i driften når du bruker modal modus - modale anrop vil fungere på samme måte som de fungerte før, uten å produsere noen advarsler, som i webklienten.

For å prikke i-ene, legg merke til at fra og med versjon 8.3.9 ignorerer den tykke klienten konfigurasjonsegenskapen "Modus for bruk av synkrone anrop til plattformutvidelser og eksterne komponenter", mens de tilsvarende synkrone metodene fungerer uten å generere unntak og vise advarsler. Den angitte ignorerte egenskapen ble lagt til i versjon 8.3.5 for å støtte asynkront arbeid med eksterne komponenter, kryptografi og utvidelser for arbeid med filer i Google Chrome-nettleseren. Det er klart at dette ikke har noe med den tykke klienten å gjøre, og derfor eliminerte det "stille" å ignorere denne egenskapen unødvendige kontroller for bruk av synkrone metoder når du bruker konfigurasjonen.

Forresten! På grunn av det faktum at plattformen beveger seg trygt mot nettet, har utviklerne med versjon 8.3.8 innført visse begrensninger på programkoden som er knyttet til logikken for å lukke et skjema eller en applikasjon, utført i tykke og tynne klienter. Sørg for å lese artikkelen vår som dekker denne nyansen i detalj. I tillegg, i kurset "Profesjonell utvikling av grensesnitt og skjemaer i 1C: Enterprise 8.3", er det et kapittel dedikert til å forlate modalitet, og du kan hente mye nyttig og relevant informasjon om dette emnet.

Kolleger, det er to ting du kan lese i det uendelige: VKontakte-feeden og listen over endringer i neste utgivelse av plattformen, så la oss oppsummere de endelige resultatene;)

I prosessen med å vurdere eksempler som lar deg gå fra elementer av en synkron modell til en asynkron, har du sannsynligvis allerede lagt merke til at det i det generelle tilfellet er mer programkode. Jo mer kode det er, desto mer kompleksitet øker dens videre vedlikehold og feilsøking.

I tillegg vil mengden kode øke enda mer dersom vi bruker flere dialoger under utviklingsprosessen. Derfor, i prosessen med å utvikle applikasjonsløsninger fokusert på å jobbe i en webklient, må du huske arbeidsparadigmet som for tiden brukes i moderne webapplikasjoner. Derfor, hvis konfigurasjonen din har mange interaktive dialoger med brukeren og advarsler, er det fornuftig å revurdere denne funksjonaliteten til fordel for noen andre tilnærminger for å organisere brukerinteraksjon.

I stedet for en konklusjon

Syklusen vår "Første trinn i 1C-utvikling" har nådd slutten. Hvis du leser den i sin helhet, har du mest sannsynlig allerede lagt merke til hvordan plattformen har utviklet seg med stormskritt i det siste. Materialet i denne serien ble skrevet relativt nylig, men vi ble tvunget til å oppdatere det seriøst, fordi... Selv på så kort tid har det dukket opp mye ny viktig funksjonalitet og endringer. Slike store endringer kan være litt forvirrende for en 1C-programmerer hvis han ikke har vokst og utviklet seg profesjonelt med plattformen hele denne tiden.

På spesialiserte Internett-ressurser kan du ofte lese forespørsler fra nybegynnere programmerere og deres mer modne kolleger om å anbefale materialer som vil hjelpe dem å forstå de omfattende og noen ganger tilsynelatende uendelige mulighetene til 1C-plattformen. Tradisjonelt anbefaler vi at du tar hensyn til våre programmeringskurs

Hvorfor oppstår feilen "Bruk av synkrone metoder på klienten er forbudt"?

Hvis du støter på en slik feil mens du fullfører leksjonene, er det veldig enkelt å fikse det.

Gå tilbake til konfiguratoren og velg menypunktet "Konfigurasjon" -> "Åpne konfigurasjon":

I vinduet som åpnes, høyreklikk på "Konfigurasjon"-elementet og velg "Egenskaper" fra menyen som åpnes:

Et vindu med konfigurasjonsegenskaper åpnes (til høyre):

Rull helt til bunnen og finn elementet "Modalitetsmodus" der:

Sett verdien til "Bruk":

Merk følgende! Vær oppmerksom på at hvis du bruker en 1C-plattform som er forskjellig fra den vi lastet ned i den første leksjonen (senere versjon), vil du også ha feltet "Modus for bruk av synkrone samtaler...". Den må også settes til "Bruk".

Til slutt velger du menypunktet "Konfigurasjon" -> "Lagre konfigurasjon":

Klar! Nå vil feilen ikke lenger oppstå.

Forklaringer nedenfor - for de som er interessert i det vi gjorde.

Vi har aktivert modalitetsmodus i konfigurasjonen vår. Som standard er denne modusen deaktivert, og dette tillater oss ikke å bruke kommandoer som EnterNumber, EnterString, EnterDate, OpenValue.

Faktum er at disse kommandoene er modale. Å ringe dem resulterer i at et vindu vises foran brukeren (for eksempel for å legge inn informasjon), som blokkerer muligheten til å jobbe med programmet til vinduet lukkes.

Og siden tilstedeværelsen av slike vinduer er ekstremt uønsket når du arbeider med 1C gjennom en nettleser, når du utvikler nye konfigurasjoner, er modalitetsmodusen slått av som standard.