Formular gestionat adăugând programatic 1s. Detalii de bază ale formularului. Metode pentru conversia datelor obiect aplicației în date de formular

Formularul este controlat prin diferite elemente de formular, care sunt situate ierarhic pe filă Elemente designer de forme. Cel mai important element este forma în sine, care se află în vârful ierarhiei elementelor, iar elementele rămase îi sunt subordonate.

Toate elementele formularului pot fi împărțite în cinci grupe: câmpuri, elemente de grupare, butoane, decorațiuni și tabele. În articolele mele voi analiza fiecare dintre grupuri. În acest articol, vom începe să studiem unul dintre tipurile de element de câmp - câmp de intrare, dar înainte de asta vom învăța cum să adăugați un element în formular.

Adăugarea de elemente într-un formular

Acest lucru se face destul de simplu: trebuie să selectați elementul Formăîn fereastra Elemente de design formular și faceți clic pe butonul „Adăugați”. După aceasta, se va deschide o fereastră în care trebuie să selectați tipul de element dorit

După selecție, elementul dorit va apărea în fereastră Elemente.

Element de formular gestionat Domeniu

Să ne uităm la un element de formular gestionat Domeniu. Acest element este necesar pentru a introduce informații în formular. Și, de asemenea, pentru a afișa orice informație. După ce adăugați acest element în formular, paleta de proprietăți a elementului de formular se va deschide în partea dreaptă. Pentru moment, ar trebui să fiți interesat de două proprietăți – DataPath și View.

În proprietatea DataPath, dezvoltatorul poate asocia un element de formular cu atributul de formular dorit. Vă rugăm să rețineți că după ce elementul a fost adăugat Câmp de intrare pe formular nu a fost afișat pe formularul propriu-zis. Acest lucru sa întâmplat deoarece noul nostru element nu este asociat cu . De exemplu, am creat mai multe atribute pe formularul de procesare cu diferite tipuri primitive și un atribut cu un tip de referință.

Acum să conectăm elementul nostru de formular recent adăugat cu unul dintre detalii. Pentru a face acest lucru, selectați atributul dorit din proprietatea PathKData a elementului.

După aceasta, proprietățile DataPath și View vor fi completate, iar elementul în sine va fi afișat în vizualizarea formularului.

Acordați atenție proprietății elementului Vedere. Această proprietate definește funcționalitatea câmpului de intrare. Puteți selecta diferite valori pentru această proprietate.

În funcție de valoarea selectată, funcționalitatea va fi determinată. În figurile de mai sus, valoarea selectată este - câmp de intrare, adică putem introduce orice valoare în acest câmp de intrare și dacă selectăm o valoare câmp de etichetă, atunci nu vom putea introduce nimic.

Această valoare a proprietății Vedere Câmpurile de introducere sunt convenabile de selectat atunci când trebuie doar să afișați informații de ajutor utilizatorului.

Acum să adăugăm un nou element de formular cu tip Câmp de intrareși conectați-l cu recuzita DetaliiData prin proprietatea deja familiară pentru noi DataPath

După cum puteți vedea, aspectul câmpului de introducere s-a schimbat și posibila alegere a valorilor pentru proprietatea View se va schimba, de asemenea.

Astfel, concluzionăm că funcționalitatea câmpului de intrare depinde de tipul de atribut.

Pentru recuzită cu tip boolean Următoarele valori ale proprietăților de vizualizare vor fi disponibile.

Și pentru atributele cu un tip de referință, alte valori ale proprietății View vor fi disponibile.

Lucrări mai detaliate cu elemente de formular folosind exemple practice sunt prezentate în cartea „Bazele dezvoltării în 1C: Taxi. Dezvoltare gestionată de aplicații în 12 pași”.

Uneori se pare că învățarea limbajului de programare în 1C este complicată și dificilă. De fapt, programarea în 1C este ușoară. Cărțile mele vă vor ajuta să stăpâniți ușor și rapid programarea în 1C: și „Elementele de bază ale dezvoltării în 1C: Taxi”

Învață programarea în 1C cu ajutorul cărții mele „Programare în 1C în 11 pași”

  1. Fără termeni tehnici complicati.
  2. Peste 700 de pagini de material practic.
  3. Fiecare sarcină este însoțită de un desen (captură de ecran).
  4. O colecție de probleme pentru teme.
  5. Cartea este scrisă într-un limbaj clar și simplu - pentru un începător.

Această carte este potrivită pentru cei care au început deja programarea și întâmpină anumite dificultăți cu acest subiect și pentru cei care programează de mult timp, dar nu au lucrat niciodată cu formulare gestionate 1C.

  1. Fără termeni tehnici complexi;
  2. Peste 600 de pagini de material practic;
  3. Fiecare exemplu este însoțit de un desen (captură de ecran);
  4. Cartea este trimisă prin e-mail în format PDF. Poate fi deschis pe orice dispozitiv!

Cod promoțional pentru o reducere de 15% - 48PVXHeYu


