Objektil Dokument on sündmuste kogum, millega arendaja saab sekkuda dokumendi andmebaasi kirjutamise protsessi, kasutades nende sündmuste töötlejaid. Sõltuvalt kasutaja sooritatava toimingu tüübist kutsutakse dokumendisündmusi teatud järjestuses.
Dokumendiga seotud toimingute põhitüübid on järgmised:
- Kirjuta üles
- Käitumine
- Pühkige ja sulgege
- Tühistamine
Tegevus Kirjuta üles
Postitamata dokumendi puhul on vormilt dokumendi salvestamise sündmuste jada järgmine:- Objektimoodul - enne salvestamist (tehing algab, dokument pole veel kirjutatud);
- Vormimoodul (&OnServer) - serveris salvestamisel (tehingu sooritamine);
- Vormimoodul (&OnClient) – enne salvestamist;
- Vormimoodul (&OnServer) – täitekontrolli töötlemine serveris;
- Objektimoodul - täitekontrolli töötlemine;
- Vormimoodul (&OnServer) – enne serverisse salvestamist;
- Objektimoodul - enne salvestamist (tehingu algus, dokument pole veel kirjutatud);
- Objektimoodul - kirjutamisel (dokument kirjutatakse);
- Objektimoodul - järeltöötlus (dokumentide liikumise kirjete komplekti moodustamine);
- Vormimoodul (&OnServer) - serveris salvestamisel (salvestatakse dokumentide liikumise kirjete komplekt, salvestatakse tehing);
- Vormimoodul (&OnServer) – pärast serverisse salvestamist;
- Vormimoodul (&OnClient) – pärast salvestamist.
Sündmuste jada dokumendi kirjutamisel vormilt, mille postitamine on keelatud (vara Läbiviimine seatud Keelama) on järgmine:
Erinevalt dokumendist, mis on lubatud läbi viia, pole sel juhul sündmust Töötlemine Juhtimine. Kuid postitatud dokumendi salvestamisel koos uuesti postitamisega ja dokumendi salvestamisel, mille postitamine on keelatud, kutsutakse sündmust lisaks kirjele endale ka vormi kontekstis ja objekti kontekstis TöötlemineKontrollimineTäitmine. Selle sündmuse põhjustab vormilaiend, mis kontrollib andmete täitmist registreerimisel või vormile dokumendi postitamisel.
Tegevus Viige läbi
Selle toimingu sooritamisel, st uue dokumendi salvestamisel koos vormilt postitamisega, on sündmuste jada sama, mis postitatud dokumendi salvestamisel (vt joonis 2).Tegevus Viige läbi ja sulgege
Sündmuste jada on sarnane teostamistoiminguga (vt joonis 2).Toiming Tühista
See toiming käivitab dokumendi kirjutamise ja käivitab järgmise sündmuste jada:- Vormimoodul (&OnClient) – enne salvestamist;
- Vormimoodul (&OnServer) – enne serverisse salvestamist;
- Objektimoodul - enne salvestamist (tehingu algust);
- Objektimoodul - juhtivuse kustutamise (liigutuste kustutamise) töötlemine;
- Objektimoodul - salvestamisel (liikumised kustutatakse, dokument salvestatakse);
- Vormimoodul (&OnServer) – pärast serverisse salvestamist (tehingu kinnistamine);
- Vormimoodul (&OnClient) – pärast salvestamist.
Rakenduslahenduste arendamisel või muutmisel platvormil 1C:Enterprise 8.x on väga sageli vaja konfiguratsiooniobjektide rühma (näiteks kataloogide) jaoks teha mõni standardtoiming. Selleks, et mitte kirjeldada iga objekti moodulis tehtud toiminguid, saab arendaja kasutada standardset platvormimehhanismi - sündmuste tellimust.
Sündmuste tellimine võimaldab pealt kuulata konfiguratsiooniobjektide sündmusi, nagu kataloogid, dokumendid, iseloomulikku tüüpi plaanid ja muud. Tänases artiklis käsitleme sündmuste tellimustöötlejate täitmisjärjestuse küsimust ja analüüsime ka platvormi käitumist mitme sündmuse tellimusega ühe toimingu jaoks (näiteks salvestamisel).
Tavaline käitumine
Laske meie näites kasutada teatud kataloogi "SimpleDirectory". Sellel on iga sündmuse jaoks loodud sündmuste tellimused, millesse arendaja saab sekkuda. Sündmuste töötleja protseduurid asuvad vastavas serveri ühismoodulis.
Tellimuse töötlejate helistamise järjekord on sama, mis platvormi tavapärases käitumises selle objektiga töötamisel. Kuna meie näites kaalume töötamist kataloogiga, teen ettepaneku kaaluda töötlejate kutsumise skeemi sõltuvalt objektiga tehtud toimingutest (vt järgmist ekraanipilti).
Nagu näeme, kutsutakse algstaadiumis sündmuste käitlejaid “ProcessingFill” (uue elemendi loomiseks) või “On Copying” (olemasoleva elemendi loomiseks). Mõlemal juhul käivitatakse pärast nimetatud töötlejate kutsumist protseduur "OnInstallNewCode", kus arendaja saab määrata koodis prefiksi või alistada platvormi käitumise uue koodi määramisel.
Kataloogielemendi kirjutamisel, olgu see siis uus või olemasolev element, nimetatakse kolme töötlejat: “ProcessingFillCheck” (selles etapis saab töötleja kontrollida sisestatud andmete õigsust ja vigade korral kirjutamisest keelduda), “BeforeWrite” (kuni objekt on andmebaasi kirjutatud, saab muuta detailide väärtusi ja kontrollida lisatingimusi) ja seejärel “OnRecord” (andmebaasi on tehtud kirje, kuid tehingut ei sulgeta , saab arendaja pärast registreerimist andmeid kontrollida ja vajadusel tehingu tühistada).
Sündmus "BeforeDelete" toimub ainult siis, kui objekt kustutatakse otse teabebaasist. Tavaliselt pole ühelgi kasutajal õigust otse kustutada, ilma viite terviklikkust kontrollimata. Kustutamine tuleks alati läbi viia töötluse "Märgitud objektide kustutamine" abil. Viimasel juhul kutsutakse ka töötleja "BeforeDelete".
Seega, kui loome kataloogiüksuse ja kirjutame selle teabebaasi, kutsub platvorm määratud järjekorras järgmisi sündmuste töötlejaid:
Teiste konfiguratsiooniobjektide osas on sündmuste tellimismehhanismi töö sarnane, erineda võivad ainult sündmused ja nende järjekord. Lisateavet leiate süntaksiabist.
Dokumentideta pool
Vaatame nüüd ühte huvitavat olukorda. Oletame, et meie kataloogi "SimpleDirectory" jaoks on määratletud kolm sündmuse "BeforeRecord" tellimust:
Mis järjekorras teie arvates nende tellimuste töötlejaid kutsutakse? Ärme oleta. Annan elemendi salvestamise tulemuse, kus iga tellimuse töötleja kuvab sõnumi kutsutud tellimuse nimega (vt järgmist ekraanipilti).
Ekraanipildi põhjal pole raske arvata, et sündmuste tellimise töötleja protseduuride kutsumise järjekord vastab haru „Sündmuste tellimused“ metaandmeobjektide järjestusele. Seda funktsiooni ei kirjeldata üheski 1C:Enterprise'i platvormi teatmekirjanduses, seega peaksite selle konfiguratsioonis kasutamisel olema ettevaatlik, kuna dokumenteerimata funktsioonid võivad 1C:Enterprise'i versioonide lõikes muutuda ja samal ajal puududa programmi muudatuste loend.
Taganeda
Võite küsida: "Miks luua ühe konfiguratsiooniobjekti sündmuse jaoks mitu tellimust?" Vastus on lihtne. Kui arendusse on kaasatud mitu inimest, võib üksteise loodud mehhanismidesse sekkumine põhjustada programmi ebaõiget toimimist. Sellistel juhtudel oleks kõige loogilisem luua iga arendaja jaoks eraldi sündmuste tellimused vastavalt käsilolevale ülesandele. Muidugi on võimalik, et tulevikus ühendatakse need ühtseks käitleja protseduuriks.
1C teabebaasiga töötades on sageli vaja siduda uus algoritm objekti muutusega seotud sündmusega. Programmi versioonis 7 oli käitleja käivitamiseks vaja programmi lähtekoodi ümber kirjutada, mis tõi kaasa probleeme konfiguratsiooni värskendamisel.
Pärast kasutajate tagasiside analüüsimist juurutasid kaheksa arendajat uue objekti nimega "Sündmuste tellimus". Selles artiklis püüame paljastada:
- Tellimuste seadistamine;
- Loomine;
- Toimimise tunnused.
Looge uus tellimus
Nagu iga teine metaandmeobjekt, lisatakse konfiguraatorist 1C sündmuse tellimus.
Need elemendid asuvad puuharus “Üldine” (joonis 1).
Uue töötleja lisamiseks peate tegema järgmist.
Joonis 3
Värskendamisega seotud probleemide vältimiseks on oma arenduste jaoks kõige parem luua oma ühine moodul, mis sisaldab ainult teie protseduure ja funktsioone.
Tellimuste toimimise omadused
Üks peamisi küsimusi, mis tekib kasutajatele, kes hakkavad töötama objektiga „Sündmuste tellimus”, on protseduuride kutsumise järjekord. Sageli peituvad siin vead, kuna protseduur ei tööta või töötab ainult aeg-ajalt.
Kasutades mis tahes dokumendi protseduuri AtWrite() näidet, näete töötlejate kutsumise järjekorda.
Seega, kui dokumendiobjekti moodulis on see protseduur olemas ja sellega paralleelselt toimub tellimusest väljakutsutud töötlus ja sama sündmuse töötlemine, siis töödeldakse esmalt dokumendimoodulit. Kui dokumendimoodulis käsu AtRecord() täitmisel võtab parameeter Rejection mingil põhjusel väärtuse True, on tellimus garanteeritud, et see ei tööta.
Juhul, kui ühe allika ja ühe sündmuse jaoks on mitu samasugust tellimisobjekti, on täitmise järjekorda väga raske jälgida. Ja kui vähemalt ühe käitleja täitmise ajal tehakse erand, jäävad mõned protseduurid teostamata.
Seega saab töötlemise järjestuse määrata järgmiselt:
- Objektimooduli sündmusi töödeldakse;
- Praeguse andmetüübiga otseselt seotud tellimusi töödeldakse;
- Üldtüübiga seotud koodi töödeldakse.
Väga oluline on meeles pidada, et mitte mingil juhul ei tohi salvestamise ajal sooritatavatesse protseduuridesse sisestada koodi, mis muudab lähteobjekti andmeid, kuna see võib kaasa tuua tarbetu loopimise. Sellist koodi on parem kasutada BeforeWrite protseduurides.
Vormi avatud sündmuste käitleja
Programmi versioonis 8 kasutatavate hallatavate vormide kasvav populaarsus ja probleemid, mis on seotud nende objektide värskendamisega nende enda muudatuste salvestamise ajal, viisid selleni, et alates platvormist 8.2.15 ilmus programmi FormReceivingProcessing sündmus. Siin saate sisestada koodi, mis muudab ja asendab standardvorme.
Mõned selle töötleja funktsioonid:
- Sündmus ei käivitu, kui avatav standardvorm on konfiguratsioonis rangelt määratud;
- Sündmust saab rakendada ainult hallatavate vormide jaoks;
- Seda käitlejat sisaldaval üldmoodulil ei pea olema mitte ainult atribuut „Server”, vaid ka väljal „Kõneserver” märgitud ruut.
Oluline on arvestada, et seda tellimust kutsutakse mitte konkreetse objekti, vaid selle halduri jaoks, see tähendab, et lähteväli peab sisaldama seda sõna (joonis 4).
Joonis 4
Eelneva kokkuvõtteks tahan öelda, et “Sündmuste tellimine” on arendajale äärmiselt kasulik ja vajalik tööriist, mis võimaldab arendajal saavutada enda eesmärke ja eesmärke ilma suurema sekkumiseta konfiguratsiooni.
Programmeerijal, kellel on vähe kogemusi platvormi 1C 8.2 kasutamisel, võib olla raske aru saada: Enne salvestamist, salvestamise ajal, pärast salvestamist, serveris, kliendis, vormimoodulis, objektimoodulis, ah-ah-ah- Ah ah!!
Alguses valdas mind just see keeruline arusaamatuse tunne. Õppimise ja reaalse kogemuse käigus sündis see petuleht, mille eesmärk oli "kõik ära sorteerida", et oleks selge arusaam, millisel juhul tuleks kasutada ja millises järjekorras need salvestamisel käivitatakse. objektid.
Miks meil neid käitlejaid üldse vaja on?
Väga sageli on programmeerijal vaja alistada objektide salvestamisel süsteemi standardkäitumine, nimelt: teatud tingimuste korral salvestamine tühistada; nõuda kasutajalt lisateavet; täitke üksikasjad; kirjuta selle kirje põhjal andmebaasi midagi muud; muuda midagi vormil peale salvestamist jne. ja nii edasi. Iga programmeerija puutub varem või hiljem kokku sarnaste ülesannetega, seetõttu peab platvormil 1C 8.2 töötav programmeerija teadma nende sündmuste käivitamise eesmärki ja järjestust.
Vormimoodulis või objektimoodulis?
Kõigepealt peame otsustama, kas vajame vormiandmeid? Kas salvestis salvestatakse programmiliselt või ainult interaktiivselt? Kas peame kasutajaga dialoogi?
Fakt on see, et osa sündmusi täidetakse vormimooduli tasemel, mis tähendab, et need käivituvad ainult interaktiivse salvestamise ajal ning ka nende sündmuste puhul pääseme ligi vormiandmetele ja peame kasutajaga dialoogi.
Teine osa sündmustest teostatakse objektimooduli tasemel nii interaktiivse kui ka programmilise salvestamise ajal.
Seetõttu saate kohe otsustada vormimooduli või objektimooduli töötleja üle, kellega koostööd teeme.
Vormimoodul: klient või server?
Järgmiseks, kui on valitud vormimoodul, peate otsustama, millist töötlejat on vaja: käivitatav kliendis või käivitatav serveris. Kui on vaja dialoogi kasutajaga, siis kliendis, muidu serveris. Neid saab eristada kompileerimisdirektiivi nimetuse või töötleja nime järgi (serveris olles kirjutatakse see nimesse, näiteks BeforeWriteOnServer()).
Kuidas valida konkreetset käitlejat?
Valik sõltub käsil olevast ülesandest. Kirjeldan allpool, mida igas töötlejas täpselt teha saab, kuid praegu toome näite.
Näide objektide kirjutamise sündmuste käitlejate valimisest:
On ülesandeid, kui ühe ülesande lahendamiseks on vaja kasutada mitut töötlejat. Näiteks peate salvestamise ajal küsima kasutajalt teavet: "Kas loome selle kirje põhjal uue dokumendi?" ja kui kasutaja vastab jaatavalt, siis tuleb luua uus dokument koos lingiga salvestatavale objektile. Veelgi enam, uue dokumendi registreerimine tuleb tehingus läbi viia, kuna kui praegune kirje mingil põhjusel tühistatakse, siis juba loodud ja salvestatud dokumenti ei tohiks andmebaasi jääda.
Selle probleemi lahendamiseks peate kasutama vormimooduli sündmuste töötlejaid kahel põhjusel.
1) Dialoog kasutajaga on võimalik ainult kliendi peal ja klienditöötlejad on ainult vormimoodulis. Dialoogi jaoks kasutame vormimooduli BeforeRecord() kliendiprotseduuri ja salvestame kasutaja vastuse selle protseduuri parameetrisse “Parameetrite salvestamine”.
2) Ja vormimooduli protseduuris WhenRecordingOnServer() aktsepteerime seda parameetrit ja olenevalt sellest loome dokumendi või mitte. Miks see konkreetne protseduur? Viide laekub alles peale salvestamist, aga kuna peame tehingutes fikseerima, siis tuleb kasutada protseduure ENNE tehingu sooritamist, kuid juba kirjutatavale objektile viidet omades. BeforeRecord() ei sobi, kuna viidet veel pole, ja AfterRecord() ei sobi, kuna tehing on juba lõpule viidud. AtRecord() jääb alles, aga oleme valiku ees: kas vormimoodul või objektimoodul? Kuna objektimooduli sündmuste töötleja OnRecord() ei sisalda kasutaja vastust sisaldavat parameetrit, küll aga vormimooduli sündmus WhenRecordingOnServer(), siis on vastus ilmne – kasutame seda vormimooduli OnRecordOnServer() sündmust, kuna :
1) See sündmus käivitatakse tehingus 2) Sisaldab parameetrit “Record Parameters”, mis sisaldab juba kasutaja vastust, mis saadeti protseduurist BeforeRecord() 3) Link on juba loodud ja saate luua uue dokumendi kasutades seda linki.
Noh, nüüd käivitamissündmuste jada (nende loetlemise järjekorras) ja väikesed üksikasjad:
Paljudel töötlejatel on parameeter "Keeldu". Kui see parameeter on olemas, tähendab see, et selles töötlejas saate siiski salvestamisest keelduda, määrates parameetri „Keeldumine” väärtuseks Tõene, ja siis salvestust ei tehta.
1) Vormimoodul BeforeRecord (tõrge, kirjeparameetrid)
Jookseb kliendi peale!
Seda käsitlejat tuleks kasutada juhul, kui on vaja enne objekti kirjutamist kasutajaga dialoogi korraldada. Küsida lisainfot, hoiatada millegi eest, anda võimalus keelduda jne.
Selle töötleja "Parameetrite kirje" teine parameeter on tüüpi "Struktuur". Dokumentide puhul täidab süsteem need parameetrid etteantud parameetritega Salvestusrežiim, Postitusrežiim. Saate lisada oma.
Need parameetrid edastatakse vormisündmuste BeforeWritingOnServer, WhileWritingOnServer, AfterWritingOnServer vahel, kus neid saab turvaliselt kasutada. Näiteks inforegistri kirjutamisel tuleb kirjutada vana ressursi väärtus mõnda teise inforegistrisse. Nendele samadele parameetritele saate edasi anda vana väärtuse ja teha kande mõnda teise WriteOnServeri registrisse.
2) Vormimoodul Serveri täitmise kontrollide töötlemine (tõrge, kinnitatud üksikasjad)
3) Objektimooduli täitmise kontrolli töötlemine (tõrge, kontrollitud üksikasjad)
Neid kahte täitekontrolli töötlejat rakendatakse massiivitüübi parameetri „Kontrollitud üksikasjad” kaudu, mis sisaldab kontrollitavaid üksikasju (st mille täitekontrolli atribuudiks on määratud „Anna viga”).
Ja kui eemaldate sellest massiivist atribuudi, siis seda ei kontrollita; kui lisate, siis kontrollitakse täitmist.
Seega võime öelda, et need kaks sündmuste käitlejat on mõeldud:
Täitesse lisamiseks märkige need andmed, mille atribuutides "Täitke kontroll" on märgitud "Ära kontrolli". Selleks peate selle atribuudi lisama massiivi parameetrile "Kontrollitud üksikasjad"
Et välistada automaatsest kontrollist üksikasjad, millel on olenevalt teatud tingimustest tšekkide täitmiseks määratud atribuut "Anna viga". Selleks peate selle atribuudi parameetri „Kontrollitud atribuudid” massiivist eemaldama
On mitmeid funktsioone, mida tuleb arvesse võtta:
Kui vormi, millelt objekti kirjutatakse, atribuutides pole seatud “Kontrolli täitmist automaatselt”, siis neid täitekontrolli töötlejaid ei kutsuta ja kontrolle ei toimu!
Helistatakse ainult interaktiivse salvestamise ajal! Saate salvestamise ajal neid ei kutsuta. Kontrollimiseks peate kasutama objekti CheckFill() meetodit, mis käivitab nende sündmuste käivitamise.
Dokumentide puhul, millel on postitamisvõimalus, tõstatatakse need polsterduse kontrollimise sündmused ainult postitamisel!
Mõlemad sündmused käivitatakse serveris, erinevus seisneb selles, et ProcessFillCheckOnServer() on vormimooduli sündmus ja seetõttu on sellel juurdepääs vormiandmetele. Ja ProcessingFillCheck() on objektimooduli sündmus.
4) Vormimoodul BeforeRecordOnServer (tõrge, CurrentObject, RecordParameters)
Selles käitlejas saate täita objekti üksikasju või teha täiendavaid kontrolle. Vormiandmetele on juurdepääs. Seal on parameeter CurrentObject.
Parameetri CurrentObject klassitüüp on “objekt”, mis sõltub kirjutatava objekti tüübist (DirectoryObject, DocumentObject jne). Need. objektiklassi eksemplar on loodud ja pääsete juurde selle omadustele ja meetoditele, kuid seda pole veel andmebaasi kirjutatud.
Tehingu algus
5) Objektimoodul enne kirjutamist (tõrge)
Selles käitlejas saate täita objekti üksikasju või teha täiendavaid kontrolle.
Dokumentide puhul lisatakse selle töötleja parameetritele veel kaks parameetrit: Salvestusrežiim, Postitusrežiim.
Salvestus
6) Objektimoodul uue numbri installimisel (standardtöötlus, eesliide)
Esineb uue dokumendi, ülesande või äriprotsessi numbri määramisel.
Või uue koodi installimisel (standardtöötlus, eesliide)
Esineb uue kataloogielemendi koodi, vahetusplaani sõlme või iseloomuliku tüübiplaani koodi installimisel.
Neid sündmusi kutsutakse objektidele, millel on määratud atribuut „Automaatne nummerdamine”, ja ainult uute objektide puhul.
Kui määrate parameetri StandardProcessing väärtuseks False, siis uut numbrit ei genereerita ja saate selles töötlejas programmiliselt määrata objekti koodi.
7) Objektimoodul OnWrite (tõrge)
Kutsutakse välja pärast objekti kirjutamist andmebaasi, kuid enne kirjutamistoimingu lõppemist.
Link on juba olemas ja selle lingi abil saate praeguse objekti põhjal andmebaasi kirjutada täiendavaid andmeid.
Näiteks looge salvestamisel teine dokument, mis sisaldab atribuudi linki salvestatavale.
8) Vormimoodul WhenRecordingOnServer (tõrge, praegune objekt, salvestusparameetrid)
Kutsutakse välja pärast objekti kirjutamist andmebaasi, kuid enne kirjutamistoimingu lõppemist. Vormiandmetele on juurdepääs. On veel viimane võimalus kohtumine tühistada.
Parameetri CurrentObject klassitüüp on “objekt”, mis sõltub kirjutatava objekti tüübist (DirectoryObject, DocumentObject jne). Võite viidata selle omadustele ja meetoditele.
Tehingu lõpuleviimine
9) Vormimoodul AfterRecordOnServer (CurrentObject, RecordParameters)
Teostatud serveris.
Saab kasutada millegi visuaalseks kuvamiseks vormil.
10) Vormimoodul AfterRecord (kirjeparameetrid)
Jookseb kliendi peale!
Saab kasutada vormil millegi visuaalseks kuvamiseks või kasutajale hoiatuse andmiseks.
Kui kasutaja klõpsab nupul, avaneb või sulgub vorm, kirjutatakse dokument, toimub sündmus.
Enne iga dokumendi salvestamist tahame kontrollida, kas see detail on täidetud.
Kuidas seda teha?
1C ürituste tellimused
1C sündmuste tellimus on , see asub jaotises Üldine / 1C sündmuste tellimused.
1C sündmuse tellimine võimaldab teil määrata käitleja, kui sündmus toimub mitme objekti (kataloogid, dokumendid) jaoks.
Lisame 1C sündmusele uue tellimuse ja määrame nime.
1C sündmuse tellimise atribuudis Allikas - peate valima ühe või mitu dokumenti, kataloogi - objekti, millele me töötleja asetame.
1C sündmuse tellimise atribuudis peate valima ühe suvanditest standardsündmuste jaoks, mis võivad valitud dokumentide ja kataloogidega esineda.
Lihtsustame, öeldes "dokumendid ja teatmeteosed" - tegelikult saate kasutada paljusid 1C objekte. Kahjuks ei saa te 1C vormisündmusi tellida - näiteks vormi avamisel, mida paljud programmeerijad kahetsevad.
Võimalike sündmuste kogum sõltub objektist. Olge ettevaatlik, sest kui valite mitu (mitu) objekti, sisaldab sündmuste loend ainult neid sündmusi, mis võivad olla igal valitud objektil (st kõigi valitud objektide ühised sündmused).
Pärast seda jääb üle vaid luua käitleja funktsioon. Selleks peab konfiguratsiooni atribuutides olema märgitud ruut Server. Kui klõpsate nuppu "suurendusklaas", luuakse funktsioon - käitleja.
Kõik! Tellisime just kõigi dokumentide jaoks ürituse 1C BeforeRecording. Nüüd käivitatakse mis tahes dokumendi salvestamisel meie funktsioon, mis sisaldab kontrolli.
Dokumendi kirjutamisest keeldumiseks, kui kontroll on negatiivne, peate määrama funktsiooni parameetri