Nuanțele generatorului de setări. Selecții în rapoarte. Nuanțe ale modului în care funcționează generatorul de setări Setați setările standard pentru formularul gestionat 1c

Cred că nu este nevoie să vă spun ce este un sistem de control al accesului, un compozitor de setări și, în general, întregul set de obiecte concepute pentru a funcționa cu un sistem de control al accesului. Principalele domenii de utilizare, fără a număra acțiunile complicate din cod, sunt listele și rapoartele dinamice, iar în ambele cazuri, funcționalitatea foarte semnificativă rămâne în culise. De multe ori nici nu ne gândim la logica comportamentului și a relațiilor tuturor participanților la proces, deoarece De obicei rezolvăm probleme destul de simple sau ne bazăm pe valorile implicite ale platformei. Dar acolo unde sunt tăceri, există și o logică internă, un fel de „deserviciu” al lui 1C, ale cărui fructe sunt uneori greu și neevidente de depășit pentru a obține efectul dorit și, în același timp, este suficient doar pentru a utiliza instrumentele corect.

Cei interesați pot sări peste părțile 1-4 și să meargă direct la exemple.

Voi încerca să mă opresc puțin mai în detaliu asupra funcționării selecțiilor ACS în cazul utilizării lor în rapoarte. Cred că comportamentul în listele dinamice, cu o serie de avertismente, va fi similar. Deci, selecții în rapoarte, puțină teorie și apoi exemple concrete.

SP 8.3.6 și mai sus, se utilizează secțiuni ale ITS (clauza 10.3.7.5 etc.), cartea „Dezvoltarea profesională în sistemul 1C-Enterprise 8” (Kazan, 2012, al doilea volum). În cartea lui E. Khrustaleva nu era nimic inteligibil pe această temă.

Partea 1

Generatorul de setări, după cum știți, are colecții „Setări”, „Setări fixe” (denumite în continuare „FN”) și „Setări personalizate” (denumite în continuare „CU”). Un raport poate avea mai multe opțiuni, iar conexiunile dintre opțiune, N, PN și FN sunt foarte unice. De asemenea, să nu uităm de sursa setărilor disponibile și de „progenitorul” acestuia, care este de obicei circuitul însuși, care are și propriile setări implicite.

* Setări – setări create în modul Configurator și modificate în modul de editare a versiunii de raport;

* UserSettings – setări pe care utilizatorul le modifică în modul „1C:Enterprise” doar prin interfață;

* FixedSettings – acele setări care sunt setate din limba încorporată, inclusiv. sunt implicit stabilite de sistem. Această proprietate conține valori de selecție care sunt transferate în formular folosind parametrii acestuia (structura „Selectare”).

Setările și FN-urile sunt similare ca design și au o colecție „Selectare” de tip „Selectare compoziție date”, disponibilă pentru modificarea compoziției în orice moment în timpul existenței raportului. În același timp, Setările sunt disponibile pentru modificări de interfață prin editarea unei variante, dar FN-urile nu sunt deloc accesibile. PN, la rândul său, este un „terci”, în care elementele egale pot fi atât „Selectia” în sine, cât și obiectele individuale de tipul „Element de selecție a compoziției datelor” (așa-numitul obiect imbricat). În ciuda disponibilității metodelor adecvate, este imposibil să se schimbe programatic compoziția unei colecții de elemente PN dacă acestea sunt PN-uri ale raportului în sine și nu sunt făcute „de la zero” de către proiectant - 1C va raporta că „Colecția setari personalizate nu își poate schimba compoziția, deoarece este legată de setările de compoziție a datelor." ITS spune: „Proprietatea nu poate fi scrisă folosind limbajul încorporat”, dar, așa cum vom vedea mai târziu, este posibil să influențezi PN. „Triciul” de obiecte are conexiuni interne - este verificat pentru consistența condițiilor atunci când se generează un raport și când se modifică compoziția. Pe ITS citim: „Elementele care sunt ele însele marcate ca personalizate nu vor fi adăugate. De exemplu, o selecție personalizată nu va include un element de selecție care este marcat ca personalizat. Elemente care conțin elemente personalizate. De exemplu, un grup de condiții nu va fi adăugat dacă grupul conține elemente marcate ca personalizate. Pentru elementele imbricate, proprietatea DisplayMode nu este analizată. Sunt adăugate sau nu împreună cu elementele părinte.” Astfel, „vechimea” obiectelor operează în culise. În acest caz, puteți obține un efect atunci când interfața vă permite să specificați selecții contradictorii pentru o variantă și PN-ul acesteia, precum și în cadrul PN-ului.

