Acasă » Sport » Comutatoare, aplicații obișnuite, formulare gestionate. Comutatoare, aplicații obișnuite, formulare gestionate 1c probleme cu formularele gestionate

Comutatoare, aplicații obișnuite, formulare gestionate. Comutatoare, aplicații obișnuite, formulare gestionate 1c probleme cu formularele gestionate

Platforma 1C:Enterprise vă permite să adăugați și să modificați în mod programatic elemente ale unui formular gestionat. Să ne dăm seama de ce ar putea fi nevoie de acest lucru.

Modificarea software-ului a formularului poate fi necesară în mai multe cazuri:

La finalizarea configurațiilor standard pentru a facilita procedura de actualizare ulterioară. În acest caz, doar modulul formular va fi modificat. Modulele sunt mult mai ușor de actualizat decât formularele.
La implementarea unor algoritmi comuni. De exemplu, în subsistemul „Interzicerea editării detaliilor obiectului”, un buton poate fi creat în mod programatic pentru toate obiectele conectate la subsistem pentru a permite posibilitatea de a edita detalii.
La implementarea unor algoritmi specifici. De exemplu, în directorul Nomenclatură, sunt create câmpuri pentru editarea detaliilor suplimentare.

Într-o formă gestionată, puteți adăuga, modifica și șterge în mod programatic:

rechizite;
echipele locale;
elemente.

Toate aceste operațiuni sunt posibile numai pe server.

Remodelarea programatică are limitări:

Puteți șterge numai detalii/comenzi/elemente adăugate programatic. Nu puteți șterge în mod programatic obiectele create în configurator.
Nu puteți atribui un atribut ca principal.

Modificarea comenzilor de formular

Pentru a gestiona compoziția comenzilor pentru un obiect ManagedForm există o colecție Echipe

Adăuga (< ИмяКоманды >)

Cantitate ()

Găsi (< ИмяКоманды >)

Șterge (< Команда >)

Colecția Teams este disponibilă atât pe client, cât și pe server. Puteți modifica colecția (metodele Add() și Delete()) numai pe server. Puteți căuta și obține numărul de elemente (metodele Find () și Count ()) atât pe client, cât și pe server.

Ca exemplu de lucru cu comenzi de formular, să creăm o nouă comandă ChangeHistory cu titlul „ChangeHistory...”, care va apela handler-ul Afișează Istoricul(). Crearea are loc atunci când formularul este deschis.

&Pe server
Procedură WhenCreatingOnServer (Eșec, Procesare standard)
Echipă = Echipe. Adăuga( „Istoria schimbărilor”);
Echipă . Acțiune = ;
Echipă . Titlu = „Istoria schimbărilor...”;
Sfârșitul procedurii
&OnClient
Procedură Connectable_DisplayHistory(Comandă)
// acțiuni de comandă
Sfârșitul procedurii

Managerul de comenzi trebuie să fie localizat pe un formular și să aibă o directivă de compilare &OnClient.

Modificarea detaliilor formularului

Citirea compoziției detaliilor formularului este efectuată de funcție Obțineți detalii(< Путь >) returnând o matrice de tip FormAttributes. Parametrul funcției specifică calea către atributul părinte (sub formă de șir). Dacă parametrul este omis sau este specificat un șir gol, sunt returnate detaliile de nivel superior.

Modificarea detaliilor se face folosind metoda Modificați detaliile(<Detalii adăugate>, <Detalii detașabile>) obiect ManagedForm. La parametri Detalii adăugateȘi Detalii detașabile Sunt transmise matrice cu elemente de tip Form Attributes.

Atenţie!

Procesul de modificare a compoziției detaliilor necesită destul de mult resurse. Forma este de fapt recreată. În acest sens, lucrul cu detaliile formularului se efectuează în modul lot.

Să creăm un nou atribut de formular cu numele Cumpărător:

AddedDetails = New Array;
Detalii adăugate. Adăugați (Atribute noi de formular(„Cumpărător”, Descriere tip nou („DirectoryLink. Contrapărți”), „Client”);

// Modificări în compoziția detaliilor
);

Schimbarea elementelor de formular

Pentru a controla compoziția elementelor unui obiect ManagedForm există o colecție Elemente. Colecția are mai multe metode:

Introduce (< Имя>, < ТипЭлемента>, < Родитель>, < Элемент >)