Dacă această lecție te-a ajutat să rezolvi vreo problemă, ți-a plăcut sau ti s-a părut utilă, atunci poți susține proiectul meu donând orice sumă:

Puteți plăti manual:

Yandex.Bani - 410012882996301
Web Money - R955262494655

Alăturați-vă grupurilor mele.

Și Data Transfer Object la structurarea codului, sub formă controlată în mediul 1C 8.2.

Introducere

Să începem cu o scurtă descriere a conceptului de „formă gestionată” și a conceptelor conexe ale platformei 1C. Cunoscătorii de platforme ar putea dori să omite această secțiune.

În 2008, a devenit disponibilă o nouă versiune a platformei 1C: Enterprise 8.2 (denumită în continuare Aplicația Gestionată), care schimbă complet întregul nivel de lucru cu interfața. Aceasta include interfața de comandă, formularele și sistemul de ferestre. În același timp, nu numai că se schimbă modelul de dezvoltare a interfeței cu utilizatorul în configurație, dar este propusă și o nouă arhitectură de separare a funcționalității între aplicația client și server.
Aplicația gestionată acceptă următoarele tipuri de clienți:

  • Client gros (mod de lansare normal și gestionat)
  • Client subțire
  • Client web
Aplicația gestionată utilizează formulare construite pe tehnologie nouă. Sunt numiti Formulare gestionate. Pentru a ușura tranziția, sunt acceptate și formularele anterioare (așa-numitele formulare Regular), dar funcționalitatea lor nu este dezvoltată și sunt disponibile doar în modul de lansare a clientului gros.
Principalele diferențe ale formularelor gestionate pentru un dezvoltator:
  • Descriere declarativă, nu „pixel cu pixel” a structurii. Amplasarea specifică a elementelor este efectuată automat de către sistem atunci când formularul este afișat.
  • Toate funcționalitățile formularului sunt descrise ca detaliiŞi echipe. Detaliile sunt datele cu care funcționează formularul, iar comenzile sunt acțiunile care trebuie efectuate.
  • Formularul rulează atât pe server, cât și pe client.
  • În contextul clientului, aproape toate tipurile de aplicații sunt indisponibile și, în consecință, este imposibil să se modifice datele din baza de informații.
  • Pentru fiecare metodă sau variabilă de formă, aceasta trebuie specificată directivă de compilare, definirea locației de execuție (client sau server) și accesul la contextul formularului.
Să enumerăm directivele pentru compilarea metodelor de formulare:
  • &OnClient
  • &OnServer
  • &OnServerWithout Context
  • &OnClientOnServerWithout Context
Să ilustrăm cele de mai sus. Captura de ecran arată un exemplu de formular gestionat și modulul acestuia în modul de dezvoltare. Găsiți descrierea declarativă, elementele de recuzită, directivele de compilare etc.

Toate discuțiile ulterioare vor fi despre partea dreaptă a ilustrației, despre cum să structurați codul modulului și ce principii vă vor permite să implementați interacțiunea eficientă client-server.

Să definim problema

Au trecut câțiva ani de când noua versiune a platformei 1C este utilizată în mod activ și multe soluții (configurații) au fost lansate atât de 1C, cât și de numeroșii săi parteneri.
În acest timp, dezvoltatorii au dezvoltat o înțelegere comună a principiilor interacțiunii client-server la crearea formularelor și s-a schimbat abordarea implementării modulelor software în noile realități arhitecturale?

Să ne uităm la structura codului (modul formular) în mai multe forme ale aceleiași configurații standard și să încercăm să găsim modele.
Prin structură înțelegem secțiuni de cod (cel mai adesea acestea sunt blocuri de comentarii) alocate de dezvoltator pentru a grupa metode și directive de compilare pentru aceste metode.
Exemplul 1:
Secțiunea de gestionare a evenimentelor Metoda - pe client Metoda - pe server Metoda - pe client Secțiunea proceduri și funcții de service Funcții auxiliare de control al intrărilor
Exemplul 2:
Proceduri și funcții de service Documente de plată Valori Manipulatori de evenimente
Exemplul 3:
Proceduri de service pe server Proceduri de service pe client Proceduri de service pe server fără context.
Exemplul 4:
Proceduri de uz general Manipulatori de evenimente de formulare Proceduri ale subsistemului „informații de contact”.
În esență, structura codului lipsește sau, pentru a spune ușor, este similară cu ceea ce era în Forms 8.1:

  • Cuvinte neinformative „General, Serviciu, Auxiliar”.
  • Încercări timide de a separa metodele client și server.
  • Metodele sunt adesea grupate pe elemente de interfață „Lucrul cu partea tabelară Produse, Informații de contact”.
  • Aranjamentul arbitrar al metodelor și grupurilor de coduri. De exemplu, Event Handlers pot fi în partea de sus într-o formă, în partea de jos într-o alta, deloc evidențiate într-o a treia, etc.
  • Și să nu uităm că toate acestea sunt într-o singură configurație.
  • Da, există configurații în care cuvintele „General, Service, Auxiliar” sunt întotdeauna în aceleași locuri, dar...
