Mecanismul formelor principale. Atribuirea de gestionare a evenimentelor folosind abonamente la evenimente Crearea unui nou abonament

Modulele obiect există pentru obiectele aplicației (documente, directoare, planuri de conturi etc.) și sunt destinate în principal procesării evenimentelor standard de tip înregistrare. Aici puteți plasa și condiții precum verificarea corectitudinii datelor. Este important să înțelegeți că gestionarea evenimentelor de înregistrare poate fi, de asemenea, localizată în modulul formular, dar va funcționa numai când interactiv lucra cu obiectul. Dacă obiectul este scris în mod programatic, atunci handlerul de evenimente va fi executat din modulul obiect.
Modulul obiect poate fi deschis făcând clic pe butonul corespunzător din fila Altele:
Sul proceduri predefinite - handlere de evenimente module obiect:

Modul obiect de referință:

Când instalați un cod nou
La copiere
ProcesareFill
Înainte de înregistrare
La înregistrare
Înainte de îndepărtare
ProcesareCheckUmplere

Modul obiect document:

Prelucrare
ProcesareFill
Când instalați un număr nou
La copiere
Înainte de înregistrare
La înregistrare
Înainte de îndepărtare
ProcesareEliminare
ProcesareCheckUmplere

Modulul obiect raport:

ProcesareCheckUmplere
Când LinkingResult
SetFieldHeaders

Modul obiect de procesare:

ProcesareCheckUmplere

Modulul obiect plan tip caracteristic:

Când instalați un cod nou
La copiere
ProcesareFill
Înainte de înregistrare
La înregistrare
Înainte de îndepărtare
ProcesareCheckUmplere

Modul obiect plan de conturi:

La copiere
ProcesareFill
Înainte de înregistrare
La înregistrare
Înainte de îndepărtare
ProcesareCheckUmplere

Modul obiect plan tip calcul:

La copiere
ProcesareFill
Înainte de înregistrare
La înregistrare
Înainte de îndepărtare
ProcesareCheckUmplere

Modul obiect de proces de afaceri:

Când instalați un număr nou
La copiere
ProcesareFill
Înainte de înregistrare
La înregistrare
Înainte de îndepărtare
ProcesareCheckUmplere

Modul obiect de activitate:

Când instalați un număr nou
La copiere
ProcesareFill
Înainte de înregistrare
La înregistrare
Înainte de îndepărtare
Gestionarea activării interactive
ProcessingChecksExecution
Înainte de Execuție
Înainte InteractiveExecution
Facand
ProcessingChecksExecution

Întrebarea 06.18 a examenului 1C: Platformă profesională. Unde sunt situate procedurile de gestionare a evenimentelor obiectului aplicației, de exemplu, La scriere, înainte de ștergere?

În modulul formular
În modulul obiect
În modulul de aplicație
Obiectele aplicației nu au astfel de evenimente.

Analizând mai sus.

Întrebarea 06.41 a examenului 1C: Platformă profesională. Folosind comanda „AddHandler”, puteți atribui un handler de evenimente la:

obiect COM
1C:Instanță obiect Enterprise (atribuiți evenimentelor modulului obiect)
o instanță a obiectului „Form”.
corecte 1,2 răspunsuri
Răspunsurile 1,2,3 sunt corecte

Să trecem la asistentul de sintaxă. Exemplele tratează instanțele de obiecte și obiectele COM.

AddHandler

Sintaxă:

AddHandler<Событие>, <ОбработчикСобытия>;

Opțiuni:

<Событие>

Evenimentul la care este adăugat handlerul.

Evenimentul este stabilit în formular<Выражение>.<Имя_события>, Unde:

<Выражение>- o expresie arbitrară în limbajul încorporat, al cărei rezultat ar trebui să fie un obiect, evenimentului căruia i se adaugă un handler;

<Имя_события>- identificatorul (numele) evenimentului.

<ОбработчикСобытия>

