V8 Technique for Overriding and Calling Form Event Handlers, Knowledge Book

Cuvinte cheie: handler, apel, eveniment, formular, actualizare, redefinire, tipic, înlocuire

De exemplu, există o configurație care este un standard modificat. Îl actualizați în mod constant și adăugați din ce în ce mai multe modificări. În cazul general, actualizarea devine mai dificilă și mai lungă de fiecare dată. O parte semnificativă a personalizării dvs. este inserarea la începutul și la sfârșitul handlerelor de evenimente ale formularului. La fel și noi handlere, pe care unii îi atribuie și în modul de editare a configurației (static), ceea ce complică și mai mult procesul de actualizare.

Metoda sugerată este să vă declarați propriii handlere de evenimente în modulul formular, care va apela vechii handlere și va executa codul necesar înainte și după acest apel. Setarea de noi handlere se va face în secțiunea principală a programului din modulul formular apelând o procedură generică, spuneți „SetFormAction”. Această procedură pe un element de formular invizibil adăugat dinamic va păstra toți gestionatorii vechi pentru fiecare eveniment suprascris, făcând destul de ușor apelarea lor printr-o funcție generică, spune „GetOldFormAction”. Urmând recomandările din 1C și, de asemenea, pentru comoditate, să luăm regula: numele noilor handler ar trebui să fie formate ca [ ][ . ][ ] și parametrii pentru a le numi standard. Subelementele sunt elemente din cadrul elementelor de formular. Indicii subelementelor indică nivelul de imbricare.

Cazul 1. Adăugăm o inserare la începutul și la sfârșitul handlerelor de evenimente de formular disponibile în formularul standard.

De obicei o fac așa.

Totul funcționează și arată bine. Cu toate acestea, după actualizare, trebuie să adăugăm manual acest lucru la noua versiune a handler-ului dacă s-a schimbat în raport cu versiunea veche.

Acum ar trebui să faci asta.

Astfel, la actualizare, în general, va trebui să adăugăm doar un bloc la secțiunea de instrucțiuni a programului principal. Strict vorbind, acest bloc ar trebui plasat chiar la sfârșitul acestei secțiuni, deoarece poate conține atribuiri concomitente de gestionare. Cu toate acestea, acest lucru este extrem de rar în configurațiile tipice. O alternativă este să mutați setarea tuturor gestionanților, cu excepțiaBeforeOpen, la un nou handlerBeforeOpen. Deoarece secțiunea din programul principal a modulului de formular nu se schimbă aproape niciodată, pur și simplu vom debifa caseta de selectare pentru aceasta în setarea de îmbinare, ceea ce va exclude complet editarea manuală a modulului de formular după actualizare.

Cazul 2: Adăugarea unui nou handler de evenimente element de formular.

De obicei o fac așa.

Ce ar trebui făcut în acest caz? Din nou în același mod.

Acum nu ne temem de responsabilul acestui eveniment adăugat într-una dintre lansările viitoare și de numele său! De îndată ce apare, handlerul nostru îl va suna acolo unde ne-am înregistrat.

Separat, aș dori să menționez noile elemente de formular. Dacă ați adăugat elementul în formular și doriți să creați un handler de evenimente pentru acesta, atunci este logic să faceți același lucru în acest caz. Într-adevăr, în noua versiune pot adăuga un element de formular cu același scop funcțional. Dacă are același nume cu al tău, atunci nici măcar nu va trebui să schimbi nimic după actualizare. Și dacă numele este diferit, atunci trebuie doar să corectați numele handler-ului și parametrul din apel pentru a-l instala.

Proceduri și funcții necesare ale modulului comun

În primul rând, procedura de redefinire a evenimentului. Pentru a stoca gestionatorii de evenimente vechi, folosim un truc sugerat deGenius 1CBook of Knowledge: v8: Unde să stocați în formulardate intermediare? Esența sa este de a adăuga dinamic zero dimensiuni la elementul de serviciu al formularului pentru a stoca lista de valori în acesta în proprietateaSelectionList. Acestea. Mai întâi, verificăm dacă există un element de formular cu numele dat (în exemplul „pOldHandlers”). Dacă nu există, atunci o creăm. Apoi obținem handlerul pentru acțiunea de formular sau elementul de formular dorit. Îl salvăm în proprietateaSelectionLista elementului de serviciu al formularului. Instalăm un nou handler, al cărui nume este format conform regulii noastre [ + ] [ + . + ] [ + ]. Parametrul „pLiExclusive” este responsabil pentru verificarea prezenței vechiului handler. O astfel de verificare poate fi necesară pentru a atribui handleri care nu apelează vechiul handler (de exemplu,SelectionStart). Parametrul „pFormElementAlias” ne permite să atribuim același handler mai multor evenimente de același tip prin specificarea aceluiași alias la setarea handler-ului.

Acum o funcție pentru obținerea unei expresii în limbajul 1C, care poate fi executată în modulul formular pentru a lansa vechiul handler și a-i transmite parametrii necesari. Dacă vechiul handler nu a fost atribuit evenimentului, funcția va returna un șir gol. În primul rând, există o funcție de ajutor pentru obținerea unui șir de argumente.

Acum o funcție pentru obținerea unei expresii în limbajul 1C, care poate fi executată în modulul formular pentru a lansa handlerul propriu-zis și a-i transmite parametrii necesari. Dacă niciun handler real nu a fost atribuit evenimentului, funcția va returna un șir gol.

Ei bine, funcții auxiliare pentru analizarea (parsarea) unui șir și obținerea tipului unei legături.

Cum să apelați programatic un handler de evenimente al unui formular din modulul său fără a fi legat de numele handler-ului?

În acest caz, funcția LxGetFormAction() ne va ajuta, ceea cereturnează textul pentru a apela handlerul de evenimente. Înainte de a executa apelul în sine, este necesar să inițializați parametrii handler-ului.

Un exemplu de apelare a evenimentuluiChoiceStart​​pentru elementul de formular numit „Depozit”:

Cum să apelați programatic un handler de evenimente de formular din orice modul fără a fi legat de numele handler-ului?

Pentru acest truc, în modulul formular, desigur, va trebui să plasați o metodă care execută cod arbitrar prin metodaRun:

Inițializarea parametrilor de gestionare a evenimentelor trebuie desigur plasată în parametrul „Expresie”.

Un exemplu de apelare a handler-ului de evenimenteChoiceStart​​pentru elementul de formular numit „Depozit”:

Pentru a facilita crearea de noi handlere, este înțelept să scrieți un șablon generic. Aici e al meu:

De asemenea, puteți scrie șabloane private pentru a accelera și mai mult dezvoltarea. Atunci nici măcar nu trebuie să căutați/rețineți șirul de parametri standard al gestionarului de evenimente.

De exemplu, un șablon pentru handlerul de evenimenteOnChange:

Și iată șablonul pentru handler-ul de evenimente pentru buton:

Am aplicat cu succes această tehnică în practică. S-au implementat handlere unificate pentru același tip de evenimente de formular, ceea ce vă permite să nu fiți legat de numele elementului de formular. Multe tipuri de evenimente sunt procesate aproape global, menținând în același timp apelul celor de tip și prezența unor noi handler-uri.

Cred că tehnica descrisă merită o implementare a platformei.

---