De ce aveți nevoie de structură de cod?
  • Simplificarea întreținerii.
  • Simplificați învățarea.
  • Înregistrarea principiilor generale/importante/de succes.
  • ...opțiunea ta
De ce nu ajută standardul de dezvoltare existent de la 1C?
Să ne uităm la principiile publicate pe discuri ITS și în diverse „Ghiduri pentru dezvoltatori...” care sunt recomandate atunci când scrieți un formular gestionat.
  • Minimizați numărul de apeluri pe server.
  • Calcul maxim pe server.
  • Apelurile non-contextuale ale serverului sunt mai rapide decât cele contextuale.
  • Program cu comunicarea client-server în minte.
  • etc.
Acestea sunt sloganuri care sunt absolut adevărate, dar cum să le implementăm? Cum să minimizezi numărul de apeluri, ce înseamnă să programezi în modul client-server?

Modele de design sau înțelepciune generațională

Interacțiunea client-server a fost folosită în diverse tehnologii software de zeci de ani. Răspunsul la întrebările prezentate în secțiunea anterioară este cunoscut de mult și este rezumat în două principii de bază.
  • Fațada la distanță(denumită în continuare interfață de acces la distanță)
  • Obiect de transfer de date(denumit în continuare obiect de transfer de date)
Un cuvânt de la Martin Fowler, descrierea sa a acestor principii:
  • … Fiecare obiect potențial destinat accesului de la distanță trebuie să aibă interfață cu granularitate scăzută, care va minimiza numărul de apeluri necesare pentru a efectua o anumită procedură. ... În loc să solicitați o factură și toate articolele ei separat, trebuie să citiți și să actualizați toate elementele facturii într-o singură solicitare. Acest lucru afectează întreaga structură a obiectului... Amintiți-vă: interfața de acces la distanță nu conține logica domeniului.
  • ...dacă aș fi o mamă grijulie, cu siguranță i-aș spune copilului meu: „Nu scrie niciodată obiecte de transfer de date!” În cele mai multe cazuri, obiectele de transfer de date nu sunt altceva decât set câmp umflat... Valoarea acestui monstru dezgustător constă numai în posibilitatea transmite mai multe informații prin rețea într-un singur apel- o tehnică de mare importanță pentru sistemele distribuite.
Exemple de șabloane în platforma 1C
Interfața de programare a aplicației disponibilă dezvoltatorului atunci când dezvoltă un formular gestionat conține multe exemple ale acestor principii.
De exemplu, metoda OpenForm(), o interfață tipică „aspră”.
Parametri de deschidere = Structură nouă(„Parametru1, Parametru2, Parametru3”, Valoare1, Valoare2, Valoare3); Form = OpenForm(FormName, OpeningParameters);
Comparați cu stilul adoptat în v8.1.
Form = GetForm(FormName); Form.Parameter1 = Value1; Form.Parameter2 = Value2; Form.Open();

În contextul unui formular gestionat, există multe „Obiecte de transfer de date”. Puteți selecta sistemicăŞi definit de dezvoltator.
Cei de sistem modelează un obiect de aplicație pe client, sub forma unuia sau mai multor elemente de date de formular. Este imposibil să le creați în afara conexiunii la detaliile formularului.

  • DataFormsStructure
  • DataFormsCollection
  • DataFormStructureWithCollection
  • DataShapesTree
Conversia obiectelor de transfer de date de sistem în tipuri de aplicații și invers se realizează folosind următoarele metode:
  • ValueInFormData()
  • FormDataValue()
  • CopyFormData()
  • ValueInFormAttributes()
  • FormAttributesValue()
Adesea, conversia explicită este utilizată atunci când se adaptează o soluție existentă. Metodele se pot aștepta (utiliza caracteristici) parametri de intrare, cum ar fi ValueTable, mai degrabă decât FormDataCollection, sau metoda a fost definită în contextul unui obiect aplicație și a devenit indisponibilă pentru apelul direct din formular.
Exemplul 1C v8.1:
// pe client în contextul formularului FillUserCache(DepartmentLink)
Exemplul 1C v8.2:
// pe server în contextul formularului ProcessingObject = Form AttributesValue("Object"); ProcessingObject.FillUserCache(DepartmentRef); ValueÂFormAttributes(ProcessingObject, "Object");

Obiectele de transfer de date, a căror structură este determinată de dezvoltator, sunt un mic subset al tipurilor disponibile atât pe client, cât și pe server. Cel mai adesea, următoarele sunt utilizate ca parametri și rezultate ale metodelor unei interfețe „groșate”:

  • Tipuri primitive (șir, număr, boolean)
  • Structura
  • Corespondenţă
  • Matrice
  • Legături către obiectele aplicației (identificator unic și reprezentare text)
Exemplu: metoda acceptă o listă de comenzi pentru schimbarea statutului și returnează clientului o descriere a erorilor.
&OnServerWithoutContext Funcția ServerChangeOrderStatus(Comenzi, NewStatus) Erori = Potrivire nouă(); // [comanda][descrierea erorii] Pentru fiecare comandă din ciclul comenzi StartTransaction();