Procedura/funcția evenimentului.

Un handler de evenimente poate fi o metodă a unui obiect limbaj 1C:Enterprise. Apoi<ОбработчикСобытия>dat ca<Выражение>.<Имя_обработчика>, Unde:

<Выражение>- o expresie arbitrară în limbajul încorporat, al cărei rezultat ar trebui să fie un obiect, a cărui metodă servește ca un handler de evenimente;

<Имя_обработчика>- numele metodei de gestionare a evenimentelor.

De asemenea, o procedură/funcție situată în domeniu poate fi setată ca handler de evenimente. În acest caz, handlerul de evenimente este specificat ca numele unei proceduri/funcție.

Descriere:

Adaugă un handler de evenimente.

Când se adaugă un handler de evenimente, se face o verificare pentru a potrivi numărul de parametri de eveniment cu numărul de parametri ai metodei atribuite ca handler.

Exemplu:

Procesare = Procesare. Controlul documentelor. Crea () ; Factură = Documente. Factura fiscala. Creați document() ; Adăugați Factură Procesor. La înregistrare, procesare. Când se scrie documentul; msword = New COMObject("Word.Application" ); Adăugați un handler msword. Schimbarea documentului, OnChangeDocument;

Procedură OnChangeDocument() A raporta ( „Documentul a fost schimbat”); EndProcedure

***

Întrebarea 06.36 a examenului 1C: Platformă profesională. Când definiți un handler de evenimente pe un obiect COM, numărul de parametri din procedura de gestionare este:

este egal cu numărul de parametri ai evenimentului obiect corespunzător
încă un parametru decât evenimentul obiect corespunzător (primul parametru conține obiectul COM în sine)
încă un parametru decât evenimentul obiect corespunzător (ultimul parametru conține obiectul COM în sine)
întotdeauna un parametru (obiectul COM în sine)

Răspunsul corect este primul.La adăugarea unui handler de evenimente, se verifică dacă numărul de parametri de eveniment se potrivește cu numărul de parametri ai metodei atribuite ca handler.

Întrebarea 06.37 a examenului 1C: Platformă profesională. La definirea unui abonament la un eveniment, numărul de parametri din procedură - handler:

această procedură nu va avea parametri

Răspunsul corect este primul. Exemplu de cod într-un handler de evenimente:

Procedură OnChangeDocument(Refuz )
EndProcedure

Un exemplu de cod de procedură handler:

Procedură OnChangeDocument(Sursa, declinare a răspunderii)

EndProcedure

Întrebarea 06.38 a examenului 1C: Platformă profesională. La definirea unui handler de evenimente pentru o instanță a obiectului 1C:Enterprise, numărul de parametri din procedura de gestionare:

este egal cu numărul de parametri ai handler-ului de evenimente corespunzător situat în modulul obiect
încă un parametru decât handlerul de evenimente corespunzător situat în modulul obiectului (primul parametru conține obiectul în sine)
încă un parametru decât handlerul de evenimente corespunzător situat în modulul obiectului (ultimul parametru conține obiectul în sine)
această procedură nu va avea parametri
întotdeauna un parametru (obiectul în sine pentru care a fost definit abonamentul)

Răspunsul corect este al doilea, similar cu întrebarea anterioară.

Întrebarea 06.40 a examenului 1C: Platformă profesională. Când atribuiți un handler de evenimente unui obiect (1C:Instanță obiect Enterprise, obiect COM), procedura responsabilă pentru procesarea acestui eveniment ar trebui să fie localizată:

necesar în modulul global partajat
necesar într-un modul partajat non-global
necesare în modulul de aplicație
alegerea modulului nu este importantă, în „vizibilitate”

Răspunsul corect este al patrulea, vezi fragmentul din asistentul de sintaxă.

