Android 

Hva er en hendelsesbehandler i 1s. Alle arrangementsabonnementer. Abonnementer på arrangementet "Når du legger ut" et dokument

Denne artikkelen er en kunngjøring om ny funksjonalitet.
Det anbefales ikke å bruke innholdet i denne artikkelen for å lære ny funksjonalitet.
En fullstendig beskrivelse av den nye funksjonaliteten vil bli gitt i dokumentasjonen for den tilsvarende versjonen.
En fullstendig liste over endringer i den nye versjonen er gitt i filen v8Update.htm.

Implementert i EDT versjon 1.7.0.567.

I 1C:Enterprise Development Tools (EDT) har vi implementert en prototype av et nytt verktøy. Arbeidsnavnet til dette verktøyet er editor Alle arrangementsabonnementer. Det vil hjelpe deg med å enkelt analysere abonnementer på alle hendelser som finnes i applikasjonsløsningen.

Arrangementsabonnement

1C:Enterprise-plattformen lar deg opprette abonnementer på hendelser av konfigurasjonsobjekter i applikasjonsløsningen. Et abonnement er en prosedyre som vil bli utført etter at den opprinnelige hendelsesbehandleren er utført. Bekvemmeligheten med abonnementer ligger i det faktum at en prosedyre kan "abonneres" på en hendelse som tilhører forskjellige konfigurasjonsobjekter. Således, hvis det er en algoritme som må utføres både når du registrerer en organisasjon og når du registrerer en avdeling, kan den lokaliseres i abonnementet, og da trenger du ikke engang å endre behandlerne for denne hendelsen i selve objektene.

Det viser seg at abonnement er en praktisk og universell mekanisme. Men i store applikasjonsløsninger kan antallet arrangementsabonnementer nå flere hundre. Det blir upraktisk å analysere dem i konfigurasjonstreet, i en lineær liste. For eksempel i en applikasjonsløsning 1C:Enterprise Management (ERP) mer enn 340 arrangementsabonnementer.

EDT gjør arbeidet med abonnementer noe enklere ved å vise dem i panelet Opplegg, når en modul til et applikasjonsobjekt åpnes.


Denne visningen av abonnementer er praktisk for en rekke oppgaver knyttet til redigering av en modul. Men det er fortsatt ikke egnet når du raskt skal finne og analysere alle algoritmene som kjøres i abonnementer når en bestemt hendelse inntreffer.

Alle arrangementsabonnementer

For å bli kvitt ulempene som er oppført ovenfor, har vi implementert en universell måte å representere abonnementer, hendelser, konfigurasjonsobjekter og prosedyrer der abonnementsalgoritmer er implementert.


Som et resultat kan du ringe redaktøren Alle arrangementsabonnementer for hele konfigurasjonen, eller bare for ett objekt - forskjellen vil bare være i sammensetningen av dataene, filtrert på en eller annen måte.


På venstre side viser redaktøren alle hendelser, og i hver hendelse alle dens abonnementer. Når du velger et spesifikt abonnement, vises en liste over konfigurasjonsobjekter hvis hendelser abonnementet er "abonnert" på, øverst til høyre. Og modulen og prosedyren som abonnementsalgoritmen er plassert i vises nederst til høyre. Ved å dobbeltklikke på en prosedyre kan du åpne den i den innebygde språkredigereren.

Mens du er i redigeringsprogrammet, kan du analysere ikke bare individuelle abonnementer, men også alle abonnementer relatert til en hendelse. Hvis du velger en hendelse, vil redaktøren vise alle moduler og alle prosedyrer signert for å behandle denne hendelsen.


Hvis du kaller redaktøren for et konfigurasjonsobjekt, vil kun objektets hendelser og abonnementer vises, og selve objektet vil alltid være uthevet i rødt i kildelisten. På denne måten kan du raskt sjekke for eksempel at abonnementet du velger fungerer for alle konfigurasjonsobjekter det er nødvendig for.


Ved å ringe editoren ved hjelp av en kontekstkommando (på et konfigurasjonsobjekt) kan du umiddelbart redusere antall abonnementer som vises i editoren. For eksempel kan du se abonnementer kun for de hendelsene som behandles i objektmodulen eller i managermodulen.


I tillegg inneholder editoren et universelt filter som du kan tilpasse sammensetningen av objekter, hendelser og prosedyrer med på hvilken som helst måte.


Merk at med dette filteret kan du velge ikke bare spesifikke objekter som er kilden til hendelser, men også sett med typer som f.eks. DirectoryObject, DocumentObject og andre. Slike sett med typer inkluderer alle kataloger eller alle dokumenter som er i konfigurasjonen.

Ved å søke etter streng kan du raskt bare finne de abonnementene som er relatert til mekanismen du er interessert i.