Încercați DocOb = Order.GetObject();

…. alte actiuni, posibile nu numai cu comanda... Exceptie CancelTransaction();
  • Errors.Insert(Comandă, ErrorDescription()); EndTempt;
  • EndCycle;
  • Eroare de returnare; EndFunction // ServerChangeOrderStatus() Structurarea codului
  • Principalele obiective pe care trebuie să le reflecte modulul de formulare gestionate și abordări ale soluției. Trebuie să existe o locație clară pentru adăugarea unui cod nou. Un punct important este că șabloanele de metodă create automat de configurator sunt adăugate la sfârșitul modulului. Deoarece manipulatorii de evenimente pentru elementele de formular sunt cel mai adesea creați automat, blocul corespunzător este situat ultimul, pentru a nu trage fiecare handler în alt loc din modul.
Mai jos este structura de bază a modulului care implementează obiectivele enumerate.
  • Versiune grafică – arată clar fluxul principal de execuție.
  • Opțiunea text este un exemplu de design șablon pentru inserarea rapidă a unei structuri într-un nou modul de formular.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор="„Data=""/> // <Описание> // // //////////////////////////////////////////////////////////////////// ////////////////////////////// VARIABILE DE MODUL ////////////////// // ////////////////////////////////////////////////////////////////////// ////////// // PE SERVER //******* EVENIMENTE PE SERVER ******* &Pe Procedura Server când este creat pe server (Eșec, Procesare standard) / /Inserați conținutul handler-ului Sfârșitul procedurii //******* INTERFAȚA DE ACCES LA DISTANȚĂ ******* //******* LOGICA DE AFACERI PE SERVER ******* ///////// ///////////////////////////////////////////////////////////// /////// //////////////////// // METODE COMUNE DE CLIENT ȘI SERVER ///////////////// /////// /////////////////////////////////////////////////////////////// ///// //////// // PE CLIENT //******* LOGICA DE AFACERI PE CLIENT ******* //******* ECHIPA * ****** //******* EVENIMENTE CLIENȚI ******* //////////////////////////// ///// ///////////////////////////////////////////////////////////////// // / / PRINCIPALI OPERATORI DE PROGRAM

Întrebări înrudite
În concluzie, vom schița câteva domenii la care este util să ne gândim atunci când programați interacțiunea client-server.
  • Opțiuni de implementare a interfeței de acces la distanță. Asincronie, nivel de detaliu...
  • Memorarea în cache. 1C a luat o decizie arhitecturală nereușită, introducând memorarea în cache doar la nivelul metodelor de apelare a modulelor comune și neasigurând capabilități de control (timp de relevanță, resetare la cerere).
  • Apeluri implicite pe server. Nu uitați de caracteristicile tehnologice multe operațiuni „inofensive” pe client provoacă platforma să contacteze serverul.

Detalii formular

Un set de detalii de formular descrie compoziția datelor care sunt afișate, editate sau stocate în formular. Cu toate acestea, detaliile formularului în sine nu oferă posibilitatea de a afișa și edita date. Elementele de formular (vezi secțiunea „Elemente de formular” a acestui capitol) asociate cu detaliile formularului sunt utilizate pentru afișare și editare. Setul de toate detaliile formularului va fi numit date formular.

Important! Trebuie reținut că, spre deosebire de formularele obișnuite, toate datele dintr-o formă gestionată trebuie descrise sub formă de detalii. Nu este permisă utilizarea variabilelor modulului de formular ca surse de date pentru elementele de formular.

Este posibil să se atribuie Detalii de bază ale formularului, adică atribute care vor determina funcționalitatea standard a formularului (extensia formularului). Trebuie amintit că o formă nu poate avea decât un singur atribut principal.

Extensie formular– acestea sunt proprietăți suplimentare, metode și parametri de formă ai obiectului ManagedForm, caracteristice obiectului care este elementul principal al formularului.

În timpul procesului de dezvoltare a formularului, puteți seta în mod explicit capacitatea de a vizualiza și edita detalii specifice formularului, în termeni de roluri, folosind proprietățile Vizualizare și Editare (pentru mai multe detalii, consultați secțiunea „Setări de formular bazate pe roluri” din „Editori” ” capitolul). În plus, disponibilitatea unui anumit atribut în formularul în sine poate fi configurată folosind opțiuni funcționale (mai multe detalii despre opțiunile funcționale pot fi găsite în capitolul „Gestionarea interfeței de configurare”).

Proprietatea atributului formularului Date salvate este un semn că o modificare interactivă a detaliilor va duce la încercarea de a bloca datele formularului pentru editare, precum și la setarea automată a steagului de modificare a formularului.

Tipuri de date disponibile într-o formă gestionată