La obiect Document există un set de evenimente cu care dezvoltatorul poate interveni în procesul de scriere a unui document în baza de date folosind handlere pentru aceste evenimente. În funcție de tipul de acțiune pe care îl efectuează utilizatorul, evenimentele documentului sunt declanșate într-o anumită secvență.
Există următoarele tipuri principale de acțiuni pentru un document:

a arde
Conduce
Treceți și închideți
Anulare

Luați în considerare succesiunea evenimentelor pentru fiecare acțiune.

Acțiune a arde

Pentru un document neînregistrat, succesiunea evenimentelor când documentul este scris din formular va fi următoarea:

Modul obiect - înainte de scriere (începe tranzacția, documentul nu a fost încă scris);
Modul formular (&AtServer) - la scrierea pe server (comiterea unei tranzacții);

Rețineți că pentru a extinde formularul de document, platforma 1C setează implicit valoarea Adevărat pentru proprietate OnRecordRewire, prin urmare, la înregistrarea unui document postat dintr-un formular, platforma 1C îl va reposta automat. În acest caz, pentru documentul postat, succesiunea evenimentelor la scrierea din formular va fi următoarea:

Modul formular (&OnClient) - înainte de înregistrare;
Modul formular (&AtServer) - procesarea verificării de umplere pe server;
Modul obiect - procesarea verificării umplerii;
Modul formular (&AtServer) - înainte de înregistrarea pe server;
Modul obiect - înainte de scriere (începerea unei tranzacții, documentul nu a fost încă scris);
Modul obiect - la scriere (documentul este scris);
Modul obiect - procesare postare (formarea unui set de înregistrări ale mișcărilor documentelor);
Modul formular (&AtServer) - la înregistrarea pe server (se înregistrează un set de înregistrări ale mișcării documentelor, se comite tranzacția);
Modul formular (&AtServer) - după înregistrarea pe server;
Modul formular (&OnClient) - după înregistrare.

Dacă pentru o proprietate OnRecordRewire valoarea stabilită Minciună, atunci succesiunea evenimentelor la înregistrarea unui document postat din formular va fi aceeași ca și pentru un document neînregistrat.

Secvența de execuție a evenimentelor la scrierea unui document dintr-un formular pentru care postarea este interzisă (proprietate Deținere setat la interzice) va fi după cum urmează:
Spre deosebire de document, care are voie să fie postat, în acest caz nu există niciun eveniment Prelucrare. Dar, la înregistrarea unui document postat cu repostare și la înregistrarea unui document pentru care postarea este interzisă, pe lângă înregistrarea în sine, un eveniment este numit și în contextul formei și în contextul obiectului ProcesareCheckUmplere. Acest eveniment este apelat de extensia de formular pentru a verifica dacă detaliile sunt completate atunci când scrieți sau postați un document în formular.

Action Run

La efectuarea acestei acțiuni, adică înregistrarea unui document nou cu postare din formular, succesiunea evenimentelor va fi aceeași ca și pentru acțiunea de înregistrare a unui document postat (vezi Figura 2).

Acțiune Post și Închidere

Secvența de execuție a evenimentelor este similară cu acțiunea de conduită (vezi Figura 2).

Anularea acțiunii

Această acțiune inițiază scrierea unui document și declanșează următoarea secvență de evenimente:

Modul formular (&OnClient) - înainte de înregistrare;
Modul formular (&AtServer) - înainte de înregistrarea pe server;
Modul obiect - înainte de scriere (începerea tranzacției);
Modul obiect - gestionarea înlăturării conduitei (ștergerea mișcărilor);
Modul obiect - în timpul înregistrării (mișcări eliminate, document înregistrat);
Modul formular (&AtServer) - după înregistrarea pe server (comiterea unei tranzacții);
Modul formular (&OnClient) - după înregistrare.

Dacă acțiunile nu sunt executate din formular (efectuate programatic), diferența este că evenimentele din formular nu sunt executate!

a arde
Conduce
Treceți și închideți
Anulare

Luați în considerare succesiunea evenimentelor pentru fiecare acțiune.