Når som helst kan du raskt filtrere innhold etter hendelsen eller kilden som vises i redigeringsprogrammet. Du fant for eksempel et abonnement Sjekk beregningsformelen. Kilden er planen for beregningstyper Holder.


Ved å bruke kontekstkommandoen på beregningstypeplanen kan du raskt se bare de abonnementene som er knyttet til hendelsene.


Legger til bruddpunkter automatisk

En vanlig måte å analysere hendelsesabonnement på er å se sekvensielt alle kalte prosedyrer i feilsøkeren i den rekkefølgen de ble utført. For å gjøre dette gir editoren et praktisk verktøy for automatisk å legge til bruddpunkter til behandlere.

Først av alt kan du kalle dette verktøyet direkte i editoren.


Du kan finne og velge objektet du er interessert i, velge en av dets hendelser og markere for eksempel alle behandlere. Etter å ha klikket OK bruddpunkter vil bli lagt til den første kjørbare linjen til hver kontrollert behandler, og alle disse bruddpunktene vil vises i panelet Knekkpunkter I perspektiv Feilsøking.


En annen måte å legge til bruddpunkter er praktisk når du allerede har funnet objektet eller hendelsen du er interessert i i redigeringsprogrammet. I dette tilfellet kan du ringe kommandoen som passer deg fra kontekstmenyen.


Og til slutt, den tredje måten du kan bruke er å automatisk legge til bruddpunkter mens du feilsøker. I dette tilfellet trenger du ikke å åpne redigeringsprogrammet fordi add-kommandoen er rett i panelet Knekkpunkter.


Så redaktøren Alle arrangementsabonnementer er et universelt verktøy som lar deg bruke en rekke analysescenarier. Det vil være nyttig ikke bare for utviklere som kjenner applikasjonsløsningen godt, men også for implementeringsspesialister eller IT-spesialister som trenger å forstå ukjent funksjonalitet.

Når brukeren utfører noen handlinger, genererer 1C-plattformen programhendelser. Som regel genereres ikke én hendelse, men en hel kjede av hendelser. Programmererens oppgave er å plassere programkoden riktig i hendelser for å oppnå forventet oppførsel fra programmet. Dette vil imidlertid ikke være lett for en nybegynner 1C-programmerer å gjøre, av grunnene som er oppført nedenfor.

Hendelser kan genereres i en kontrollert form: På ReadingOnServer, OnCreatingOnServer, OnOpening, etc.

Hendelser i kontrollert form genereres på klienten og på serveren: BeforeRecord, BeforeRecordOnServer.

Hendelser kalles opp i forskjellige moduler: ElementForm, ObjectModule, ManagerModule.

Noen hendelser kan kalles flere ganger hvis det er flere katalogelementer i listen, for eksempel: ProcessingGetView.

Et administrert skjema kan åpnes som et resultat av forskjellige brukerhandlinger, og kjedene av hendelsesanrop vil variere. Enhver av følgende brukerhandlinger med katalogen vil åpne et kontrollert skjema: opprette et nytt element, kopiere et element, endre et eksisterende katalogelement.

Hendelser genereres også av skjemaelementer: når du legger til en rad i tabelldelen, når du redigerer en rad i tabelldelen, når du aktiverer en rad eller et felt, når du velger et oppslagselement i inndatafeltet, osv.

For bedre å forstå logikken og rekkefølgen av utløste hendelser, kan du bruke "Studie av hendelser"-utviklingen vedlagt denne artikkelen. Når du kjenner konteksten til hendelsesanropet, hendelsesforløpet og handlingene som brukeren skal utføre, vil det være lettere å forstå hvilken hendelsesbehandler som er best å plassere programkoden i.

Instruksjoner for bruk av Event Study-programmet

Event Study-programmet viser hendelsene som 1C-plattformen genererer under interaktive brukerhandlinger. Driftsprinsippet er som følger: brukeren åpner katalogen, programmet viser hendelseskjeden. Brukeren merker et katalogelement for sletting, og programmet viser sekvensen av hendelser som oppstår. Hendelser vises med en liten forsinkelse på 3 sekunder som standard, dette er nødvendig for å skille en hendelseskjede fra en annen hendelseskjede. Derfor må du utføre interaktive handlinger "sakte".

Alle hendelser vises i et spesielt "Siste hendelser"-vindu. Her kan du aktivere eller deaktivere hendelsesopptak. Som standard er hendelsesopptak aktivert første gang den åpnes. Jeg anbefaler deg å feste "Siste hendelser"-vinduet nederst på skjermen umiddelbart når du starter programmet, for praktisk visning av hendelser.