De asemenea, un formular gestionat diferă de un formular obișnuit prin tipurile de date cu care lucrează. Dacă forma normală funcționează cu majoritatea tipurilor pe care 1C:Enterprise le oferă (inclusiv cele de tip DirectoryObject, DocumentObject etc.), atunci în forma gestionată se pot distinge următoarele categorii de tipuri:

  • tipurile care sunt utilizate direct în formular sunt acele tipuri care există pe partea clientului subțire și Web (de exemplu, Number, DirectoryLink.Products, GraphicScheme, TabularDocument);
  • tipuri care vor fi convertite în tipuri speciale de date — tipuri de date de formular gestionate. Astfel de tipuri sunt afișate în lista de detalii de formular între paranteze, de exemplu (DirectoryObject.Products);
  • lista dinamică (pentru mai multe detalii, consultați secțiunea „Lista dinamică” a acestui capitol).

Conversia obiectelor aplicației în date de formular

Unele tipuri de aplicații (cum ar fi DirectoryObject, etc.) nu există pe partea de client subțire și Web (consultați capitolul Conceptul de aplicație gestionată pentru mai multe detalii). Prin urmare, pentru a reprezenta astfel de tipuri de aplicații în formular, platforma a introdus tipuri speciale de date concepute să funcționeze în formulare gestionate. Această caracteristică a unei aplicații gestionate face necesară convertirea obiectelor aplicației în date de formular (și invers).

Sunt utilizate următoarele tipuri de date:

  • Form DataStructure – conține un set de proprietăți de tip arbitrar. Proprietățile pot fi alte structuri, colecții sau structuri cu colecții. Acest tip este reprezentat, de exemplu, sub forma DirectoryObject.
  • O FormDataCollection este o listă de valori tastate, similară cu o matrice. Un element de colecție este accesat prin index sau identificator. Accesul prin ID poate să nu fie disponibil în unele cazuri. Acest lucru se datorează tipului de obiect aplicație care este reprezentat de această colecție. Identificatorul poate fi orice număr întreg. Acest tip este reprezentat, de exemplu, sub forma unei părți tabelare.
  • Formularul DataStructureWithCollection este un obiect care este reprezentat ca o structură și o colecție în același timp. Poate fi tratat ca oricare dintre aceste entități. Acest tip reprezintă, de exemplu, un set de înregistrări într-un formular.
  • Form DataTree – un obiect conceput pentru a stoca date ierarhice.

Un obiect de aplicație este reprezentat fie de unul sau mai multe elemente de date de formular. În general, ierarhia și compoziția datelor din formular depind de complexitatea și interconectarea obiectelor aplicației din formularul gestionat.

De exemplu, un document care conține o parte tabelară va fi reprezentat de un obiect de tip FormDataStructure (documentul în sine), căruia îi este subordonat un obiect de tip FormDataCollection (partea tabelară a documentului).

Important! Când se dezvoltă o configurație, este important să rețineți că obiectele aplicației sunt disponibile numai pe server, în timp ce obiectele de date din formular pot fi utilizate atât pe server, cât și pe client.

Transmiterea datelor între părțile client și server ale unui formular gestionat

De fapt, putem spune că datele formularului sunt o reprezentare unificată a datelor din diverse obiecte de aplicație cu care formularul funcționează uniform și care sunt prezente atât pe server, cât și pe client. Adică, formularul conține o „proiecție” a datelor obiect aplicației sub forma propriilor tipuri de date și efectuează conversie între ele dacă este necesar. Cu toate acestea, dacă dezvoltatorul de configurație implementează propriul algoritm de procesare a datelor, atunci trebuie să efectueze conversia datelor (de la tipuri specializate la tipuri de aplicații și invers) în mod independent.

La editarea detaliilor formularului într-un editor specializat (pentru mai multe detalii, vezi secțiunea „Detalii formular” din capitolul „Editori”), este posibil să se influențeze transferul de date între client și server în timp ce formularul rulează. Coloana editorului de detalii este folosită pentru aceasta. Utilizați întotdeauna. Efectul acestei proprietăți diferă pentru trei tipuri de atribute:

  • Pentru un atribut subordonat unei liste dinamice (coloana listă dinamică):
    • proprietatea este activată – atributul este întotdeauna citit din baza de date și inclus în datele formularului;
    • proprietatea este dezactivată - atributul este citit din baza de date și inclus în datele formularului numai atunci când există un element de formular vizibil asociat cu atributul sau cu atributul său subordonat.
  • Pentru recuzita subordonată colecției de mișcare:
    • proprietatea este activată – mișcările documentelor sunt citite din baza de date și vor fi prezente în datele din formular;
    • proprietatea este dezactivată - mișcările documentelor nu vor fi citite din baza de date și nu vor fi incluse în datele formularului (dacă nu există niciun element de formular care să facă referire la mișcările documentului).
  • Alte detalii formular:
    • proprietatea este activată – atributul va fi prezent în datele formularului, indiferent dacă există sau nu cel puțin un element de formular care este asociat cu atributul sau cu atributul subordonat acestuia;
    • proprietatea este dezactivată - atributul va fi prezent în datele formularului numai dacă există un element de formular asociat cu atributul sau cu atributul subordonat acestuia. Spre deosebire de atributele listelor dinamice, vizibilitatea elementului asociat cu atributul nu contează aici.