Adăuga (< Имя>, < ТипЭлемента>, < Родитель >)

Cantitate ()

Găsi (< Имя >)

Mișcare(< Элемент>, < Родитель>, < МестоРасположения >)

Șterge (< Элемент >)

Colecția Items este disponibilă atât pe client, cât și pe server. Modificați o colecție (Insert methods () , Add () , Move () și Delete () ) sunt disponibile numai pe server. Puteți căuta și obține numărul de elemente (metodele Find () și Count ()) atât pe client, cât și pe server. Elementele de colectare pot fi:

FormGroup;
FormTable;
FormField;
Butonul Formular.

Puteți atribui programatic handler-uri de evenimente elementelor de formular. Metoda este destinată acestor scopuri SetAction(< ИмяСобытия>, < Действие >) .

Să ne uităm la câteva dintre cele mai comune exemple de lucru cu comenzi, detalii și elemente de formular.

Adăugarea unei comenzi și a butonului asociat:

// Creați o comandă
Echipă = Echipe. Adăuga( „Istoria schimbărilor”);
Echipă . Acțiune = „Plug-in_DisplayHistory”; // Formularul trebuie să conțină o procedură cu numele specificat
Echipă . Titlu = „Istoria schimbărilor...”;
// Creați un buton și asociați-l cu o comandă
Element = Articole. Adăuga( „Istoria schimbărilor”, Type("FormButton" ));
Element.CommandName = „Istoria schimbărilor”;

Adăugarea unui atribut și a câmpului de intrare asociat:

// Descrierea detaliilor adăugate
AddedDetails = New Array;
Detalii adăugate. Adăuga(Propoziții de formulare noi („Cumpărător”, Descriere tip nou ( „DirectoryLink. Contrapărți”), „Client” ));
// Modificarea compoziției detaliilor
Modificați detalii (Detalii adăugate);
// Crearea unui câmp de intrare și conectarea cu atribute
Element = Articole. Adaugă(„Cumparator” , Tip(„FormField” ));
Element . Vizualizare = FormFieldView. Câmp de intrare;
Element . PathToData= "Cumparator";

Atribuirea unui handler de evenimente unui element de formular:

ArticolClient. SetAction("Când se schimbă", „Connected_BuyerOnChange”);

&OnClient
Procedură Connected_BuyerOnChange(Element)
// Acțiuni de eveniment
Sfârșitul procedurii

Atenţie!

Proceduri care sunt setate ca handler de evenimente din cod folosind metoda SetAction(), este recomandat să setați prefixul Connectable_.

Atenţie!

Puteți descărca procesarea cu exemple de căutare programatică și modificarea detaliilor, comenzilor și elementelor unui formular gestionat.

Ș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 slab
Client web