Programmet i seg selv kan ikke bestemme hvilken handling som forårsaket hendelseskjeden; Jeg anbefaler deg å skrive inn navnene på de siste handlingene dine i feltet "Action Cause", for eksempel "Kataloglisteskjemaet er åpent," "Et element i katalogen listen er merket for sletting» osv. Dette vil da gjøre det lettere å analysere handlinger og hendelser.

Hendelser registreres og vises for objekter plassert i "Hendelsessporing"-delen, forutsatt at hendelsesregistrering er aktivert i "Nylige hendelser"-skjemaet.

Alle registrerte hendelser kan sees gjennom "Hendelsesrapport", som er plassert i "Service"-delen.

For raskt å slette alle registrerte handlinger og hendelser, i "Service"-delen, velg "Slett hendelser og handlinger".

Abonnement på en hendelse 1C 8.3 og 8.2 er et konfigurasjonsobjekt som lar deg tilordne en behandler til en spesifikk objekthendelse. En slik behandler kan tilordnes flere konfigurasjonsobjekter samtidig, for eksempel til alle dokumenter samtidig.

La oss se nærmere på dette metadataobjektet.

  • Når du installerer et nytt nummer
  • Ved kopiering
  • Behandler Fylling
  • Før opptak
  • Ved opptak
  • Før sletting
  • BearbeidingLedende
  • BehandlingFjerningUtfører
  • ProcessingCheckingFylling

Du kan abonnere på et arrangement bare på objektet, ikke på skjemaet.

Rekkefølgen for å ringe behandlere i 1C 8

Hendelsesabonnementsbehandlere kalles etter objektbehandleren, dvs. hvis hendelsesabonnementet er satt til "ProcessingProcessing"-hendelsen, vil behandleren fra objektmodulen kjøre først, og deretter behandleren fra abonnementet.

Få 267 videotimer på 1C gratis:

Hvis det er flere abonnementer på én begivenhet, blir abonnementet som er høyere i konfigurasjonstreet først kalt etter erfaring. Selv om 1C-selskapet selv melder at denne prioriteringen ikke er bestemt.

Bruke arrangementsabonnement i 1C

Å bruke abonnement er veldig praktisk, for eksempel å registrere endringer for . Eller en annen handling som er den samme for forskjellige konfigurasjonsobjekter.

Jeg bruker ofte arrangementsabonnement for ikke å endre standard . Dette er veldig praktisk, for eksempel kan vi i et abonnement justere dokumentbevegelser eller legge til bevegelser i nye registre uten å endre konfigurasjonen.

Sette opp et arrangementsabonnement

Å sette opp et abonnement er veldig enkelt:

  • Kilde— datatyper som behandleren er installert for;
  • Begivenhet– hendelsen som behandleren er installert for;
  • Handler— indikerer prosedyren som hendelsesbehandleren vil bli lokalisert fra.

Når du utvikler eller endrer applikasjonsløsninger på 1C:Enterprise 8.x-plattformen, er det svært ofte nødvendig å utføre en standardhandling for en gruppe konfigurasjonsobjekter (for eksempel kataloger). For ikke å beskrive handlingene som utføres i modulen til hvert objekt, kan utvikleren bruke standardplattformmekanismen - arrangementsabonnement.

Hendelsesabonnementer lar deg avskjære hendelser for konfigurasjonsobjekter, for eksempel kataloger, dokumenter, planer av karakteristiske typer og andre. I dag i artikkelen vil vi vurdere spørsmålet om sekvensen for utførelse av hendelsesabonnementsbehandlere, og også analysere oppførselen til plattformen med flere hendelsesabonnementer for en handling (for eksempel ved opptak).

Standard oppførsel

La vårt eksempel bruke en bestemt katalog "SimpleDirectory". Den har arrangementsabonnementer opprettet for hver hendelse som utvikleren kan gripe inn på. Prosedyrer for hendelsesbehandler er plassert i den tilsvarende serverens fellesmodul.

Rekkefølgen for å ringe abonnementsbehandlere er den samme som i standardoppførselen til plattformen når du arbeider med dette objektet. Siden vi i vårt eksempel vurderer å jobbe med en katalog, foreslår jeg å vurdere ordningen for å kalle behandlere avhengig av handlinger med et objekt (se neste skjermbilde).

Som vi kan se, kalles hendelsesbehandlerne "ProcessingFill" (for å lage et nytt element) eller "On Copying" (for å lage et element basert på et eksisterende) i det innledende stadiet. I begge tilfeller, etter å ha kalt de navngitte behandlerne, utføres "OnInstallNewCode"-prosedyren, der utvikleren kan sette et prefiks i koden eller overstyre plattformens oppførsel når den tilordner en ny kode.