Nota. Trebuie reținut că proprietatea setată pe atributul părinte afectează toate atributele subordonate. De exemplu, dacă proprietatea Utilizare este întotdeauna ștearsă pentru partea tabelară a documentului, atunci sistemul consideră că această proprietate este ștersă și pentru toate detaliile subordonate (în ciuda stării reale a proprietății).

Metode pentru conversia datelor obiect aplicației în date de formular

Pentru a converti obiectele aplicației în date de formular și înapoi, există un set de metode globale:

  • ValueInFormData(),
  • FormDataInValue(),
  • CopyFormData().

Important! Metodele care funcționează cu obiectele aplicației sunt disponibile numai în procedurile de server. Metoda de copiere a valorilor între datele formularului este disponibilă pe server și pe client, deoarece nu necesită obiecte de aplicație ca parametri.

Când convertiți datele formularului într-un obiect de aplicație, trebuie să luați în considerare compatibilitatea acestora.

  • ValueInFormData() – convertește un obiect de tip aplicație în date de formular;
  • FormDataInValue() – convertește datele formularului într-un obiect de tip aplicație;
  • CopyFormData() – copiază datele formularului care au o structură compatibilă. Returnează True dacă copia a avut succes sau False dacă structura obiectului este incompatibilă.

Nota. La efectuarea acțiunilor standard (deschiderea unui formular, executarea unei comenzi standard Write etc.) a unui formular cu detaliile principale, conversia se realizează automat.

Să dăm un exemplu despre cum să utilizați transformarea datelor în proprii algoritmi.

&OnServerProcedure Când CreateOnServer (Eșec, Procesare standard)

ObjectProduct = Directories.Products.FindByName("Coffeepot").GetObject();

ValueInFormData(ObjectItem, Object);

Sfârșitul procedurii

&OnClient Procedure Write()

ValueInFormData(ObjectItem, Object);

WriteOnServer();

&OnServer Procedura WriteOnServer()

ObjectProduct = FormDataValue(Object, Type("DirectoryObject.Products"));

ObjectItem.Write();

  • Sfârșitul procedurii
  • Obiectul ManagedForm are și metode disponibile pe server:

ValueВFormAttribute() – convertește un obiect de tip aplicație în atributul de formular specificat.

FormAttributeVValue() – convertește un atribut de date de formular într-un obiect de tip aplicație.

Utilizarea acestor metode este de obicei mai convenabilă, deoarece acestea au, de exemplu, informații despre tipul de atribut al formularului. În plus, metoda Form AttributesValue() stabilește corespondența dintre datele din formular și obiect, care este utilizată la generarea mesajelor. Puteți citi mai multe despre acest lucru în capitolul „Capacitățile de navigare a serviciului”.

// Convertește atributul Object într-un obiect aplicație.

ObjectProduct = FormDataValue(Object, Type("DirectoryObject.Products"));

Document = Form AttributesValue("Obiect");

// Efectuează recalcularea utilizând metoda definită în modulul document.

  • Document.Recalculate();
  • // Convertește obiectul aplicației înapoi într-o prop.

ValueВFormAttributes(Document, „Obiect”);

Interfață software

FormDataTree

FindById

GetItems

Descriere:

Proiectat pentru a modela un arbore în date de formulare gestionate.

Acest obiect poate fi serializat către/de la XDTO. Tipul XDTO corespunzător acestui obiect este definit în spațiul de nume. Nume tip XDTO:

ValueВFormAttributes(Document, „Obiect”);

GetItems

Sintaxă:

GetItems()

GetItems

Valoarea returnată:<Идентификатор>)

Tip: Form DataCollection of Tree Elements.

<Идентификатор>Obține o colecție de elemente de arbore de nivel superior.

Disponibilitate: client, server, client subțire, client web.

Proiectat pentru a modela un arbore în date de formulare gestionate.

FindById

ValueВFormAttributes(Document, „Obiect”);