S-ar părea că „senior” este o opțiune. Dar făcând clic pe „Mai multe” / „Modificare opțiunea” și confirmarea modificărilor în formularul deschis apelează gestionarea evenimentelor formularului , în acest caz, selecția apare în panoul „De bază” pe formularul numit din „Setări...”, și apare pe formularul de raport, dar NU este afișată în fila „Selectare”; Mai mult, fie apare imediat atât pe formularul principal de raportare, cât și pe formularul „Setări...” (dacă există un steag „Includeți în setările utilizatorului”), fie nici acolo, nici acolo. Dar, în orice caz, NU va fi în fila „Selectare” din formularul „Setări...”. Diferența dintre fila „De bază”, formularul „Setări...” și formularul principal de raport este determinată de câmpul „Modul de editare” (normal - doar în „Setări”, rapid - tot pe formularul de raport în sine), dar cred că toată lumea știe asta. Apropo, valorile „Selectare” și „Rapid” nu sunt sincronizate în niciun fel și se pot contrazice, dar „Rapid” din formularul de raport și din formularul de setări sunt strict sincrone. Deci, atunci când editați o variantă, ea însăși devine schimbată (dar ID-ul și numele ei nu se schimbă), dar PN-urile rămân NU modificate (adică, chiar dacă vorbim despre ele, adică despre steag pentru includerea cutare sau cutare). element din PN ).

Făcând clic pe „Selectați opțiunea...” și confirmarea modificărilor în formularul care se deschide, declanșează evenimente în următoarea ordine:

Când încărcați OptionOn Server

Când actualizați compoziția setărilor utilizatorului pe server

În acest caz, nici opțiunea și nici PN-ul nu se modifică în niciun fel. De aici este clar că opțiunea și setările, dacă sunt conectate, nu sunt în niciun caz conectate direct.