Aplicația gestionată utilizează formulare construite pe tehnologie nouă. Sunt chemați 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
&Pe server
&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, au dezvoltat dezvoltatorii 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.
și așa mai departe.

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 fără referire 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 pot aștepta (folosește 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.

Separare clară a codului client și server. Să nu uităm că la momentul execuției acestea sunt două procese care interacționează, fiecare dintre ele având funcționalități disponibile semnificativ diferite.
Identificarea clară a interfeței de acces la distanță, ce metode de server pot fi apelate de la client și care nu? Numele metodelor de interfață la distanță încep cu prefixul „Server”. Acest lucru vă permite să vedeți imediat transferul de control către server în timp ce citiți codul și simplifică utilizarea ajutorului contextual. Rețineți că recomandarea oficială (ITS) sugerează metode de denumire cu postfixe, de exemplu, ChangeOrderStatusOnServer(). Cu toate acestea, repetăm că nu toate metodele de server pot fi apelate de la client și, prin urmare, accesibilitatea logică este mai importantă decât locația de compilare. Prin urmare, cu prefixul „Server” marchem doar metodele disponibile pentru client; să numim metoda exemplu ServerChangeOrderStatus().
Lizibilitate. O chestiune de gust, acceptăm comanda atunci când modulul începe cu procedurile de creare a unui formular pe server și metodele de acces la distanță.
Mentenabilitatea. 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.

Opțiune 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.

Formeîn 1C:Enterprise sunt destinate pentru afișarea și editarea informațiilor conținute în baza de date. Formularele pot aparține unor obiecte de configurare specifice sau pot exista separat de acestea și sunt utilizate de întreaga soluție de aplicație.

De exemplu, un director Nomenclatură poate avea mai multe forme care vor fi folosite în scopuri specifice - editarea unui element de director, afișarea unei liste etc.:

Alături de aceasta, pot exista forme generale care nu aparțin unor obiecte de configurare specifice - forme generale.

Forme de bază

Fiecare obiect de configurare poate fi folosit pentru a efectua unele acțiuni standard. De exemplu, pentru orice director poate fi necesar să afișați o listă a elementelor acestuia, să afișați elemente individuale ale directorului, să afișați un grup din director, să selectați elemente și grupuri de elemente din director. Pentru orice document, lista acestor acțiuni va fi mult mai mică: vizualizarea unei liste de documente, selectarea dintr-o listă de documente și vizualizarea unui document separat.

Pentru a se asigura că astfel de acțiuni standard sunt efectuate cu datele obiectelor soluției aplicației, pentru fiecare dintre ele există un set de formulare de bază care vor fi utilizate la efectuarea acțiunilor corespunzătoare. Oricare dintre formele subordonate acestui obiect poate fi atribuită ca fiind cea principală. De exemplu, în director Nomenclatură Pot exista următoarele forme de bază:

Și documentul Recepția de bunuri și servicii compoziția principalelor forme va fi diferită:

Astfel, dacă utilizatorul dorește să vizualizeze lista de directoare Nomenclatură sau lista de documente Recepția de bunuri și servicii, sistemul va deschide formularul corespunzător desemnat ca formular de listă pentru aceste obiecte.

Formulare generate automat

O caracteristică importantă a sistemului 1C:Enterprise 8 este mecanismul formularelor autogenerate. Acest mecanism eliberează dezvoltatorul de a crea toate formularele posibile pentru fiecare obiect de configurare. Dezvoltatorul trebuie doar să adauge un nou obiect de configurare, iar sistemul însuși va genera, la momentele potrivite în munca utilizatorului, formularele necesare pentru a afișa informațiile conținute în acest obiect.

Astfel, dezvoltatorul trebuie să-și creeze propriile forme de obiecte soluție de aplicație doar dacă acestea trebuie să aibă diferențe (design diferit sau comportament specific) față de formularele generate automat de sistem.

Conectarea unui formular la date

Dacă un formular aparține unui anumit obiect de configurare nu determină compoziția datelor care sunt afișate în formular. Faptul că formularul aparține, de exemplu, unui director Nomenclatură, vă permite să îl atribuiți ca unul dintre formele principale pentru acest director, dar nu determină în niciun fel ce date va afișa acest formular și care va fi comportamentul său.

Pentru a asocia un formular cu date se folosesc detalii de formular, care indica lista de date afisata de formular. Toate formularele, în sine, au același comportament, indiferent de datele pe care le afișează. Cu toate acestea, unul dintre atributele formularului poate fi desemnat ca atribut principal pentru acesta (este evidențiat cu caractere aldine), caz în care comportamentul standard al formularului și proprietățile sale vor fi completate în funcție de tipul atributului principal al formularului:

De exemplu, dacă un document este atribuit ca atribut principal al formularului Recepția de bunuri și servicii, apoi la închiderea formularului, sistemul va solicita confirmarea înregistrării și postării acestui document. Dacă atribuiți, de exemplu, un director ca atribut principal al formularului Nomenclatură, atunci o astfel de cerere de confirmare nu va apărea la închiderea formularului.

Structura formei

Principala caracteristică a formularelor este că nu sunt desenate de dezvoltator în detaliu, „pixel cu pixel”. Un formular într-o configurație este o descriere logică a compoziției formularului. Iar plasarea specifică a elementelor este efectuată automat de către sistem atunci când formularul este afișat.

Partea afișată a formularului (vizibilă pentru utilizator) este descrisă ca un arbore care conține elemente de formular.

Elementele pot fi câmpuri de introducere, casete de validare, butoane radio, butoane etc. În plus, un element poate fi un grup care include alte elemente. Un grup poate fi reprezentat ca un panou cu un cadru, un panou cu pagini (marcaje), o pagină în sine sau un panou de comandă. În plus, elementul poate fi un tabel, care include și elemente (coloane). Structura elementului descrie modul în care va arăta formularul.

Toate funcționalitățile formularului sunt descrise sub formă de detalii și comenzi. Detaliile sunt datele cu care funcționează formularul, iar comenzile sunt acțiunile care trebuie efectuate. Astfel, dezvoltatorul în editorul de formulare trebuie să includă detaliile și comenzile necesare în formular, să creeze elemente de formular care să le afișeze și, dacă este necesar, să aranjeze elementele în grupuri.

Pe baza acestei descrieri logice, sistemul generează automat aspectul formularului pentru a fi afișat utilizatorului. În acest caz, sistemul ia în considerare diverse proprietăți ale datelor afișate (de exemplu, tip) pentru a aranja elementele de formular cât mai convenabil pentru utilizator.

Dezvoltatorul poate influența aranjarea elementelor cu diverse setări. Poate determina ordinea elementelor, poate specifica lățimea și înălțimea dorite. Totuși, acestea sunt doar câteva informații suplimentare pentru a ajuta sistemul să afișeze formularul.

În formulare, dezvoltatorul poate folosi nu numai comenzile formularului în sine, ci și comenzile globale utilizate în interfața de comandă a întregii configurații. În plus, este posibil să se creeze comenzi parametrizabile care vor deschide alte formulare ținând cont de datele specifice formularului curent. De exemplu, aceasta ar putea fi apelarea unui raport privind soldurile la depozit care este selectat în prezent în formularul de factură.

Știm cu toții că compania 1C a avut multe versiuni diferite ale platformei 1C; acum vom fi interesați de una dintre cele mai recente versiuni la momentul scrierii acestui articol, acestea sunt versiunile 1C 8.2 și 1C 8.3. Dacă ați trebuit să lucrați în ambele versiuni, atunci cel mai probabil a observat diferențe în interfețele acestor versiuni, pentru utilizatori diferă doar ca aspect. În esență, o alegere aplicație obișnuită sau gestionată spune sistemului ce formulare să afișeze să ruleze, regulat sau controlat, precum și ce client de aplicație va fi utilizat implicit, gros sau subțire. Pentru informații mai detaliate despre clienți, citiți articolul „Ce sunt clienții grosi și subțiri în 1C, precum și diferențele lor.”

Aplicație obișnuită 1C (forme obișnuite, interfață obișnuită, versiunea 1C 8.2)

În 1C 8.2 este posibil să funcționeze numai cu forme obișnuite, în modul obișnuit de aplicare. Imaginea de mai jos prezintă baza de date în modul de operare „aplicație obișnuită 1C” (formulare obișnuite).

Aplicație gestionată 1C (formulare gestionate, interfață gestionată, versiunea 1C 8.3)

Pe platforma 1C 8.3 putem lucra atât cu forme obișnuite (în modul de compatibilitate), cât și cu cele gestionate. în plus formularele gestionate au două tipuri de afișare, acesta este standard și taxi. Un exemplu de configurație 1C 8.3 cu formulare standard gestionate este prezentat mai jos, iar după aceasta este afișată interfața „Taxi”.

Care este diferența dintre o aplicație 1C obișnuită și gestionată?

După cum am aflat deja o aplicație obișnuită și o aplicație gestionată sunt aceste tipuri de lansare a unui program 1C. Mai mult, în funcție de valoarea tipului de lansare 1C ( aplicație obișnuită sau gestionată), o interfață specifică va fi încărcată implicit ( forme regulate sau gestionate), prin urmare, există atât de multe sinonime pentru acest concept. Dorim să remarcăm că diferențele dintre interfețe sunt destul de semnificative; interfața gestionată a fost complet reproiectată. În principiu, acestea sunt toate diferențele pe care le văd utilizatorii obișnuiți ai programului 1C. În ceea ce privește programatorii, interfața gestionată necesită scrierea codului modificat, deoarece dezvoltarea este deja efectuată în 1C 8.3, și nu în 1C 8.2, de aici toate consecințele care decurg. Codul trebuie, de asemenea, împărțit în client și server; acest lucru este indicat folosind directivele corespunzătoare din configurator.

Klyuev V.V.

http://prof1c.kklab.ru

LUCRARE CU COMUTATORI

Va rog sa luati in calcul toti utilizatorii serviciului site - postez materiale in sectiunea Incepatori!!!

8.2 Formulare gestionate

În timp ce studiază comportamentul formularelor gestionate, programatorii sau dezvoltatorii de interfețe se confruntă cu întrebarea unde sunt comutatoarele în formele gestionate și cum să le adauge la formular. Este un lucru mic, dar este neplăcut că se petrece mult timp pentru astfel de fleacuri, deși acest timp ar putea fi alocat dezvoltării și optimizarii algoritmului, mai degrabă decât proiectării formularului.

Deci, să creăm o configurație goală pentru a înțelege întrebarea sau să alegem oricare dintre ele tipice.
Accesați grupul care conține directoare și adăugați un director nou pentru a experimenta. Aș dori să notez că configurația trebuie să aibă modul principal de lansare - Aplicație gestionată.

Deci, să creăm un nou director și să adăugăm atributul „Property1”, cu tipul „Boolean”

Acum să mergem la fila Formulare și să adăugăm un formular nou.

Deci, formularul controlat a fost creat, acum să lucrăm cu formularul și să găsim unde se află comutatorul.
Aici este forma noastră și pe ea ne vedem recuzita, dar sub forma unui steag

Deci cu ce am greșit?
Să ne uităm în proprietățile elementelor de recuzită pentru a vedea dacă există o comutare la tipul de control.
Și vedem că câmpul Switch nu este aici! (Unde am greșit?

Aparent, tipul de control al formularului depinde de tipul de date, să revenim la proprietățile formularului, și anume fila detalii, și să schimbăm proprietățile atributului nostru - și anume tipul său „Boolean”, la tipul „Număr”. ”.

Acum să ne întoarcem la proprietățile controlului și să verificăm dacă View-ul controlului a fost adăugat la proprietățile sale - - - Și urrah, vedem vizualizarea acolo - Switch Field.

Acum uitați-vă la formular, ceea ce vedem:

Vedem - 3 valori implicite, 3 comutatoare, dar avem nevoie de două dintre ele, mergem din nou la proprietățile atributului și ne uităm la proprietățile „Număr de coloane” acolo

Pentru 2 - setați Numărul de coloane - 2.

Acest lucru ar putea opri puțin un programator obosit)), dar acum și el și noi știm asta!