Acțiune a arde

Pentru un document neînregistrat, succesiunea evenimentelor când documentul este scris din formular va fi următoarea:

Modul obiect - înainte de scriere (începe tranzacția, documentul nu a fost încă scris);
Modul formular (&AtServer) - la scrierea pe server (comiterea unei tranzacții);

Modul formular (&OnClient) - înainte de înregistrare;
Modul formular (&AtServer) - procesarea verificării de umplere pe server;
Modul obiect - procesarea verificării umplerii;
Modul formular (&AtServer) - înainte de înregistrarea pe server;
Modul obiect - înainte de scriere (începerea unei tranzacții, documentul nu a fost încă scris);
Modul obiect - la scriere (documentul este scris);
Modul obiect - procesare postare (formarea unui set de înregistrări ale mișcărilor documentelor);
Modul formular (&AtServer) - la înregistrarea pe server (se înregistrează un set de înregistrări ale mișcării documentelor, se comite tranzacția);
Modul formular (&AtServer) - după înregistrarea pe server;
Modul formular (&OnClient) - după înregistrare.

Action Run

Acțiune Post și Închidere

Secvența de execuție a evenimentelor este similară cu acțiunea de conduită (vezi Figura 2).

Anularea acțiunii

Această acțiune inițiază scrierea unui document și declanșează următoarea secvență de evenimente:

Modul formular (&OnClient) - înainte de înregistrare;
Modul formular (&AtServer) - înainte de înregistrarea pe server;
Modul obiect - înainte de scriere (începerea tranzacției);
Modul obiect - gestionarea înlăturării conduitei (ștergerea mișcărilor);
Modul obiect - în timpul înregistrării (mișcări eliminate, document înregistrat);
Modul formular (&AtServer) - după înregistrarea pe server (comiterea unei tranzacții);
Modul formular (&OnClient) - după înregistrare.

Dacă acțiunile nu sunt executate din formular (efectuate programatic), diferența este că evenimentele din formular nu sunt executate!

Poate fi dificil pentru un programator care are puțină experiență pe platforma 1C 8.2 să-și dea seama: înainte de înregistrare, la înregistrare, după înregistrare, pe server, pe client, în modulul formular, în modulul obiect, ah-ah -ah-ah-ahhh!!.....
A fost un sentiment atât de complex de neînțelegere pe care l-am avut la început. În procesul de învățare și experiență reală, a fost creată această foaie de cheat, al cărei scop a fost să „sorteze lucrurile”, astfel încât să existe o înțelegere clară a ce handler ar trebui utilizat, în ce caz și în ce secvență sunt lansate atunci când obiecte de scriere.

De ce avem nevoie chiar de acești manipulatori?
Foarte des, un programator trebuie să redefinească comportamentul standard al sistemului în timpul înregistrării obiectelor, și anume: să anuleze înregistrarea, în cazul unor condiții; solicitați informații suplimentare de la utilizator; completați detaliile; scrieți altceva în baza de date pe baza acestei înregistrări; schimba ceva de pe formular după înregistrare etc. și așa mai departe. Fiecare programator se confruntă mai devreme sau mai târziu cu sarcini similare, prin urmare, un programator care lucrează pe platforma 1C 8.2 trebuie să cunoască scopul și secvența lansării acestor evenimente.

În modulul formular sau în modulul obiect?
Mai întâi trebuie să decidem dacă avem nevoie de date de formular? Înregistrarea va fi scrisă programatic sau doar interactiv? Vom avea un dialog cu utilizatorul?
Cert este că unele dintre evenimente sunt executate la nivelul modulului de formular, ceea ce înseamnă că sunt executate doar în timpul înregistrării interactive, iar în aceste evenimente putem accesa datele formularului și putem conduce un dialog cu utilizatorul.
Cealaltă parte a evenimentelor se realizează la nivelul modulului obiect, atât interactiv, cât și programatic.
Prin urmare, putem decide imediat asupra handlerului modulului formular sau al modulului obiect, vom lucra.