FindById(

Sintaxă:

Parametri:

(necesar)

<Имя свойства> (<Имя свойства>)

  • Tip: Număr. Identificatorul elementului arborelui.
  • Tip: FormDataTreeElement.
  • // Convertește obiectul aplicației înapoi într-o prop.
  • Obține un element de colecție după ID.

ValueВFormAttributes(Document, „Obiect”);

FormDataTreeItem

Proprietăți:

GetId (GetId)

GetParent

  • Proprietate
  • Element de arbore de date din formular.
  • FormDataTreeItemCollection
  • Elemente de colecție: DataFormTreeElement
  • Pentru un obiect, este posibil să parcurgeți colecția folosind operatorul Pentru fiecare... Din... Buclă. Parcursul selectează elementele colecției. Este posibil să accesați un element de colecție folosind operatorul [...]. Indexul elementului este transmis ca argument.
  • Introduce
  • Adăuga
  • Index (IndexOf)

ValueВFormAttributes(Document, „Obiect”);

Conta

Sintaxă:

Clar

  • Obţine
  • Mişcare

Şterge

Colectie de elemente din lemn.

Vezi și: FormDataTreeElement, metoda GetElements DataFormTree, metoda GetItems

Caracteristicile lucrului cu un arbore de valori Actualizare arbore Există o problemă

cade

platforme la actualizarea arborelui.

Dacă orice nod din arbore a fost extins și a fost selectat un nod subordonat, atunci când actualizați arborele cu funcția

&Pe Procedura Server Fill Concept Tree() dConcepts = srProperties.Build Concept Tree(OnDate, Meta.CurrentIB());

ClearTree(ConceptTree.GetItems());

ValueInFormData(dConcepts, ConceptTree); Sfârșitul procedurii

&OnClient Procedura OnDateOnChange(Element) Fill ConceptTree(); Sfârșitul procedurii Detaliile formularului asigură legătura acestuia cu datele. În acest caz, unul (și doar unul) dintre detalii poate fi desemnat ca principal; poate să nu fie neapărat tipul de date la care desenăm formularul. Dar comportamentul formularului va depinde de tipul de date al atributului principal. Pe lângă schimbarea comportamentului formularului, contextul modulului formular se modifică. Împreună cu metodele și proprietățile formei, metodele și proprietățile obiectului, care este valoarea atributului principal, devin disponibile în acesta. Este important ca formularele de tip Free Form să nu aibă detalii de bază. În acest caz, comportamentul formularului este determinat doar de setările utilizatorului. Să luăm în considerare întrebările despre detaliile de bază.

  1. Întrebarea 10.05 a examenului 1C: Platform Professional.
  2. Pentru ce este folosit principalul atribut al formularului?
  3. Definește sursa de date pentru formular în ansamblu
  4. Definește capabilitățile standard ale platformei de lucru cu formularul cu date de tipul specificat în atributul principal
  5. Pentru a oferi posibilitatea de a accesa programatic detaliile obiectului din contextul formularului local
  6. Oferă vizualizarea detaliilor obiectului în dialogul formular

2 și 3 sunt corecte


1 și 2 sunt corecte Răspunsul corect este numărul șase, vezi mai sus.
  1. Întrebarea 10.06 a examenului 1C: Platform Professional.
  2. Pentru ce sunt necesare detaliile formularului?
  3. Oferă vizualizarea detaliilor obiectului în dialogul formular

Pentru a descrie conținutul datelor care sunt afișate, editate sau stocate într-un formular

Pentru a afișa și edita date într-un formular Răspunsul corect este al treilea - ambele.

  1. Întrebarea 10.07 a examenului 1C: Platform Professional.
  2. Pentru a atribui atributele principale unei forme controlate arbitrare...

Trebuie să bifați caseta de selectare „Detalii de bază” din proprietățile atributelor formularului

trebuie să completați proprietatea „Date” a formularului selectând atributul necesar al formularului Răspunsul corect este al doilea:
  1. Întrebarea 10.08 a examenului 1C: Platform Professional.
  2. Pentru a atribui detaliile principale unei forme regulate arbitrare...
  3. formularul trebuie să fie cel principal, detaliile principale sunt determinate automat
  4. Trebuie să bifați caseta de selectare „Detalii de bază” din proprietățile atributelor formularului

trebuie să accesați meniul „Editare”, selectați „Detalii de bază” și selectați valoarea dorită

Detaliile principale sunt evidențiate cu caractere aldine:

Întrebarea 10.09 a examenului 1C: Platform Professional. Dacă există un atribut principal al formularului, este posibil să adăugați un alt atribut principal?
  1. Acest lucru este imposibil
  2. Este posibil prin atribuirea valorii adecvate proprietății atributului formular
  3. Este posibil doar programatic, la accesarea obiectului „Form”.
  4. Acest lucru este posibil prin adăugarea unei alte valori proprietății formularului corespunzătoare

Răspunsul corect este primul, există strict o cerință principală, pentru că... legătura cu obiectul trebuie să fie lipsită de ambiguitate.

Întrebarea 10.113 a examenului 1C: Platform Professional. Care dintre detaliile formularului prezentat în figură este principala?

  1. Lista cursurilor valutare
  2. DirectoryObject
  3. Formularele de director nu au detalii de bază
  4. Formularele de director au toate detaliile de bază
Al doilea răspuns corect este cel îngroșat.

Editor de formulare utilizat pentru a crea și edita formulare ale obiectelor soluției aplicației. Formele obiectelor sunt folosite de sistem pentru a afișa vizual datele pe măsură ce utilizatorul lucrează.

Orice formă reprezintă o combinație de mai multe componente:

  • elemente - obiecte care determină reprezentarea vizuală a formei și interacționează cu utilizatorul,
  • interfață de comandă - un set de comenzi afișate în formular;
  • detalii - obiecte ale căror date le utilizează formularul în activitatea sa.
  • comenzi - acțiuni care sunt definite în această formă specifică,
  • parametri - obiecte ale căror valori caracterizează forma în sine, sunt utilizate în timpul creării acesteia și rămân constante în timpul „vieții” formei,
  • modul - un program într-un limbaj încorporat responsabil pentru lucrul cu elemente și procesarea evenimentelor;

Editorul de formulare conține mai multe file care permit editarea tuturor componentelor formularului.

Într-o fereastră separată, în partea de jos a editorului, este afișat aspectul formularului în modul 1C:Enterprise.

Editarea elementelor

Editorul de formulare permite dezvoltatorului să folosească o gamă largă de opțiuni pentru a schimba aspectul formularului - aspectul pe care îl va avea formularul în modul 1C:Enterprise. Să le enumerăm pe cele principale:

Pagini, marcaje

Editorul de formulare vă permite să adăugați elemente speciale în formular care ajută la formarea propriului stil recunoscut, face accesul la date simplu și clar și, de asemenea, încadrează o cantitate mare de informații într-o zonă limitată.

Editorul vă permite să adăugați mai multe elemente în formular Grup - Pagini, fiecare dintre acestea putând conține mai multe elemente Grup - Pagina.

De exemplu, un formular de document poate conține un element Grup - Pagini, căruia îi sunt subordonate mai multe elemente Grup - Pagina cu titluri Imagine, CaracteristiciŞi Descriere:

Apoi, în modul 1C:Enterprise, va arăta astfel:

Titlul fiecărui grup - pagină este afișat într-o filă separată. Dezvoltatorul are posibilitatea de a seta modul de afișare a marcajelor: jos sau sus:

De exemplu, marcajele pot fi plasate în partea de jos:

Elemente

Editorul vă permite să adăugați diferite elemente în formular. Puteți adăuga elemente folosind comanda add sau trăgând detaliile formularului în arborele de elemente:

Toate elementele de formă sunt reprezentate sub forma unei structuri ierarhice, a cărei rădăcină este forma însăși. Acest lucru vă permite să navigați rapid la elementul de formular dorit:

Prin plasarea elementelor mai sus/jos în arbore, subordonându-le altor elemente și setând proprietățile elementelor grupului, puteți seta ordinea în care utilizatorul va ocoli controalele formularului la introducerea și editarea datelor. În modul 1C:Enterprise, elementele de formular vor fi procesate în ordinea ierarhiei lor și în funcție de tipul de grupare selectat pentru grupuri: verticală sau orizontală.

Separatoare

Separatoarele sunt elemente speciale care pot fi folosite pentru a redistribui spațiul unui formular fără a-i modifica dimensiunea. Platforma în modul 1C:Enterprise adaugă în mod independent aceste elemente în formular. Separatorul are capacitatea de a fi „prins” de mouse și de a se deplasa în cadrul formei în limitele sale, ținând cont de posibilitatea de localizare a altor elemente și de orientarea separatorului:

Când mutați un separator, toate elementele asociate cu separatorul se vor redimensiona sau se vor muta:

Modul formular

Pentru a edita un modul de formular, configuratorul apelează editorul de text și modul. Acest editor oferă dezvoltatorului o mare varietate de opțiuni pentru crearea și modificarea textului modulului.

Detalii formular

Editarea detaliilor formularului se efectuează în listă, ceea ce vă permite să creați detalii noi, să modificați detaliile existente și să ștergeți detaliile inutile. Proprietățile atributelor sunt stabilite folosind paleta de proprietăți.

Dacă un formular are un atribut principal care determină comportamentul formei care diferă de cel standard, acesta este evidențiat cu caractere aldine.

Interfață de comandă formular

Interfața de comandă a formularului este editată în arbore. Ramurile principale ale arborelui conțin comenzi adăugate în bara de navigare a ferestrei în care va fi afișat formularul și în bara de comandă a formularului. În fiecare dintre aceste ramuri, echipele sunt împărțite în grupuri standard.

Platforma adaugă automat câteva comenzi la interfața de comandă. Împreună cu aceasta, dezvoltatorul poate adăuga în mod independent comenzi la interfața de comandă trăgându-le din lista de comenzi de formular sau din lista de comenzi globale disponibile. Pentru toate comenzile adăugate la interfața de comandă, dezvoltatorul își poate seta vizibilitatea la diferitele roluri definite în configurație.

Formular comenzi

Comenzile de formular sunt editate în listă. Dezvoltatorul are capacitatea de a adăuga, elimina comenzi de formular și de a le stabili proprietățile folosind paleta de proprietăți. Inclusiv atribuirea unei proceduri unei comenzi care va fi executată atunci când utilizatorul apelează această comandă.

Marcat Comenzi standardŞi Echipe globale dezvoltatorului i se oferă liste de comenzi generate de platformă și disponibile pentru utilizare în acest formular. Proprietățile lor nu pot fi modificate, le puteți doar adăuga în formular.

Folosind mouse-ul, dezvoltatorul poate trage și plasa o comandă în interfața de comandă a formularului. De asemenea, puteți trage o comandă direct în arborele de elemente dacă aveți nevoie, de exemplu, să afișați această comandă ca buton situat pe un formular.

Opțiuni de formular

Parametrii formularului sunt editați în listă. Dezvoltatorul are capacitatea de a adăuga, elimina parametri de formular și de a le stabili proprietățile folosind paleta de proprietăți.