Făcând clic pe „Setări...” și confirmarea modificărilor din formularul deschis, declanșează doar un eveniment Când actualizați compoziția setărilor utilizatorului pe server(în acest caz, PN-urile devin modificate, dar vederile și cheia (dacă nu erau acolo) nu sunt primite; dacă „Fast” este activat pentru elementele obiectului „Selectare” al PN-ului, atunci pe lângă „Selectare”, elementele sale reale apar ca câmpuri, adică se comportă în mod similar cu elementele imbricate. Aceste setări sunt salvate la închidere și restabilite data viitoare când introduceți formularul. Nu atinge și nu modifică opțiunea.

Faceți clic pe „Mai multe”/„Instalare” setări standard„ în formularul de setări (precum și elementul „Setări standard” din opțiunea de editare) declanșează doar evenimentul Când actualizați compoziția setărilor utilizatorului pe server. În acest caz, opțiunea devine schimbată, dar PN se schimbă. Dacă opțiunea a fost schimbată înainte, aceasta rămâne modificată (nici steagul modificat nu este resetat, nici setările reale nu sunt resetate).

Făcând clic pe „Proprietăți ale unui element de setări personalizate” în arborele de structură din formularul de editare a variantei, se adaugă un obiect „Selectare” și acesta se dovedește gol și nu este sincronizat în niciun fel cu selecția de variante existentă și cu elementele de selecție imbricate existente. varianta nu se schimba in niciun fel.

De aici recomandarea: dacă trebuie să setați anumite selecții în modul „Configurator”, pentru a nu modifica codul și pentru ca acestea să nu fie în opțiune, ci să fie în interfața de raport, nu trebuie să manipulați selecția elemente ale opțiunii, modificându-și proprietățile, dar selecția în sine, folosind butoanele „Proprietăți element...” și „Setări personalizate”.

Adăugarea a ceva care apare în Setări la PN necesită acțiuni în cod sau interfață, dar ștergerea și ștergerea Setărilor afectează PN imediat și fără actualizări, de exemplu:

Report.SettingsLitter.Settings.Selection.Items.Clear();

Înainte de a închide formularul de raportare, sistemul întreabă doar dacă au existat modificări ale variantei. Dacă au existat modificări la PN, acestea vor fi salvate automat, fără întrebări și, de asemenea, vor încerca automat să fie aplicate în următoarea sesiune de lucru cu raportul.

Note:

În cazul unui număr de erori în aplicarea setărilor, este afișat mai întâi un mesaj despre problemă, iar apoi compoziția are loc în continuare, evenimentul este numit și generarea de rapoarte. În acest caz, FN-urile, chiar dacă au existat, sunt încă ignorate și doar Setările joacă un rol.

La adăugarea unei selecții pe formularul „Modificare opțiune”, se face imediat cu steag „Include în PN” setat, dar, repet, din punctul de vedere al limbajului încorporat, PN rămâne neschimbat.

Setarea variației unei variante și setarea variației PN nu sunt direct legate; acestea sunt două direcții diferite de schimbare.

PN, printre altele, are „Setări suplimentare”. Nu am reușit niciodată să înțeleg ce și în ce moment sunt umplute. Deși raportul conține setări „marcate în designul de selecție și condițional” ca personalizate (în conformitate cu societatea în comun), dar setari aditionaleîn toate cazurile erau goale. Nu există nimic despre asta pe ITS.

În ciuda declarației din joint venture, PN-urile sunt serializate perfect în xml.

Dacă atât elementele de selecție independente, cât și selecția în sine sunt incluse pentru utilizare, atunci raportul este compilat corect, dar atunci când este afișat, acesta duplică informațiile despre selecția stabilită în aspectul final.

Formularul implicit pentru editarea unei versiuni de raport conține multe lucruri interesante, dar nicăieri nu funcționează cu FN și PN și chiar și cu setările de bază funcționează mai mult pentru citire (cu excepția faptului că șterge selecția, ordinea, convențiile).

Partea 2

Lucrul cu Setări și FN prin colecția lor este aproape întotdeauna acceptabil, dar este important să ne amintim că esența „al treilea nivel” se schimbă. Primul nivel conține întotdeauna setările implicite ale sistemului de control acces propriu-zis, ele apar implicit și în sursa setărilor disponibile; la al doilea nivel – setările opțiunii utilizate. Dar aici logica vă permite fie să „suprascrieți” instrucțiunile de bază, fie să le ignorați. Dar lucrul cu PN nu mai permite libertăți, iar manipulările subtile trebuie făcute folosind metode speciale și uneori obiecte intermediare auxiliare temporare, de exemplu:

Comp=NewDataCompositionSettingsComposer; // puteți, de asemenea, să porniți // comp.Initialize(SomeSettingsComposer.GetSourceofAvailableSettings()); comp.LoadSettings(SomeSettingsComposer.Settings); SomeSettingsComposer.LoadCustomSettings(comp.CustomSettings);

Generatorul de setări are o metodă (), care încarcă valorile setărilor utilizatorului transmise ca parametru metodei. Metodă GetSettings() vă permite să obțineți o copie a setărilor curente (ținând cont de setările utilizatorului). Metodă DescărcareSetări() încarcă setările transmise în generatorul de setări (setările utilizatorului sunt de asemenea repopulate pe baza datelor transmise, ținând cont de prezența cheilor, vezi exemplul de mai jos).

Aplicarea setărilor personalizate la setările principale se face în metodă GetSettings() generator de setări. Se efectuează următoarele acțiuni:

* Pentru tipurile DataCompositionSelectionElement, conținutul elementelor este copiat în elementele de setări personalizate corespunzătoare.

* Pentru tipurile de selecție a aspectului datelor, elementele situate în setările principale și marcate ca Inaccesibile rămân neschimbate. Elementele din PN sunt transferate la cele principale. Ele sunt adăugate la sfârșitul colecției pentru selecție.

* Pentru tipurile DataCompositionSelectionElementGroup, proprietatea Utilizare este setată în elementul corespunzător al setărilor principale (pe baza semnului utilizării elementului PN).

Partea 3

La formarea setărilor finale, pentru a cita ITS, diferite setări sunt combinate după cum urmează:

* Dacă orice tip de setări este marcat în întregime ca personalizat, atunci setările rezultate includ PN. În acest caz, dacă elementele de setări sunt marcate ca indisponibile, atunci aceste setări vor fi plasate în setările rezultate din proprietatea Settings Composer.Settings.

* Dacă orice tip de setări este marcat ca personalizat nu în întregime, ci element cu element, atunci elementele marcate ca personalizate vor fi preluate în setările rezultate din proprietatea Settings Composer.CustomSettings, iar elementele marcate ca indisponibile vor fi preluate în setările rezultate din Settings Composer.Settings property .

* Setările fixe sunt adăugate la setările rezultate „ca atare”. În acest caz, situația este inacceptabilă când FN și PN au setări cu același nume, de exemplu, selecție cu aceeași valoare stângă în condiție. Observ că chiar și coincidența completă a tuturor proprietăților acestor condiții este interzisă. Sincer să fiu, este puțin ilogic.

Aș dori să remarc faptul că, dacă orice fragment al setărilor este supus unei opțiuni funcționale și ar trebui limitat, sistemul funcționează „liniștit” - elimină acest fragment de peste tot, nu raportează nimic și în timpul manipulărilor programului cu privire la un astfel de fragment , prelucrează erori „inactiv” nu produce, dar nici codul nu are efect. Cu toate acestea, este posibil ca diferite versiuni să se comporte diferit.

Partea 4.

Extensia formularului de raportare ne pune la dispoziție parametrii „FN” și „PN”, dar nicăieri nu se recomandă completarea lor direct prin trecerea lor în formular. După cum au arătat experimentele, fără dansuri suplimentare cu o tamburină, conținutul acestor parametri este ignorat - este suprascris atunci când linkerul este inițializat în timpul procesului de deschidere și când sunt primite PN-uri salvate anterior. Este recomandat să lucrați cu chei PN, prin care le puteți prelua din magazinul de setări și apoi le puteți deschide și utiliza, iar acest lucru se face automat pe partea laterală a formularului de raportare, și nu pe formularul de apelare.

Parametrul „Sursa setărilor disponibile” este tradus automat în informațiile generatorului atunci când formularul este creat pe server și nu poate fi suprascris. Sau, mai degrabă, se poate, dar acest lucru va avea efect numai după o redefinire completă a întregului lanț de obiecte înrudite. în care GetSourceAvailableSettings() va returna Nedefinit până la sfârșitul tuturor evenimentelor de deschidere a formularului.

Permiteți-mi să remarc că parametrii formularului, care în esență nu sunt parametri cheie, își „întind” efectul pe mai multe evenimente dacă steagul de formare este setat la deschidere. Da, în caz ProcessingCheckFillOnServer, numit în timpul deschiderii și formării, va fi disponibil parametrul „Selectare”, dar odată cu el, dar apelat simplu de utilizator făcând clic pe butonul „Generează”, acesta nu va mai fi disponibil. Acest lucru se datorează faptului că toate aceste evenimente sunt procesate într-o singură „vizită” la server, dacă formarea la deschidere este activată și numai la sfârșitul lor controlul este transferat către client și numit La Deschidere. În acest caz, parametrii care nu sunt cheie se pierd în mod natural.

Ordinea generală de execuție a evenimentelor la deschiderea unui formular cu un steag pentru a genera un raport la deschidere (puțin mai mult decât este descris în „Dezvoltare profesională”):

Când CreatedOnServer

Înainte de a încărca opțiunea pe server

Când încărcați OptionOn Server

Înainte de a încărca setările utilizatorului pe server

Când se încarcă setările utilizatorului pe server

Când actualizați compoziția setărilor utilizatorului pe server

ProcessingCheckFillOnServer

La Deschidere

În acest caz, nici opțiunea, nici PN nu sunt modificate decât dacă s-au făcut eforturi deosebite.

Partea 5.

Acum să ne uităm mai detaliat la sarcina de a deschide un formular de raport cu construcția sa și selecția pre-specificată. Informații succinte despre acest lucru sunt în ITS și în recomandările metodologice, dar numai principiul în sine este acoperit acolo și subtilitățile nu sunt dezvăluite. Deci, pentru a apela contextual un raport, trebuie să treceți parametrul „GenerateOnOpen” în forma acestuia, egal cu True; și parametrul Selection care conține structura. Cheile de structură sunt numele câmpurilor ACS sau ale parametrilor ACS, iar valorile sunt valorile acestora. Citând SP, dacă există un parametru ACS cu un nume corespunzător numelui cheii de structură, atunci valoarea va fi setată la acesta. Dacă nu există niciun parametru, dar există un câmp, atunci o selecție va fi adăugată la acest câmp. În același timp, dacă există un parametru și un câmp cu același nume, atunci sistemul îl va ignora pur și simplu în liniște și nu va instala nimic.

„Dezvoltarea profesională” oferă un exemplu de schimbare (adică interceptarea și reconfigurarea) PN „din mers” într-un eveniment Înainte de a încărca setările utilizatorului pe server, unde argumentul care conține PN curent este trecut. De fapt, acesta nu este întotdeauna cazul - de exemplu, pot exista cazuri în care o eroare la salvarea PN-ului într-o sesiune anterioară sau inconsecvențele între Setări, FN și PN vor duce la golirea argumentului „Setări”. Și cel mai interesant este că nu va fi posibilă reconfigurarea completă în acest eveniment; acest lucru se poate face doar „la sfârșitul” secvenței de evenimente, și anume, în cazul ProcessingCheckFillOnServer.

Să vedem ce avem înainte de a încărca PN-ul pe server.

Pentru un caz simplu, când nimic nu este presetat în ACS și nu sunt incluse elemente în PN, situația este următoarea: Setări – gol; FN – conțin selecția corectă; Mon conține o selecție goală. Modelarea funcționează corect, dar din punctul de vedere al utilizatorului interfața contrazice interiorul și este descurajatoare - selecția funcționează, dar nu este vizibilă. În mod similar, dacă activați Selecția în PN în setările structurii opțiunilor, raportul este, de asemenea, construit ținând cont de selecție, dar nici utilizatorul nu vede nicio selecție.

Să setăm preselecții în setările ACS din Configurator (egal valori goale) și includeți-le în Lun. În teorie, FN-urile ar trebui să completeze Setările, iar acelea ar trebui să completeze PN-ul, dar în realitate avem: în Setări - Selecție cu elementul necesar, dar o valoare de dreapta goală, FN-urile conțin selecția corectă și PN-urile încă nu conțin nimic. În plus, în acest caz raportul nu se va construi, deoarece valoarea de selecție din dreapta este goală, în ciuda valorii transmise în parametrul Select.

Nici o încercare de a lucra cu elemente PN nu dă rezultate. Pentru elementul PN, puteți schimba doar steagul „Utilizați” și participarea la „Rapid”. Valoarea de selecție de pe interfață va fi goală, sistemul nu va genera erori. În mod similar, va funcționa și o încercare de a lucra cu PN Selection; în depanator, valoarea corectă va fi vizibilă ca fiind completată corect, dar nu veți vedea nimic pe interfață. Permiteți-mi să vă reamintesc că este imposibil să schimbați componența PN. Astfel, sunt necesare trucuri suplimentare. De exemplu:

&Pe server Procedura SetPresetSelections(UserSettings) Dacă nu Parameters.Property(„Selection”), apoi returnează EndIf; Dacă Parameters.Selection.Quantity()=0, atunci returnează EndIf; rTypeEO=Type("Element de selecție al compoziției datelor"); Pentru fiecare cheie Din Parameters.Selection Loop pField=NewDataCompositionField(key.Key); // If (ValueType(kiz.Value)=Type("Array") sauValueType(kiz.Value)=Type("ValueList")) și kiz.Value.Quantity()>1 Then pViewComparison=DataCompositionComparisonType.InList; În caz contrar pComparisonType=DataCompositionComparisonType.Equals; endIf; // pNecessarySelection = Nedefinit; // vezi dacă există Selecție în setările utilizatorului pNecessaryEO=Nedefinit; // vezi dacă există un element separat de selecție de compoziție de date în setările utilizatorului Pentru fiecare elnastr Din UserSettings.Elements Cycle If TypeValue(elnastr) = Type("DataComposition Selection") și pNecessarySelection=Undefined Then // poate exista doar o singură pNecessarySelection= elnastr; // acest lucru ar putea fi făcut în afara buclei, dar este necesar să sortați setările utilizatorului de dragul elementelor... În caz contrar, dacă TypeZnch(elnastr) = pTypeEO Atunci // acesta este un element de selecție, pot fi multe dintre ele, dar ne interesează cele care nu sunt inițializate sau cu câmpul obligatoriu If elstr.LeftValue=pField sau elstr.LeftValue=Undefined și rNeedEO=Undefined Then pNeedEO=elstr; endIf; endIf; EndCycle; // Dacă preRequiredSelection<>Nedefinit Apoi // merge ca o prioritate pNecessaryEOFromSelection = Nedefinit; Pentru fiecare elotb Din pNecessarySelection.Elements Cycle If elotb.LeftValue=pField Atunci pNecessaryEOfromSelection=eloteb; Abort EndIf; EndCycle; Dacă pNecessary EO din Selecție = Nedefinit, atunci pNecessary EO din Selecție = pNecessary Selection.Elements.Add(pType of EO); pNeedEOFromSelection.LeftValue=pField; endIf; pNecessaryEOfromSelection.ComparisonType=pComparisonType; pNecessaryEOFromSelection.RightValue=kiz.Value; pNecessaryEOFromSelection.Use=Adevărat; // rNeededEO.Use=False; OtherwiseIf pNecessarySelection=Nedefinit și pNecessaryEO<>Nedefinit Apoi // pune pe elementul pNecessaryEO.LeftValue=pField; pNecessaryEO.ComparisonType=pComparisonType; pNeedEO.RightValue=kiz.Value; pNeedEO.Use=Adevărat; endIf; pNeed=Nedefinit; Pentru fiecare elotb Din Report.ComposerSettings.Settings.Selection.Elements Loop // într-un mod amiabil, ar trebui să existe o căutare recursivă! Dacă TypeValue(elotb)=pTypeEO și elotb.LeftValue=pField, atunci pNeed=elotb; Abort EndIf; EndCycle; Dacă pNeed = Nedefinit, atunci pNeed = Report.Settings Composer.Settings.Selection.Elements.Add(pEOType); pNeed.LeftValue=pMargin; endIf; pNecessary.ComparisonType=pComparisonType; pNeed.RightValue=kiz.Value; pNeed.Use=Adevărat; //EndCycle; Report.Settings Composer.FixedSettings.Selection.Items.Clear(); // în caz contrar se va spune că elementele se intersectează/contrad Sfârșitul procedurii

Cel mai corect mod de a numi acest lucru este:

&Pe server Procedura Procesarea Verificărilor de completare Pe server (Eșec, Detalii verificate) Setați selecții predefinite (Raport. Linker Setări. Setări utilizator); Sfârșitul procedurii

Apoi, un apel de context, de exemplu, dintr-un formular de director, va arăta astfel:

&OnClient Procedura OpenReport(Command) If ValueFilled(Object.Link) Then ot=New Structure("LinkToDirectory",Object.Link); // așa este denumit câmpul în raportul SDS Form Parameters = New Structure ("Selection, GenerateWhen Opening", select, True); OpenForm("Report.Report1.Form.ReportForm",FormParameters,ThisForm); endIf; Sfârșitul procedurii

Partea 6.

Dacă este necesar, modificați setările raportului în timp ce lucrați cu acesta, inclusiv. atât la pornire, cât și după deschidere, cel mai corect mod este schimbarea „de la început”, adică. din setări ACS. Schimbarea schemei ACS se efectuează numai cu obiectul Raport (sau Raport extern), și nu cu datele formularului și în sine nu schimbă nimic - în Setări și în PN rămâne același ca a fost și FN-ul poate rămâne gol. Prin urmare, în funcție de sarcinile noastre:

După execuție

Report.Settings Composer.LoadSettings(SKD.DefaultSettings)

Se schimbă doar opțiunea și nimic mai mult;

După efectuarea tehnicii menționate la paragraful 2 (folosind „intermediarul” și metoda LoadCustomSettings()

funcționează numai dacă resetați PN-ul curent folosind interfața. De la sine, dacă opțiunea este schimbată, ei nu se vor schimba. În acest caz, selecția se modifică, dar un nou element de selecție nu este adăugat.

După execuție

ThisForm.CreateFormElementsUserSettings(,DisplayModeDataCompositionSettings.All)

platforma cade în tăcere. Testat pe mai multe versiuni diferite. Și apelarea modului pentru afișarea setărilor numai pentru cele rapide nu are sens - nu am influențat compoziția lor, așa că oricum nimic nu se va schimba.

Și, deoarece încă trebuie să modificăm complet nu numai selecțiile interne, ci și afișarea în formularul de raport și în formularele aferente, fie trebuie să schimbăm doar selecția, fie să procedăm după cum urmează:

&Pe server Procedura ChangeSKD() pObject = Form AttributesValue("Raport"); selection=pObject.DataCompositionScheme.SettingsOptions.Get(0).Settings.Selection; eo = selection.Elements.Add(Type("DataCompositionSelectionElement")); eo.LeftValue=NewDataCompositionField("LinkToDirectory.Field1"); eo.ComparisonType=DataCompositionComparisonType.Equals; eo.RightValue=Adevărat; eo.Use=True; ValueÂFormAttributes(pObject,"Raport"); Report.SettingsLitter.LoadSettings(pObject.DataCompositionSchema.DefaultSettings); Report.SettingsComposer.Restore(); // de dorit, deși acest lucru încă nu afectează FN-ul. // de fapt, aceasta este exact ceea ce se poate numi o modificare a compoziției PN-ului Pentru fiecare e-mail De la Report.ComponentSettings.Settings.Selection.Elements Cycle email.DisplayMode=ElementDisplayModeDataCompositionSettings.QuickAccess; Dacă EmptyString(el.UserSettingsIdentifier) ​​​​Atunci // puteți utiliza metoda electronicSetIdentifier pentru elementul PN, vedeți ajutorul acestuia în SP, totul este destul de clar acolo e.UserSettingsIdentifier="ID123"; // important - identificatorul poate fi ORICE, nu UUID sau GUID! el.ViewUserSettings="Test"; endIf; EndCycle; comp=NewDataCompositionSettingsComposer; comp.LoadSettings(pObject.DataCompositionScheme.DefaultSettings); Report.SettingsComposer.LoadCustomSettings(comp.CustomSettings); Pentru fiecare e-mail de la Report.Settings Composer.CustomSettings.Elements Cycle email.DisplayMode=ItemDisplayModeDataLayoutSettings.QuickAccess; // trage EndCycle pe formularul de raport; // iar acum aceasta va avea efectul: ThisForm.CreateFormElementsUserSettings(,DisplayModeDataCompositionSettings.QuickAccess); Sfârșitul procedurii

De fapt, poți studia această mecanică mult timp. Această publicație a apărut din studierea modalităților de a rezolva o problemă specifică și, prin urmare, este destul de unilaterală; dar bănuiesc că se poate scrie o carte separată despre logica internă a setărilor, în special a celor de utilizator, nu mai subtilă decât cea a lui Khrstalev. Din păcate, nu am energia sau timpul pentru asta. Cine consideră că anumite dezvoltări sunt utile este deja bun.

Unele lucruri au fost clarificate experimental și, prin urmare, sunt controversate. Cei care știu mai multe sunt invitați să critice și să comenteze.

Subsistemul din 1C 8.3— un obiect arbore de metadate care este responsabil pentru construirea interfeței de comandă de configurare.

Mai jos în articol vom vorbi despre subsisteme începând de la versiunea 8.2.

Cert este că în versiunea 8.1 (precum și pentru aplicare regulată 8.2) au existat și subsisteme, dar au servit cu totul alte scopuri, mai probabil pentru dezvoltator decât pentru utilizator. Folosind subsisteme în 8.1, diferite funcționalități au fost de obicei separate. Subsistemele au ajutat și la combinarea diferitelor configurații 1C - a fost posibil să se specifice ce sistem să fie transferat.

Subsisteme 1C și interfață de programare

În versiunile 8.3 și 8.2, subsistemele sunt instrumentul principal pentru construirea unei interfețe cu utilizatorul de comandă. Subsisteme au obiectele metadate structura ierarhica Pentru a configura un „submeniu” în interfață, trebuie să adăugați un subsistem subordonat:

Proprietăți și setări

Să ne uităm la setările și proprietățile subsistemelor din configurator:

Obțineți 267 de lecții video pe 1C gratuit:

Includeți în interfața de comandă— dacă ați uitat să setați acest steag, subsistemul nu va fi afișatîn interfață.

Butonul deschide panoul de setări de interfață, unde puteți configura interfețele în funcție de rolul utilizatorului curent:

Imagine— imaginea atribuită subsistemului este afișată în modul întreprindere. Puteți selecta o imagine standard sau o puteți adăuga pe propria dvs. creând-o mai întâi ca obiect de configurare Imagine:

Pe fila Opțiuni funcționale indică o listă de opțiuni funcționale în care este utilizat acest subsistem.

Tab Compus definește un set de obiecte metadate care participă la un subsistem dat.

Pe fila Alte puteți descrie ajutorul pentru subsistem și puteți specifica setările Includeți în conținut de ajutor— dacă să includă aceasta sectiune ajutor la informații de referință de configurare generală.

Dacă nu vedeți un raport sau o procesare în interfața gestionată

Această problemă apare foarte des în rândul dezvoltatorilor începători - se pare că un raport sau o procesare a fost adăugat la subsistem, dar nu este vizibil.

Primul motiv pentru aceasta poate fi faptul că obiectul nu are o formă controlată definită.

Al doilea motiv este că în fila Comenzi a obiectului, caseta de selectare „Utilizați comenzi standard” este bifată. Acest lucru se datorează faptului că pentru a deschide procesarea, fie poate fi descrisă propria procedură, fie poate fi utilizată una standard:

Articolul continuă seria „Primii pași în dezvoltarea 1C”.

În configurația pe platforma 1C:Enterprise, la afișarea informațiilor se folosesc cel mai des tabelele care afișează diverse liste de informații. Lucrul cu astfel de liste poate avea loc atât sub forma unei liste, cât și sub forma unui element (procesare).

În acest articol, ne vom familiariza cu aceste opțiuni pentru personalizarea listelor și, de asemenea, ne vom uita la alte caracteristici ale personalizării formularelor din partea utilizatorului.

Aplicabilitate

Articolul discută despre interfața administrată în versiunea „Versiunea 8.2” a configurației dezvoltate pe platforma 1C 8.3.4.482.

Dacă lucrați cu configurații care acceptă această interfață, atunci informațiile sunt relevante pentru tine și versiunile actuale platforme.

Dacă lucrați în noua interfață Taxi, atunci numele unor comenzi de configurare, precum și secvența generală a acțiunilor, pot fi ușor diferite.

În plus, versiunea actuală a platformei a adăugat noi capabilități de căutare în liste.

Configurarea formularelor și lucrul cu liste

Pentru elementele de formular gestionate, este posibilă modificarea vizibilității și a altor proprietăți. În aceste scopuri într-o formă controlată în meniu Toate acțiunile servește ca element Schimbați forma.

După ce faceți clic pe această comandă, va apărea fereastra „Setări formular”.

În fereastra care apare, puteți utiliza casetele de selectare pentru a modifica vizibilitatea unor detalii. În acest caz, formularul este scalat automat.

Puteți modifica ordinea detaliilor. Adăuga grup nouși plasați câteva detalii (elemente) în el, determinând opțiunea de grupare a acestora (orizontală, verticală).

Detaliile incluse în grup vor fi postate în consecință. În plus, puteți configura proprietăți precum lățimea, înălțimea și datele de antet pentru elemente.

Puteți defini atribute care vor fi activate la deschiderea formularului.

O caracteristică importantă este capacitatea de a adăuga noi câmpuri în formular. Acest lucru devine posibil prin atributele tipului de referință.

De exemplu, având un atribut tip referință pe formular Contrapartidă, poate adauga Persoana de contact , dacă acest detaliu este prezent în directorul „Contrapărți”.

Dacă este necesar, câmpurile suplimentare pot fi eliminate. Câmpurile create în configurator nu pot fi șterse. Toate setările făcute de utilizator sunt salvate.

Pentru a reveni la setările standard în fereastra Setări formular din meniu Toate acțiunile ar trebui să selectați articolul Setați setările implicite.

Pe lângă personalizarea formularelor din interfața gestionată, este posibilă personalizarea listelor (elemente de director, documente).

Sub forma unei liste în meniu Toate acțiunile conţine o comandă specială Personalizați lista.

Se va deschide fereastra „Setări Listă”. În această fereastră puteți selecta, sorta, defini formatarea condiționată și gruparea.

Figura prezintă un formular pentru editarea selecției.

Selectarea se poate face folosind mai multe câmpuri. În acest caz, în mod implicit selecția va funcționa în funcție de condiția AND.De asemenea, puteți utiliza condițiile SAU și NU.

Pentru a utiliza condiția SAU (NU), trebuie să adăugați grupul corespunzător (Grup SAU, Grup NU) utilizând comanda Condiții de grup.

Figura prezintă un formular pentru definirea câmpurilor de sortare.

Gruparea poate fi configurată. În figură, câmpul pentru grupare este selectat Contrapartidă.

Figura următoare arată cum va fi efectuată gruparea.

Puteți colora în mod liber lista sau aplica alte elemente de design condiționat (selectarea fontului, formatarea specifică) în funcție de o anumită condiție, precum și selectarea unei liste de câmpuri de formatat.

Figura arată rezultatul proiectării condiționate a fundalului câmpului Sumă.
Când suma este > 100.000.

Trebuie remarcat faptul că este posibil să vizualizați directoare în modul ierarhic.

Vizualizarea ierarhică a directoarelor poate fi configurată prin intermediul articolului Modul de vizualizareîn meniu Toate acțiunile. Puteți alege una dintre opțiuni: Lista ierarhică, Listă, Copac.

De asemenea, este posibil să configurați propria grupare a elementelor de director după anumite detalii.

De exemplu, puteți grupa articole după furnizor. Exemplul este similar cu cel în care am analizat gruparea documentelor „Vânzări de bunuri și servicii” pe contrapărți.

O caracteristică convenabilă este selecția multiplă în liste și execuția ulterioară a acțiunilor de grup (postare, anulare, debifare ștergere).

Obiectele din listă sunt selectate ținând apăsată tasta Schimb sau Ctrl.

Căutarea unei anumite valori într-o listă are propriile sale caracteristici. Căutarea operează în modul de selecție. Rămân doar acele rânduri care îndeplinesc condiția de căutare.

Pentru a căuta după valoare în coloana curentă, trebuie doar să poziționați cursorul pe coloana dorită și să faceți clic pe butonul Găsiîn panoul de comandă. Va apărea o fereastră în care ar trebui să faceți clic și pe butonul Găsi.

Pentru a face căutarea mai precisă, puteți utiliza caseta de selectare Caută în găsit.

Când căutați un rând de date de un tip de referință (de exemplu, unități de măsură), ar trebui să selectați opțiunea de căutare adecvată ...(pe linie).

Aceasta se încheie cu liste și modalități de configurare a acestora. În următorul articol vom continua să ne familiarizăm cu interfața și să ne uităm la instrument la îndemână pentru a informa utilizatorul despre care nu am mai vorbit până acum. Ce fel de instrument este acesta? :)