Modul formular: client sau server?
În plus, dacă modulul de formular este selectat, atunci este necesar să decideți care handler este necesar: executabil pe client sau executabil pe server. Dacă este necesar un dialog cu utilizatorul, atunci pe client, în caz contrar pe server. Ele pot fi distinse după numele directivei de compilare sau după numele handler-ului (când se află pe server, acesta este scris în nume, cum ar fi BeforeWriteOnServer()).

Cum să alegi un anumit handler?
Alegerea depinde de sarcina la îndemână. Ce se poate face exact în fiecare handler va fi descris mai jos, dar deocamdată un exemplu.

Un exemplu de selectare a handlerelor de evenimente de înregistrare a obiectelor:
Există sarcini când trebuie să utilizați mai mulți handlere pentru a rezolva o singură sarcină. De exemplu, trebuie să solicitați informații de la utilizator în timpul înregistrării: „Vom crea un nou document pe baza acestei înregistrări?” și, dacă utilizatorul răspunde afirmativ, atunci trebuie creat un nou document cu un link către obiectul care este scris. Mai mult, înregistrarea unui nou document trebuie efectuată într-o tranzacție, deoarece. dacă înregistrarea curentă este anulată dintr-un motiv oarecare, atunci documentul deja creat și înregistrat nu ar trebui să rămână în baza de date.
Pentru a îndeplini această sarcină, va trebui să utilizați handlere de evenimente din modulul formular din două motive:
1) Dialogul cu utilizatorul este posibil doar pe client, iar managerii de client sunt disponibili doar în modulul formular. Pentru dialog, vom folosi procedura client a modulului de formular BeforeWrite() și vom stoca răspunsul utilizatorului în parametrul „RecordParameters” al acestei proceduri.
2) Și în procedura OnWriteOnServer() a modulului formular, vom accepta acest parametru și, în funcție de el, vom crea sau nu un document. De ce această procedură specială? Legătura va fi obținută numai după scriere, dar din moment ce trebuie să scriem într-o tranzacție, trebuie să folosim proceduri ÎNAINTE ca tranzacția să fie finalizată, dar având deja un link către obiectul care este scris. BeforeWrite() nu funcționează pentru că nu există încă nicio referință, iar AfterWrite() nu funcționează deoarece tranzacția este deja comisă. Rămâne pe Write(), dar ne confruntăm cu o alegere: un modul formular sau un modul obiect? Deoarece handlerul de evenimente OnWrite() al modulului obiect nu conține un parametru care să conțină răspunsul utilizatorului, dar evenimentul OnWriteOnServer() al modulului formular, răspunsul este evident - folosim acest eveniment OnWriteOnServer() al modulului formular deoarece :
1) Acest eveniment este executat într-o tranzacție 2) Conține parametrul RecordParameters, care conține deja răspunsul utilizatorului, care a fost transmis din procedura BeforeWrite() 3) Link-ul a fost deja creat și puteți crea un nou document folosind acest link .