8.2 Forme regulate.

Plictisitor de întrerupătoare în forme obișnuite.
Există astfel de momente și se întâmplă) când trebuie să modificați un formular gata făcut, care are deja unele comutatoare și trebuie să adăugați un alt comutator la acest formular. Aici apare un fel de oboseală, care necesită mult timp, și nu timp pentru programarea codului - ci o pierdere de timp pentru a afișa aceste comutatoare pentru utilizator.

Deci, să ne uităm la un exemplu. Există un astfel de document pentru ajustarea chitanțelor în 1C UPP - cu siguranță există. Odată a trebuit să îi adăugăm comutatoare, astfel încât să fie extrase intrări ușor diferite pentru contabilitate. Care este problema, s-ar părea că trebuie, trebuie, o vom face. Dar acest formular are deja 2 butoane radio.

Așa arată forma în care trebuie să adăugăm mai multe comutatoare

În fila Avansat, am dori să plasăm încă două butoane radio. Deci, primul pas este să adăugați cu îndrăzneală un nou element de control în locul de care avem nevoie și să-l introduceți.

S-ar părea că totul este simplu. Creăm un nou atribut cu tipul „Număr” și introducem 2 comutatoare, dintre care unul va putea scrie date în atribut, iar celălalt nu.

Adăugați un nou element de control - Comutator, adăugați Switch2 în tabelul cu numărul și descrierea comutatoarelor, setați Switch1 mai întâi în grup și apăsați OK. Plasați controalele create pe formular. Actualizăm configurația bazei de date (F7) și o rulăm pentru depanare.

La executare (la crearea unui document nou în modul 1C:Enterprise), vedem că oricât am încerca să facem clic pe Switch2, nu se întâmplă nimic. Elementele nu funcționează așa cum ar trebui. Există un truc aici.
Reveniți la configurator. Selectați elementul de meniu Form -> Set traversal order... (este important ca formularul să fie deschis pe ecran)

Pentru ca comutatoarele noastre să funcționeze, trebuie să rupeți comanda automată și să fiți de acord cu una manuală. Și puneți-o în formă, astfel încât comutatoarele noastre să meargă una după alta în ordine.