Når du skriver et katalogelement, enten det er et nytt element eller et eksisterende, kalles tre behandlere: "ProcessingFillCheck" (på dette stadiet kan behandleren kontrollere riktigheten av de angitte dataene og, hvis det er feil, nekte å skrive), "BeforeWrite" (inntil objektet er skrevet i databasen, kan du justere verdiene til detaljene og sjekke eventuelle tilleggsbetingelser) og deretter "OnRecord" (en registrering er gjort til databasen, men transaksjonen er ikke lukket , kan utvikleren sjekke dataene etter registreringen og om nødvendig kansellere transaksjonen).

"BeforeDelete"-hendelsen skjer bare hvis et objekt slettes direkte fra infobasen. Vanligvis har ingen bruker tillatelse til å slette direkte uten å sjekke referanseintegriteten. Sletting skal alltid utføres ved å bruke "Slette merkede objekter"-prosessen. I sistnevnte tilfelle kalles også "BeforeDelete"-behandleren.

Derfor, hvis vi oppretter et katalogelement og skriver det til infobasen, vil plattformen kalle opp følgende hendelsesbehandlere i den angitte rekkefølgen:

Når det gjelder andre konfigurasjonsobjekter, vil driften av avære lik, bare hendelsene og deres rekkefølge kan variere. Se syntakshjelperen for flere detaljer.

Den udokumenterte siden

La oss nå se på en interessant situasjon. La oss si at for vår katalog "SimpleDirectory" er tre abonnementer på "BeforeRecord"-hendelsen definert:

I hvilken rekkefølge tror du behandlerne for disse abonnementene vil bli kalt? La oss ikke gjette. Jeg vil gi resultatet av opptak av et element der behandleren for hvert abonnement viser en melding med navnet på det oppringte abonnementet (se følgende skjermbilde).

Fra skjermbildet er det ikke vanskelig å gjette at rekkefølgen på prosedyrene for oppringing av hendelsesabonnementsbehandler tilsvarer rekkefølgen til metadataobjekter i grenen "Hendelsesabonnementer". Denne funksjonen er ikke beskrevet i noen referanselitteratur på 1C:Enterprise-plattformen, så du bør være forsiktig når du bruker den i konfigurasjonen, siden udokumenterte funksjoner kan endres fra versjon til versjon av 1C:Enterprise og samtidig være fraværende fra liste over programendringer.

Retrett

Du kan spørre: "Hvorfor opprette flere abonnementer for én konfigurasjonsobjekthendelse?" Svaret er enkelt. Hvis flere personer er involvert i utviklingen, kan interferens i hverandres opprettede mekanismer føre til feil drift av programmet. I slike tilfeller vil det mest logiske å gjøre å opprette separate arrangementsabonnementer for hver utvikler i samsvar med oppgaven. Selvfølgelig er det mulig at de i fremtiden vil bli kombinert til en enkelt behandlerprosedyre.

Når en bruker klikker på en knapp, åpnes eller lukkes et skjema, et dokument skrives, en hendelse oppstår.

Før vi registrerer hvert dokument, ønsker vi å sjekke at denne detaljen er fylt ut.

Hvordan gjøre det?

Abonnement på 1C-arrangementer

Abonnement på 1C-hendelser er , det er plassert i konfigurasjonsgrenen Generelt/Abonnementer på 1C-hendelser.

Ved å abonnere på en 1C-hendelse kan du tilordne en behandler når en hendelse oppstår for flere objekter (kataloger, dokumenter).

La oss legge til et nytt abonnement på 1C-arrangementet og angi navnet.

I 1C-hendelsesabonnementsegenskapen Kilde - må du velge ett eller flere dokumenter, kataloger - objekter som vi plasserer behandleren på.

I egenskapen 1C Event-abonnement må du velge ett av alternativene for standardhendelser som kan oppstå med de valgte dokumentene og katalogene.

Vi forenkler ved å si "dokumenter og oppslagsverk" - faktisk kan du bruke mange 1C-objekter. Dessverre kan du ikke abonnere på 1C-skjemahendelser – for eksempel når du åpner et skjema, noe mange programmerere angrer på.

Settet med mulige hendelser avhenger av objektet. Vær forsiktig, for hvis du velger flere (flere) objekter, vil listen over hendelser kun inneholde de hendelsene som hvert av de valgte objektene kan ha (det vil si hendelser som er felles for alle valgte objekter).

Etter dette gjenstår det bare å lage en behandlerfunksjon. For å gjøre dette må konfigurasjonen ha avkrysningsboksen Server i egenskapene. Når du klikker på "forstørrelsesglass"-knappen, opprettes en funksjon - en behandler.

Alle! Vi har nettopp abonnert på 1C BeforeRecording-arrangementet for alle dokumenter. Nå, når du registrerer et dokument, vil funksjonen vår bli utført, som inkluderer en sjekk.

For å nekte å skrive et dokument hvis sjekken er negativ, må du angi funksjonsparameteren