Ei bine, acum succesiunea evenimentelor de declanșare (în ordinea în care sunt listate) și mici detalii:
Mulți operatori au opțiunea Respingere. Acolo unde acest parametru este prezent, înseamnă că este încă posibil să refuzi înregistrarea în acest handler setând parametrul „Refuz” la True, iar apoi înregistrarea nu va fi făcută.
1) Modulul formular BeforeRecord (Rejectare, RecordParameters)
Funcționează pe client!
Acest handler ar trebui folosit dacă este necesar să se stabilească un dialog cu utilizatorul înainte de a scrie obiectul. Solicitați informații suplimentare, avertizați despre ceva, oferiți posibilitatea de a refuza etc.
Al doilea parametru al acestui handler „RecordParameters” este de tip „Structure”. Pentru documente, acești parametri sunt completați de sistem cu parametri predefiniti Mod înregistrare, Mod postare. Îți poți adăuga pe al tău.
Acești parametri sunt trecuți între evenimente de forma BeforeWriteOnServer, OnWriteOnServer, AfterWriteOnServer, unde pot fi utilizați în siguranță. De exemplu, atunci când scrieți un registru de informații, trebuie să scrieți într-un alt registru de informații vechea valoare a resursei. Puteți trece vechea valoare acestor aceiași parametri și deja în OnWriteAtServer, scrieți într-un alt registru.
2) Modulul formular ProcessingFillingChecksOnServer (Eșec, CheckedDetails)
3) Modulul obiectului ProcessingCheckFilling (Rejection, CheckedDetails)
Acești doi manipulatori de verificare a umplerii sunt implementați prin intermediul parametrului Atribute verificate de tipul Array care conține detaliile care trebuie verificate (adică, care au proprietatea Verificare umplere setată la Throw an Error)
Și dacă atributul este eliminat din această matrice, atunci nu va fi verificat, dacă este adăugat, atunci umplerea va fi verificată.
Astfel, putem spune că acești doi handlere de evenimente sunt destinate:
Pentru a include în completare verifica acele detalii care au „Nu verifica” în proprietățile „Fill Check”. Pentru a face acest lucru, trebuie să adăugați acest atribut la parametrul de matrice „CheckedAttributes”
Pentru a exclude din verificarea automată cerințele care au proprietatea „Dă eroare” a verificării de umplere, în funcție de anumite condiții. Pentru a face acest lucru, trebuie să eliminați acest atribut din matricea parametrului „Atribute verificate”.
Există mai multe caracteristici de luat în considerare:
Dacă formularul din care este scris obiectul nu are setat „Verificarea umplerii automate” în proprietățile sale, atunci acești manipulatori de verificare de umplere nu sunt apelați și verificările nu au loc!
Apelat doar pentru înregistrare interactivă! Ele nu sunt apelate în timpul înregistrării programului. Pentru a verifica, trebuie să utilizați metoda CheckFill() a obiectului, care declanșează lansarea acestor evenimente.
Pentru documentele care pot fi postate, aceste evenimente de verificare completă sunt ridicate doar atunci când sunt postate!
Ambele evenimente sunt executate pe server, diferența este că FillCheckHandlingOnServer() este un eveniment al modulului formular și, prin urmare, există acces la datele formularului. Iar ProcessingFillCheck() este un eveniment al modulului obiect.
4) Modulul formular BeforeWriteOnServer (Rejection, CurrentObject, RecordParameters)
În acest handler, puteți completa detaliile obiectului sau puteți efectua verificări suplimentare. Există acces la datele formularului. Există un parametru CurrentObject.
Parametrul CurrentObject are tipul de clasă „obiect” în funcție de tipul obiectului care este scris (CatalogObject, DocumentObject etc.). Acestea. a fost creată o instanță a clasei de obiecte și puteți accesa proprietățile și metodele acesteia, dar nu a fost încă scrisă în baza de date.
Începutul tranzacției
5) Modulul obiect BeforeWrite (Eșec)
În acest handler, puteți completa detaliile obiectului sau puteți efectua verificări suplimentare.
Pentru documente, la parametrii acestui handler se adaugă încă doi parametri: Mod înregistrare, Mod postare.
Înregistrare
6) Modul obiect WhenSettingNewNumber(StandardProcessing, Prefix)
Apare atunci când este setat numărul unui nou document, sarcină sau proces de afaceri.
Sau când setați codul nou (procesare standard, prefix)
Apare în momentul în care este setat un nou cod al unui element de director, un nod de plan de schimb sau un cod de plan de tipuri de caracteristici.
Aceste evenimente sunt apelate pentru obiectele care au proprietatea „Autonumber” specificată și numai pentru obiectele noi.
Dacă setați parametrul StandardProcessing la Fals, atunci un număr nou nu va fi generat și puteți seta codul obiect în mod programatic în acest handler.
7) Modul obiect la scriere (respingere)
Apelat după ce obiectul este scris în baza de date, dar înainte ca tranzacția de scriere să se încheie.
Link-ul este deja acolo și puteți scrie date suplimentare în baza de date pe baza obiectului curent folosind acest link.
De exemplu, atunci când înregistrați, creați un alt document care conține linkul necesar către documentul care este înregistrat.
8) Modulul formular OnWriteAtServer (Rejection, CurrentObject, RecordParameters)
Apelat după ce obiectul este scris în baza de date, dar înainte ca tranzacția de scriere să se încheie. Există acces la datele formularului. Există o ultimă șansă de a vă dezabona.
Parametrul CurrentObject are tipul de clasă „obiect” în funcție de tipul obiectului care este scris (CatalogObject, DocumentObject etc.). Vă puteți referi la proprietățile și metodele sale.
Sfârșitul tranzacției
9) Modulul formular AfterRecordOnServer (CurrentObject, RecordParameters)
Se rulează pe server.
Poate fi folosit pentru a afișa vizual ceva pe formular.
10) Modulul formular AfterRecord(RecordParameters)
Funcționează pe client!
Poate fi folosit pentru a afișa vizual ceva pe un formular sau pentru a emite un avertisment utilizatorului.

Atenţie! Iată o versiune de probă a lecției, ale cărei materiale ar putea să nu fie complete.

Conectați-vă ca student

Conectați-vă ca student pentru a accesa conținutul școlii

Crearea configurațiilor 1C: adăugarea procesării

Continuăm să studiem elementele de bază ale creării configurațiilor pe 1C.

În această lecție, vom crea împreună o nouă procesare și apoi vom scrie comenzi pentru aceasta care demonstrează cum să lucrăm cu directorul „Angajați”.

Ne întoarcem la configurator și deschidem arborele de configurare.

Adăugarea de noi procesări

Faceți clic dreapta pe secțiunea „Procesare” și selectați „Adăugați”:

Se deschide o fereastră pentru crearea unei noi procesări. Să mergem la fila „De bază” și să specificăm „Procesarea referințelor” ca nume de procesare:

Creați un formular de procesare

Să mergem la fila „Formulare” și să facem clic pe semnul verde plus pentru a adăuga o nouă formă (o reprezentare vizuală a procesării noastre):

A apărut constructorul de formulare. Lăsați totul ca implicit și faceți clic pe „Finish”:

S-a deschis un nou formular:

Creați o nouă comandă pentru formular

Să mergem la fila „Comenzi”-> „Comenzi de formular”:

Să adăugăm o nouă comandă (semnul verde plus):

Și în proprietățile noii comenzi, specificați numele „OutputAllEmployees”:

În proprietățile sale, faceți clic pe lupa de lângă câmpul „Acțiune” pentru a seta gestionarea comenzilor. Să alegem opțiunea de a crea handler-ul „Pe client” și să facem clic pe „OK”:

Am fost transferați la modulul de formular în handlerul de procedură al comenzii „OutputAllEmployees”:

Scrierea codului de gestionare a comenzii

Acum sarcina noastră este să scriem cod în limbajul intern al 1C, care va repeta peste toate elementele directorului „Angajați”.

Vreau să spun imediat că acest cod nu poate fi scris direct în procedura „OutputAllEmployees”, întrucât se execută pe client (atenție la linia specială dinaintea procedurii „&AtClient”). Încercarea de a citi date din baza de date într-o procedură client va avea întotdeauna ca rezultat o eroare (doar țineți minte asta pentru moment).

Deci, să adăugăm o procedură ca aceasta la sfârșitul modulului:

Vă rugăm să rețineți că înainte am indicat semnul „&AtServer”. Aceasta înseamnă că va fi executat pe server, ceea ce înseamnă că putem citi datele directorului de pe acesta.

Acum organizăm un apel la această procedură de la clientul „OutputAllEmployees”:

Aici logica este aceasta:

Utilizatorul apelează comanda „DisplayAllEmployees” (de exemplu, făcând clic pe un buton, pe care nu îl avem încă)
Comanda lansează procedura de gestionare „OutputAllEmployees” cu același nume pe client (la urma urmei, butonul și, prin urmare, comanda, sunt localizate pe client)
Procedura client „OutputAllEmployees” efectuează un apel către procedura de server „OutputAllEmployeesOnServer”
Procedura de server „OutputAll EmployeesOn the Server” citește datele directorului din baza de date și le afișează în fereastra de mesaje

Singurul lucru care ne mai rămâne este să scriem codul procedurii „OutputAll EmployeesOn the Server”, care rulează prin elementele directorului „Angajați” și le afișează în fereastra de mesaje.

Este foarte ușor. Ocolirea tuturor directoarelor din 1C este aceeași. Deci, după ce ați învățat cum să faceți acest lucru acum cu directorul „Angajați”, puteți face același lucru cu orice alte directoare.

Pentru a accesa datele directorului, se folosește un manager, care este accesat după cum urmează:

Manager = Directoare. Angajații;

În această propoziție, partea cheie este în dreapta semnului egal. În stânga este doar o variabilă în care salvăm managerul pentru a lucra mai departe cu ea. Numele acestei variabile ar putea fi nu numai „Manager”, ci și orice altul - chiar și „Miel”.

Ce este un director de director? Managerul nu este încă datele directorului în sine. Un manager este un obiect de program (puteți gândi la el ca o cutie neagră) prin care putem face ceva cu directorul.

Managerul de director este, parcă, un astfel de strat între codul nostru și datele directorului. Și se dovedește că, dacă trebuie să citim toate elementele directorului, atunci nu putem face acest lucru direct. Putem cere asta doar stratului nostru dintre noi și director, adică manager.

Pentru a face acest lucru, trebuie să apelați metoda „Select” încorporată în manager. Este apelat printr-un punct după numele variabilei în care este stocat managerul și returnează o colecție de elemente de director:

Manager = Directoare. Angajații; Sample = Manager. Alegeți() ;

Ce este o mostră? Selecția (din nou, acesta este doar numele variabilei în care salvăm rezultatul metodei „Select”, și ar putea fi orice altceva) este o colecție, dar nu ca o matrice sau o listă de valori, de exemplu .

Eșantionul este un obiect - din nou, gândiți-vă la el ca la o cutie, nu la datele în sine. Particularitatea acestui obiect este că poate itera elementele directorului de care avem nevoie. Și le sortează dinamic. Aceasta înseamnă că utilizarea unei selecții nu citește toate elementele directorului deodată, ci le selectează în porțiuni din baza de date.

Această abordare vă permite să ocoliți rapid liste mari de directoare folosind o selecție, fără a le încărca pe toate odată în memoria computerului.

Pentru a obține următoarea porțiune de date din selecție, trebuie să apelați metoda „Următorul” încorporată în ea. Recepția porțiunilor de date (o porțiune corespunde unui element al directorului) are loc de obicei într-o buclă:

Când datele (elementele directorului) din selecție se termină, metoda „Next” va returna False și bucla se va opri.

După fiecare apel la metoda „Următorul” (cu condiția ca aceasta să returneze „Adevărat”), selecția va conține toate câmpurile cu date doar ale elementului citit din dicționar, care pot fi accesate prin nume separate printr-un punct:

Se dovedește la un moment dat - lucrăm cu datele doar unuia dintre elementele directorului. Și aici fie le putem afișa imediat utilizatorului (folosind metoda „Report”), fie, de exemplu, le putem adăuga la o altă colecție (matrice), pentru ca ulterior să putem face ceva cu ele la un moment dat. Totul depinde de sarcina pe care o rezolvăm.