Detajet themelore të formularit. Detajet e formularit të menaxhuar (1Cv8) Formularët e menaxhuar 1c shtojnë detaje në mënyrë programore

Detajet e formularit

Një grup detajesh formulari përshkruan përbërjen e të dhënave që shfaqen, modifikohen ose ruhen në formular. Në të njëjtën kohë, vetë detajet e formularit nuk ofrojnë mundësinë për të shfaqur dhe modifikuar të dhënat. Elementet e formularit (shih seksionin "Elementet e formularit" të këtij kapitulli) të lidhur me detajet e formularit përdoren për shfaqje dhe modifikim. Grupi i të gjitha detajeve të formularit do të quhet të dhënat e formularit.

E rëndësishme! Duhet mbajtur mend se, ndryshe nga format e rregullta, të gjitha të dhënat në një formë të menaxhuar duhet të përshkruhen në formën e detajeve. Nuk lejohet përdorimi i variablave të modulit të formularit si burim të dhënash për elementët e formularit.

Është e mundur të caktohet Detajet bazë të formularit, d.m.th., atributet që do të përcaktojnë funksionalitetin standard të formularit (zgjatja e formularit). Duhet mbajtur mend se një formë mund të ketë vetëm një atribut kryesor.

Zgjerimi i formularit– këto janë veti, metoda dhe parametra të formës shtesë të objektit ManagedForm, karakteristikë e objektit që është elementi kryesor i formularit.

Gjatë procesit të zhvillimit të formularit, mund të vendosni në mënyrë eksplicite aftësinë për të parë dhe modifikuar detaje specifike të formularit, për sa i përket roleve, duke përdorur veçoritë Shiko dhe modifikoni (për më shumë detaje, shihni seksionin "Cilësimet e formës së bazuar në role" të "Redaktuesit ” kapitulli). Për më tepër, disponueshmëria e një atributi të veçantë në vetë formularin mund të konfigurohet duke përdorur opsionet funksionale (më shumë detaje rreth opsioneve funksionale mund të gjenden në kapitullin "Menaxhimi i ndërfaqes së konfigurimit").

Vetia e atributit të formës Të dhënat e ruajturaështë një shenjë se një ndryshim ndërveprues në detaje do të çojë në një përpjekje për të bllokuar të dhënat e formularit për redaktim, si dhe në vendosjen automatike të flamurit të modifikimit të formularit.

Llojet e të dhënave të disponueshme në një formë të menaxhuar

Një formë e menaxhuar gjithashtu ndryshon nga një formë e rregullt në llojet e të dhënave me të cilat punon. Nëse forma normale funksionon me shumicën e llojeve që ofron 1C:Enterprise (përfshirë llojet DirectoryObject, DocumentObject, etj.), atëherë në formën e menaxhuar mund të dallohen kategoritë e mëposhtme të llojeve:

  • llojet që përdoren drejtpërdrejt në formë janë ato lloje që ekzistojnë në anën e klientit të hollë dhe Web (për shembull, Number, DirectoryLink.Products, GraphicScheme, TabularDocument);
  • llojet që do të konvertohen në lloje të veçanta të të dhënave—llojet e të dhënave të formës së menaxhuar. Llojet e tilla shfaqen në listën e detajeve të formularit në kllapa, për shembull (DirectoryObject.Products);
  • listë dinamike (për më shumë detaje, shihni seksionin "Lista dinamike" të këtij kapitulli).

Konvertimi i objekteve të aplikacionit në të dhëna të formularit

Disa lloje aplikacionesh (të tilla si DirectoryObject, etj.) nuk ekzistojnë në anën e hollë dhe të klientit në ueb (shih kapitullin Koncepti i aplikacionit të menaxhuar për më shumë detaje). Prandaj, për të përfaqësuar lloje të tilla aplikacionesh në formë, platforma ka prezantuar lloje të veçanta të dhënash të dizajnuara për të punuar në forma të menaxhuara. Kjo veçori e një aplikacioni të menaxhuar e bën të nevojshme konvertimin e objekteve të aplikacionit në të dhëna formuese (dhe anasjelltas).

Përdoren llojet e mëposhtme të të dhënave:

  • Form DataStructure – përmban një grup të vetive të një lloji arbitrar. Vetitë mund të jenë struktura të tjera, koleksione ose struktura me koleksione. Ky lloj përfaqësohet, për shembull, në formën DirectoryObject.
  • Një FormDataCollection është një listë vlerash të shtypura, të ngjashme me një grup. Një element koleksioni arrihet me indeks ose identifikues. Qasja me ID mund të mos jetë e disponueshme në disa raste. Kjo është për shkak të llojit të objektit të aplikacionit që përfaqësohet nga ky koleksion. Identifikuesi mund të jetë çdo numër i plotë. Ky lloj përfaqësohet, për shembull, në formën e një pjese tabelare.
  • Form DataStructureWithCollection është një objekt që përfaqësohet si një strukturë dhe një koleksion në të njëjtën kohë. Mund të trajtohet si ndonjë nga këto entitete. Ky lloj përfaqëson, për shembull, një grup regjistrimesh në një formë.
  • Form DataTree – një objekt i krijuar për të ruajtur të dhënat hierarkike.

Një objekt aplikacioni përfaqësohet nga një ose më shumë elementë të të dhënave të formës. Në përgjithësi, hierarkia dhe përbërja e të dhënave të formularit varen nga kompleksiteti dhe ndërlidhja e objekteve të aplikimit të formës së menaxhuar.

Për shembull, një dokument që përmban një pjesë tabelare do të përfaqësohet nga një objekt i llojit FormDataStructure (vetë dokumenti), të cilit i nënshtrohet një objekt i llojit FormDataCollection (pjesa tabelare e dokumentit).

E rëndësishme! Kur zhvilloni një konfigurim, është e rëndësishme të mbani mend se objektet e aplikacionit janë të disponueshëm vetëm në server, ndërsa objektet e të dhënave të formës mund të përdoren si në server ashtu edhe në klient.

Kalimi i të dhënave ndërmjet pjesëve të klientit dhe serverit të një forme të menaxhuar

Në fakt, mund të themi se të dhënat e formularit janë një paraqitje e unifikuar e të dhënave nga objekte të ndryshme aplikacioni me të cilat forma funksionon në mënyrë uniforme dhe të cilat janë të pranishme si në server ashtu edhe në klient. Kjo do të thotë, formulari përmban disa "projeksione" të të dhënave të objektit të aplikacionit në formën e llojeve të veta të të dhënave dhe kryen konvertimin midis tyre nëse është e nevojshme. Megjithatë, nëse zhvilluesi i konfigurimit zbaton algoritmin e tij të përpunimit të të dhënave, atëherë ai duhet të kryejë konvertimin e të dhënave (nga llojet e specializuara në llojet e aplikacioneve dhe anasjelltas) në mënyrë të pavarur.

Kur redaktoni detajet e formularit në një redaktues të specializuar (për më shumë detaje, shihni seksionin "Detajet e formularit" të kapitullit "Redaktuesit"), është e mundur të ndikoni në transferimin e të dhënave midis klientit dhe serverit ndërsa formulari është duke u ekzekutuar. Për këtë përdoret kolona e redaktuesit të detajeve. Përdorni gjithmonë. Efekti i kësaj vetie ndryshon për tre lloje atributesh:

  • Për një atribut të varur nga një listë dinamike (kolona e listës dinamike):
    • prona e aktivizuar – atributi lexohet gjithmonë nga baza e të dhënave dhe përfshihet në të dhënat e formularit;
    • vetia është e çaktivizuar - atributi lexohet nga baza e të dhënave dhe përfshihet në të dhënat e formularit vetëm kur ekziston një element i dukshëm aktualisht i formës i lidhur me atributin ose atributin e tij vartës.
  • Për rekuizitat në varësi të koleksionit të lëvizjes:
    • prona është e aktivizuar - lëvizjet e dokumenteve lexohen nga baza e të dhënave dhe do të jenë të pranishme në të dhënat e formularit;
    • prona është e çaktivizuar - lëvizjet e dokumenteve nuk do të lexohen nga baza e të dhënave dhe nuk do të përfshihen në të dhënat e formularit (nëse nuk ka element formular që referon lëvizjet e dokumentit).
  • Detaje të tjera të formularit:
    • veçoria është e aktivizuar - atributi do të jetë i pranishëm në të dhënat e formularit, pavarësisht nëse ekziston apo jo të paktën një element i formës që lidhet me atributin ose atributin e tij vartës;
    • prona është e çaktivizuar - atributi do të jetë i pranishëm në të dhënat e formularit vetëm nëse ka një element formular të lidhur me atributin ose atributin e tij vartës. Ndryshe nga atributet e listës dinamike, dukshmëria e elementit të lidhur me atributin nuk ka rëndësi këtu.

Shënim. Duhet mbajtur mend se vetia e vendosur në atributin prind prek të gjitha atributet vartëse. Për shembull, nëse veçoria Use pastrohet gjithmonë për pjesën tabelare të dokumentit, atëherë sistemi konsideron se kjo veti pastrohet edhe për të gjitha detajet vartëse (pavarësisht gjendjes aktuale të pronës).

Metodat për konvertimin e të dhënave të objektit të aplikacionit në të dhëna të formës

Për të kthyer objektet e aplikacionit në të dhëna të formës dhe mbrapa, ekziston një grup metodash globale:

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

E rëndësishme! Metodat që punojnë me objektet e aplikacionit janë të disponueshme vetëm në procedurat e serverit. Metoda e kopjimit të vlerave midis të dhënave të formularit është e disponueshme në server dhe në klient, pasi nuk kërkon objekte aplikacioni si parametra.

Kur konvertoni të dhënat e formularit në një objekt aplikacioni, duhet të merrni parasysh përputhshmërinë e tyre.

  • ValueInFormData() – konverton një objekt të llojit të aplikacionit në të dhëna të formës;
  • FormDataInValue() – konverton të dhënat e formularit në një objekt të llojit të aplikacionit;
  • CopyFormData() – kopjon të dhënat nga forma që kanë një strukturë të pajtueshme. Kthen True nëse kopjimi ishte i suksesshëm, ose False nëse struktura e objektit është e papajtueshme.

Shënim. Gjatë kryerjes së veprimeve standarde (hapja e një formulari, ekzekutimi i një komande standarde Write, etj.) të një formulari me detajet kryesore, konvertimi kryhet automatikisht.

Le të japim një shembull se si të përdorni transformimin e të dhënave në algoritmet tuaja.

Procedura &OnServer Kur CreateOnServer (Dështim, përpunim standard)

ObjectProduct = Directories.Products.FindByName("Coffeepot").GetObject(); ValueInFormData(ObjectItem, Object);

Fundi i procedurës

Procedura &OnClient Shkruaj()

WriteOnServer();

Fundi i procedurës

Procedura &OnServer WriteOnServer()

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

Fundi i procedurës

Objekti ManagedForm ka gjithashtu metoda të disponueshme në server:

  • ValueВFormAttribute() – konverton një objekt të llojit të aplikacionit në atributin e specifikuar të formës.
  • FormAttributeVValue() – konverton një atribut të të dhënave të formës në një objekt të një lloji aplikacioni.

Përdorimi i këtyre metodave është zakonisht më i përshtatshëm, pasi ato kanë, për shembull, informacion në lidhje me llojin e detajeve të formularit. Përveç kësaj, metoda Form AttributesValue() vendos korrespondencën midis të dhënave të formularit dhe objektit, i cili përdoret gjatë gjenerimit të mesazheve. Mund të lexoni më shumë rreth kësaj në kapitullin "Mundësitë e navigimit të shërbimit".

Le të japim një shembull të përdorimit të këtyre metodave.

Procedura &OnServer RillogaritjeOnServer()

// Konverton atributin Object në një objekt aplikacioni. Document = Form AttributesValue("Objekt"); // Kryen rillogaritjen duke përdorur metodën e përcaktuar në modulin e dokumentit. Document.Rillogaritje(); // Konverton përsëri objektin e aplikacionit në një mbështetës. ValueВFormAttributes (Dokument, “Objekt”);

Fundi i procedurës

Ndërfaqja e softuerit

FormDataTree

  • FindById
  • GetItems

Përshkrim:

Projektuar për të modeluar një pemë në të dhënat e formës së menaxhuar.

Ky objekt mund të serializohet në/nga XDTO. Lloji XDTO që korrespondon me këtë objekt përcaktohet në hapësirën e emrave. Emri i llojit XDTO:

GetItems

Sintaksë:

GetItems ()

Vlera e kthimit:

Lloji: Form DataCollection of Tree Elements.

Përshkrim:

Merr një koleksion të elementeve të pemës së nivelit të lartë.

Disponueshmëria: klienti, serveri, klienti i hollë, klienti në internet.

FindById

Sintaksë:

FindById(<Идентификатор>)

Opsione:

<Идентификатор>(kërkohet)

Lloji: Numri. Identifikuesi i elementit të pemës.

Vlera e kthimit:

Lloji:FormDataTreeElement.

Përshkrim:

Merr një element koleksioni me ID.

Disponueshmëria: klienti, serveri, klienti i hollë, klienti në internet.

FormDataTreeItem

Vetitë:

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

  • GetId (GetId)
  • GetParent
  • GetItems
  • Prona

Përshkrim:

Elementi i pemës së të dhënave të formës.

FormDataTreeItemCollection

Elementet e koleksionit: DataFormTreeElement

Për një objekt, është e mundur të përshkohet koleksioni duke përdorur operatorin Për secilin... Nga... Loop. Kalimi zgjedh elementet e koleksionit. Është e mundur të aksesoni një element koleksioni duke përdorur operatorin [...]. Indeksi i elementit kalohet si argument.

  • Fut
  • Shtoni
  • Indeksi (IndexOf)
  • Numëroni
  • Qartë
  • Marr
  • Lëvizni
  • Fshije

Përshkrim:

Koleksioni i elementeve prej druri.

Disponueshmëria: klienti, serveri, klienti i hollë, klienti në internet.

Shiko gjithashtu:

  • FormDataTreeElement, metoda GetElements
  • DataFormTree, metoda GetItems

Karakteristikat e punës me një pemë vlerash

Përditësimi i pemës

Ka një problem bie platformat kur përditësoni pemën.

Nëse ndonjë nyje në pemë është zgjeruar dhe një nyje vartëse është zgjedhur, atëherë kur përditësohet pema me funksionin ValueInFormData platforma bie.

Zgjidhja: Duhet të pastroni pemën përpara se ta përditësoni.

Për shembull:

&Në procedurën e serverit ClearTree(elemente) Për çdo element nga elementet Loop ClearTree(element.GetElements()); Cikli i Fundit; elementet.Clear(); Fundi i procedurës

&Në procedurën e serverit Plotësoni Pemën e Konceptit() dConcepts = srProperties.Build Concept Tree(OnDate, Meta.CurrentIB()); ClearTree(ConceptTree.GetItems()); ValueInFormData(dConcepts, ConceptTree); Fundi i procedurës

Procedura &OnClient OnDateOnChange(Element) Fill ConceptTree(); Fundi i procedurës

Platforma 1C:Enterprise ju lejon të shtoni dhe ndryshoni në mënyrë programore elementet e një forme të menaxhuar. Le të kuptojmë pse kjo mund të jetë e nevojshme.

Modifikimi i softuerit të formularit mund të kërkohet në disa raste:

  • Gjatë finalizimit të konfigurimeve standarde për të lehtësuar procedurën e mëvonshme të përditësimit. Në këtë rast, vetëm moduli i formularit do të ndryshohet. Modulet janë shumë më të lehta për t'u përditësuar sesa formularët.
  • Gjatë zbatimit të disa algoritmeve të zakonshme. Për shembull, në nënsistemin "Ndalimi i redaktimit të detajeve të objektit", një buton mund të krijohet në mënyrë programore për të gjitha objektet e lidhura me nënsistemin për të mundësuar mundësinë e redaktimit të detajeve.
  • Gjatë zbatimit të disa algoritmeve specifike. Për shembull, në drejtorinë Nomenklature, krijohen fusha për modifikimin e detajeve shtesë.

Në një formë të menaxhuar, ju mund të shtoni, ndryshoni dhe fshini në mënyrë programore:

  • kushtet;
  • ekipet lokale;
  • elementet.

Të gjitha këto operacione janë të mundshme vetëm në server.

Riformësimi programatik ka kufizime:

  • Mund të fshini vetëm detajet/komandat/elementet e shtuara në mënyrë programore. Nuk mund të fshini në mënyrë programore objektet e krijuara në konfigurues.
  • Nuk mund të caktoni një atribut si kryesor.

Ndryshimi i komandave të formularit

Për të menaxhuar përbërjen e komandave për një objekt Forma e menaxhuar ka një koleksion Ekipet

    Shtoni (< ИмяКоманды >)

    Sasi ()

    Gjej (< ИмяКоманды >)

    Fshije (< Команда >)

Koleksioni Teams është i disponueshëm si në klient ashtu edhe në server. Ju mund të ndryshoni koleksionin (metodat Add() dhe Delete()) vetëm në server. Mund të kërkoni dhe të merrni numrin e elementeve (metodat Find () dhe Count ()) si në klient ashtu edhe në server.

Si shembull i punës me komandat e formularit, le të krijojmë një komandë të re ChangeHistory me titullin "ChangeHistory...", i cili do të thërrasë mbajtësin Historia e shfaqjes(). Krijimi ndodh kur hapet forma.

&Në server
Procedura WhenCreatingOnServer (Dështim, përpunim standard)
Ekipi = Ekipet. Shto( "Historia e Ndryshimeve");
Ekipi . Veprimi = ;
Ekipi . Titulli = "Historia e ndryshimeve...";
Fundi i procedurës
&OnClient
Procedura Connectable_DisplayHistory(Komanda)
// veprimet komanduese
Fundi i procedurës

Trajtuesi i komandave duhet të jetë i vendosur në një formular dhe të ketë një direktivë përpilimi &OnClient.

Ndryshimi i detajeve të formularit

Leximi i përbërjes së detajeve të formularit kryhet nga funksioni Merrni detaje(< Путь >) duke kthyer një grup të tipit FormAttributes. Parametri i funksionit specifikon shtegun drejt atributit prind (si varg). Nëse parametri hiqet ose specifikohet një varg bosh, detajet e nivelit të lartë kthehen.

Ndryshimi i detajeve bëhet duke përdorur metodën Ndrysho Detajet(<Detaje të shtuara>, <Detaje të heqshme>) Objekt Forma e menaxhuar. Tek parametrat Detaje të shtuara Dhe Detaje të heqshme Transmetohen vargje me elemente të tipit Form Atributes.

Kujdes!

Procesi i ndryshimit të përbërjes së detajeve është mjaft intensiv me burime. Forma në të vërtetë po rikrijohet. Në këtë drejtim, puna me detajet e formularit kryhet në modalitetin e grupit.

Le të krijojmë një atribut të ri të formës me emrin Blerësi:


AddedDetails = Array i ri;
Detaje të shtuara. Shto (Atribute të reja të formës(“Blerësi”, Përshkrimi i llojit të ri (“DirectoryLink. Kundërpartitë”), “Klient”));

// Ndryshime në përbërjen e detajeve
);

Ndryshimi i elementeve të formës

Për të kontrolluar përbërjen e elementeve të një objekti Forma e menaxhuar ka një koleksion Elementet. Mbledhja ka disa mënyra:

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

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

    Sasi ()

    Gjej (< Имя >)

    Lëviz (< Элемент>, < Родитель>, < МестоРасположения >)

    Fshije (< Элемент >)

Koleksioni i Artikujve është i disponueshëm si në klient ashtu edhe në server. Modifikoni një koleksion (Fut metodat () , Shto () , Zhvendos () dhe Fshi () ) janë të disponueshme vetëm në server. Mund të kërkoni dhe të merrni numrin e elementeve (metodat Find () dhe Count ()) si në klient ashtu edhe në server. Elementet e koleksionit mund të jenë:

  • FormGroup;
  • FormTable;
  • FormField;
  • Butoni i formës.

Ju mund të caktoni programatikisht mbajtës të ngjarjeve për të formuar elementë. Metoda është menduar për këto qëllime SetAction(< ИмяСобытия>, < Действие >) .

Le të shohim disa nga shembujt më të zakonshëm të punës me komandat, detajet dhe elementët e formës.

Shtimi i një komande dhe butoni i lidhur me të:

// Krijo një komandë
Ekipi = Ekipet. Shto( "Historia e Ndryshimeve");
Ekipi . Veprim = "Plug-in_Display History"; // Formulari duhet të përmbajë një procedurë me emrin e specifikuar
Ekipi . Drejtimi = "Historia e ndryshimeve...";
// Krijoni një buton dhe shoqëroni atë me një komandë
Elementi = Artikuj. Shto( "Historia e Ndryshimeve", Type("FormButton" ));
Elementi.Emri i komandës = "Historia e Ndryshimeve";

Shtimi i një atributi dhe fushës së hyrjes përkatëse:

// Përshkrimi i detajeve të shtuara
AddedDetails = Array i ri;
Detaje të shtuara. Shtoni(Propa të reja të formularit ("Blerësi", Përshkrimi i llojit të ri ( "DirectoryLink. Kundërpartitë"), "Klient" ));
// Ndryshimi i përbërjes së detajeve
Ndrysho Detajet (Detajet e Shtuara);
// Krijimi i një fushe hyrëse dhe lidhja me atributet
Elementi = Artikuj. Add("Blerësi" , Lloji ("Fusha e formularit" ));
Elementi . Pamje = FormFieldView. Fusha e hyrjes;
Elementi . PathToData= "Blerësi" ;

Caktimi i një mbajtësi të ngjarjeve në një element formulari:

ArtikulliKlient. SetAction("Kur ndryshon" , "Connected_BuyerOnChange");

&OnClient
Procedura Connected_BuyerOnChange(Element)
// Veprimet e ngjarjes
Fundi i procedurës

Kujdes!

Procedurat që janë caktuar si mbajtës të ngjarjeve nga kodi duke përdorur metodën SetAction (), rekomandohet të vendosni prefiksin Connectable_.

Kujdes!

Mund ta shkarkoni përpunimin me shembuj të kërkimit programatik dhe ndryshimit të detajeve, komandave dhe elementeve të një forme të menaxhuar.

Detajet e formularit sigurojnë lidhjen e tij me të dhënat. Në këtë rast, një (dhe vetëm një) nga detajet mund të caktohet si kryesore; mund të mos jetë domosdoshmërisht lloji i të dhënave tek i cili po e tërheqim formularin. Por sjellja e formularit do të varet nga lloji i të dhënave të atributit kryesor. Përveç ndryshimit të sjelljes së formularit, ndryshon edhe konteksti i modulit të formularit. Së bashku me metodat dhe vetitë e formës, në të bëhen të disponueshme metodat dhe vetitë e objektit, që është vlera e atributit kryesor. Është e rëndësishme që formularët e tipit Forma e Lirë të mos kenë detaje bazë. Në këtë rast, sjellja e formularit përcaktohet vetëm nga cilësimet e përdoruesit. Le të shqyrtojmë pyetjet në lidhje me detajet themelore.

Pyetja 10.05 e provimit 1C: Platforma profesionale. Për çfarë përdoret atributi kryesor i formës?

  1. Përcakton burimin e të dhënave për formën në tërësi
  2. Përcakton aftësitë standarde të platformës për të punuar me formularin me të dhëna të llojit të specifikuar në atributin kryesor
  3. Për të ofruar aftësinë për të aksesuar në mënyrë programore detajet e objektit nga konteksti i formës lokale
  4. Ofron vizualizimin e detajeve të objektit në dialogun e formularit
  5. 2 dhe 3 janë të sakta
  6. 1 dhe 2 janë të sakta

Përgjigja e saktë është numri gjashtë, shih më lart.


Pyetja 10.06 e provimit 1C: Platforma profesionale. Për çfarë nevojiten detajet e formularit?
  1. Për të përshkruar përmbajtjen e të dhënave që shfaqen, modifikohen ose ruhen në një formë
  2. Për të shfaqur dhe modifikuar të dhënat në një formë
  3. 1 dhe 2 janë të sakta

Përgjigja e saktë është e treta - të dyja.

Pyetja 10.07 e provimit 1C: Platforma Professional. Për të caktuar atributet bazë në një formë të kontrolluar arbitrare...

  1. Duhet të kontrolloni kutinë "Detajet bazë" në vetitë e atributeve të formularit
  2. duhet të plotësoni vetinë “Data” të formularit duke zgjedhur atributin e kërkuar të formularit

Përgjigja e saktë është e dyta:

Pyetja 10.08 e provimit 1C: Platforma profesionale. Për të caktuar detajet kryesore në një formular të rregullt arbitrar...
  1. forma duhet të bëhet kryesore, detajet kryesore përcaktohen automatikisht
  2. Duhet të kontrolloni kutinë "Detajet bazë" në vetitë e atributeve të formularit
  3. duhet të shkoni te menyja "Redakto", "Detajet bazë" dhe të zgjidhni vlerën e dëshiruar
  4. duhet të plotësoni vetinë “Data” të formularit duke zgjedhur atributin e kërkuar të formularit

Përgjigja e katërt e saktë është:

Detajet kryesore janë theksuar me shkronja të zeza:

Pyetja 10.09 e provimit 1C: Platforma Professional. Nëse ka një atribut të formës kryesore, a është e mundur të shtohet një atribut tjetër kryesor?
  1. Kjo eshte e pamundur
  2. Është e mundur duke i caktuar vlerën e duhur veçorisë së atributit të formës
  3. Është e mundur vetëm në mënyrë programore, kur hyni në objektin "Forma".
  4. Kjo është e mundur duke shtuar një vlerë tjetër në vetinë përkatëse të formës

Përgjigja e saktë është e para, ekziston rreptësisht një kusht kryesor, sepse lidhja me objektin duhet të jetë e paqartë.

Pyetja 10.113 e provimit 1C: Platforma profesionale. Cili nga detajet e formularit të paraqitur në figurë është kryesori?

  1. Lista e normave të valutës
  2. Objekti i Drejtorisë
  3. Formularët e drejtorive nuk kanë detaje themelore
  4. Formularët e drejtorive kanë të gjitha detajet themelore
Përgjigja e dytë e saktë është ajo me shkronja të zeza.

Forma kontrollohet përmes elementëve të ndryshëm të formës, të cilët ndodhen në mënyrë hierarkike në skedë Elementet dizajner formash. Elementi më i rëndësishëm është vetë forma, e cila ndodhet në krye të hierarkisë së elementeve, dhe elementët e mbetur janë në varësi të saj.

Të gjithë elementët e formës mund të ndahen në pesë grupe: fusha, elemente grupimi, butona, dekorime dhe tabela. Në artikujt e mi do të analizoj secilin nga grupet. Në këtë artikull, ne do të fillojmë të studiojmë një nga llojet e elementit të fushës - fusha e hyrjes, por para kësaj do të mësojmë se si të shtojmë një element në formular.

Shtimi i elementeve në një formë

Kjo është bërë mjaft thjesht: ju duhet të zgjidhni elementin Forma në dritaren Form Design Elements dhe klikoni butonin "Shto". Pas kësaj, do të hapet një dritare në të cilën ju duhet të zgjidhni llojin e dëshiruar të elementit

Pas zgjedhjes, elementi i dëshiruar do të shfaqet në dritare Elementet.

Elementi i formës së menaxhuar Fusha

Le të shohim një element të formës së menaxhuar Fusha. Ky element është i nevojshëm për të futur informacione në formular. Dhe gjithashtu për të shfaqur çdo informacion. Pasi ta shtoni këtë element në formular, paleta e vetive të elementit të formës do të hapet në të djathtë. Tani për tani, duhet të jeni të interesuar për dy veti - DataPath dhe View.

Në veçorinë DataPath, zhvilluesi mund të shoqërojë një element formulari me atributin e dëshiruar të formës. Ju lutemi vini re se pasi të jetë shtuar elementi Fusha e hyrjes në formular nuk u shfaq në vetë formularin. Kjo ndodhi sepse elementi ynë i ri nuk është i lidhur me . Për shembull, kam krijuar disa atribute në formën e përpunimit me lloje të ndryshme primitive dhe një atribut me një lloj referimi.

Tani le të lidhim elementin tonë të formës së shtuar së fundi me një nga detajet. Për ta bërë këtë, zgjidhni atributin e dëshiruar nga vetia PathKData e elementit.

Pas kësaj, vetitë DataPath dhe View do të plotësohen dhe vetë elementi do të shfaqet në pamjen e formularit.

Kushtojini vëmendje veçorisë së elementit Pamje. Kjo veti përcakton funksionalitetin e fushës së hyrjes. Ju mund të zgjidhni vlera të ndryshme për këtë pronë.

Në varësi të vlerës së zgjedhur, do të përcaktohet funksionaliteti. Në figurat e mësipërme, vlera e zgjedhur është - fusha e hyrjes, d.m.th. ne mund të fusim çdo vlerë në këtë fushë hyrëse dhe nëse zgjedhim një vlerë fushën e etiketës, atëherë nuk do të mund të futim asgjë.

Kjo vlerë e pronës Pamje Fushat e hyrjes janë të përshtatshme për t'u zgjedhur kur thjesht duhet t'i shfaqni informacionet e ndihmës përdoruesit.

Tani le të shtojmë një element të ri të formës me tip Fusha e hyrjes dhe lidheni atë me mbështetëset DetajetData përmes veçorisë tashmë të njohur për ne DataPath

Siç mund ta shihni, pamja e fushës së hyrjes ka ndryshuar dhe zgjedhja e mundshme e vlerave për veçorinë View do të ndryshojë gjithashtu.

Kështu, arrijmë në përfundimin se funksionaliteti i fushës hyrëse varet nga lloji i atributit.

Për rekuizita me tip Boolean Vlerat e mëposhtme të pronës View do të jenë të disponueshme.

Dhe për atributet me një lloj referimi, vlera të tjera të pronës View do të jenë të disponueshme.

Puna më e detajuar me elementët e formës duke përdorur shembuj praktikë është dhënë në librin "Bazat e zhvillimit në 1C: Taxi. Zhvillimi i menaxhuar i aplikacionit në 12 hapa".

Ndonjëherë duket se mësimi i gjuhës së programimit në 1C është i ndërlikuar dhe i vështirë. Në fakt, programimi në 1C është i lehtë. Librat e mi do t'ju ndihmojnë të zotëroni shpejt dhe lehtë programimin në 1C: dhe "Bazat e zhvillimit në 1C: Taxi"

Mësoni programimin në 1C me ndihmën e librit tim "Programimi në 1C në 11 hapa"

  1. Nuk ka kushte të komplikuara teknike.
  2. Mbi 700 faqe material praktik.
  3. Çdo detyrë shoqërohet me një vizatim (screenshot).
  4. Një koleksion problemesh për detyrat e shtëpisë.
  5. Libri është shkruar në gjuhë të qartë dhe të thjeshtë - për një fillestar.

Ky libër është i përshtatshëm për ata që tashmë kanë filluar programimin dhe po përjetojnë vështirësi të caktuara me këtë temë dhe për ata që programojnë për një kohë të gjatë, por nuk kanë punuar kurrë me forma të menaxhuara 1C.

  1. Pa terma komplekse teknike;
  2. Më shumë se 600 faqe material praktik;
  3. Çdo shembull shoqërohet me një vizatim (screenshot);
  4. Libri dërgohet me email në formatin PDF. Mund të hapet në çdo pajisje!

Kodi promovues për një zbritje prej 15% - 48PVXHeYu


Nëse ky mësim ju ndihmoi të zgjidhni ndonjë problem, ju pëlqeu ose ju duk i dobishëm, atëherë mund ta mbështesni projektin tim duke dhuruar çdo shumë:

Ju mund të paguani manualisht:

Yandex.Money - 410012882996301
Paratë në ueb - R955262494655

Bashkohuni me grupet e mia.

Dhe objekti i transferimit të të dhënave në strukturimin e kodit, formë e kontrolluar në mjedisin 1C 8.2.

Prezantimi

Le të fillojmë me një përshkrim të shkurtër të konceptit të "formës së menaxhuar" dhe koncepteve të lidhura me platformën 1C. Njohësit e platformës mund të dëshirojnë ta kapërcejnë këtë seksion.

Në vitin 2008, u bë i disponueshëm një version i ri i platformës 1C: Enterprise 8.2 (në tekstin e mëtejmë: Aplikacioni i Menaxhuar), i cili ndryshon plotësisht të gjithë shtresën e punës me ndërfaqen. Kjo përfshin ndërfaqen e komandës, formularët dhe sistemin e dritareve. Në të njëjtën kohë, jo vetëm që ndryshon modeli për zhvillimin e ndërfaqes së përdoruesit në konfigurim, por gjithashtu propozohet një arkitekturë e re për ndarjen e funksionalitetit ndërmjet aplikacionit të klientit dhe serverit.
Aplikacioni i menaxhuar mbështet llojet e mëposhtme të klientëve:

  • Klient i trashë (modaliteti i lëshimit normal dhe i menaxhuar)
  • Klient i hollë
  • Klient në ueb
Aplikacioni i menaxhuar përdor formularë të ndërtuar mbi teknologjinë e re. Ata janë quajtur Format e menaxhuara. Për të lehtësuar tranzicionin, mbështeten edhe format e mëparshme (të ashtuquajturat forma të rregullta), por funksionaliteti i tyre nuk është zhvilluar dhe ato janë të disponueshme vetëm në modalitetin e nisjes së klientit të trashë.
Dallimet kryesore të formave të menaxhuara për një zhvillues:
  • Përshkrimi deklarativ, jo "piksel pas piksel" i strukturës. Vendosja specifike e elementeve kryhet automatikisht nga sistemi kur shfaqet forma.
  • I gjithë funksionaliteti i formularit përshkruhet si detajet Dhe ekipet. Detajet janë të dhënat me të cilat funksionon forma, dhe komandat janë veprimet që duhen kryer.
  • Formulari funksionon si në server ashtu edhe në klient.
  • Në kontekstin e klientit, pothuajse të gjitha llojet e aplikacioneve nuk janë të disponueshme, dhe në përputhje me rrethanat është e pamundur të ndryshohen të dhënat në bazën e informacionit.
  • Për secilën metodë ose variabël të formës, ajo duhet të specifikohet direktiva e përpilimit, duke përcaktuar vendndodhjen e ekzekutimit (klientin ose serverin) dhe aksesin në kontekstin e formularit.
Le të rendisim direktivat për përpilimin e metodave të formularit:
  • &OnClient
  • &Në server
  • &NëServer Pa Kontekst
  • &OnClientOnServerPa Kontekst
Le të ilustrojmë sa më sipër. Pamja e ekranit tregon një shembull të një forme të menaxhuar dhe modulin e saj në modalitetin e zhvillimit. Gjeni përshkrimin deklarativ, rekuizitat, direktivat e përpilimit, etj.

Të gjitha diskutimet e mëtejshme do të jenë në lidhje me anën e djathtë të ilustrimit, se si të strukturoni kodin e modulit dhe cilat parime do t'ju lejojnë të zbatoni ndërveprim efektiv klient-server.

Le të përcaktojmë problemin

Kanë kaluar disa vite që kur versioni i ri i platformës 1C është përdorur në mënyrë aktive dhe shumë zgjidhje (konfigurime) janë lëshuar si nga 1C ashtu edhe nga partnerët e tij të shumtë.
Gjatë kësaj kohe, a kanë zhvilluar zhvilluesit një kuptim të përbashkët të parimeve të ndërveprimit klient-server gjatë krijimit të formularëve dhe a ka ndryshuar qasja për zbatimin e moduleve softuerike në realitetet e reja arkitekturore?

Le të shohim strukturën e kodit (modulin e formës) në disa forma të të njëjtit konfigurim standard dhe të përpiqemi të gjejmë modele.
Me strukturë nënkuptojmë seksione të kodit (më shpesh këto janë blloqe komentesh) të alokuara nga zhvilluesi për të grupuar metodat dhe direktivat e kompilimit për këto metoda.
Shembulli 1:
Seksioni i trajtuesve të ngjarjeve Metoda - në klient Metoda - në server Metoda - në klient Seksioni i procedurave dhe funksioneve të shërbimit Funksionet ndihmëse të kontrollit të hyrjes
Shembulli 2:
Procedurat dhe funksionet e shërbimit Dokumentet e pagesave Vlerat Trajtuesit e ngjarjeve
Shembulli 3:
Procedurat e shërbimit në server Procedurat e shërbimit në klient Procedurat e shërbimit në server pa kontekst Trajtuesit e ngjarjeve të kokës Trajtuesit e ngjarjeve të komandave
Shembulli 4:
Procedurat për qëllime të përgjithshme Trajtuesit e ngjarjeve të formularit Procedurat e nënsistemit të "informacionit të kontaktit"
Në thelb, struktura e kodit mungon, ose për ta thënë butë, është e ngjashme me atë që ishte në Formularët 8.1:

  • Fjalë jo informative “Gjeneral, Shërbimi, Ndihmës”.
  • Përpjekje të turpshme për të ndarë metodat e klientit dhe serverit.
  • Metodat shpesh grupohen sipas elementeve të ndërfaqes "Puna me pjesën tabelare Produktet, Informacioni i kontaktit".
  • Rregullimi arbitrar i metodave dhe grupeve të kodeve. Për shembull, Event Handlers mund të jenë në krye në një formë, në fund në një tjetër, të mos theksohen fare në një të tretë, etj.
  • Dhe të mos harrojmë se kjo është e gjitha brenda një konfigurimi.
  • Po, ka konfigurime në të cilat fjalët "Gjeneral, Shërbimi, Ndihmës" janë gjithmonë në të njëjtat vende, por...
Pse keni nevojë për strukturën e kodit?
  • Thjeshtimi i mirëmbajtjes.
  • Thjeshtoni mësimin.
  • Regjistrimi i parimeve të përgjithshme/të rëndësishme/të suksesshme.
  • ...opsioni juaj
Pse nuk ndihmon standardi ekzistues i zhvillimit nga 1C?
Le të shohim parimet e publikuara në disqet e ITS dhe në "Udhëzuesit e Zhvilluesve..." të ndryshëm që rekomandohen kur shkruani një formular të menaxhuar.
  • Minimizoni numrin e thirrjeve të serverit.
  • Llogaritja maksimale në server.
  • Thirrjet jokontekstuale të serverit janë më të shpejta se ato kontekstuale.
  • Program me komunikimin klient-server në mendje.
  • e kështu me radhë.
Këto janë slogane që janë absolutisht të vërteta, por si t'i zbatojmë ato? Si të minimizoni numrin e thirrjeve, çfarë do të thotë të programoni në modalitetin klient-server?

Modele të projektimit ose mençuri brezash

Ndërveprimi klient-server është përdorur në teknologji të ndryshme softuerike për dekada. Përgjigja e pyetjeve të përshkruara në pjesën e mëparshme ka qenë prej kohësh e njohur dhe është përmbledhur në dy parime bazë.
  • Fasada në distancë(në tekstin e mëtejmë referuar si Ndërfaqja e Qasjes në distancë)
  • Objekti i transferimit të të dhënave(në tekstin e mëtejmë: Objekt i transferimit të të dhënave)
Një fjalë nga Martin Fowler, përshkrimi i tij i këtyre parimeve:
  • … Çdo objekt potencialisht i destinuar për qasje në distancë duhet të ketë ndërfaqe me granularitet të ulët, i cili do të minimizojë numrin e thirrjeve të nevojshme për të kryer një procedurë specifike. ... Në vend që të kërkoni një faturë dhe të gjithë artikujt e saj veçmas, ju duhet të lexoni dhe përditësoni të gjithë artikujt e faturës në një kërkesë. Kjo ndikon në të gjithë strukturën e objektit...Mos harroni: ndërfaqja e aksesit në distancë nuk përmban logjikën e domenit.
  • Nëse do të isha një nënë e kujdesshme, patjetër do t'i thoja fëmijës tim: "Mos shkruani kurrë objekte të transferimit të të dhënave!" Në shumicën e rasteve, objektet e transferimit të të dhënave nuk janë asgjë më shumë se komplet fushash të fryra... Vlera e këtij përbindëshi të neveritshëm qëndron vetëm në mundësinë transmetojnë informacione të shumta në rrjet në një telefonatë- një teknikë që ka një rëndësi të madhe për sistemet e shpërndara.
Shembuj të shablloneve në platformën 1C
Ndërfaqja e programimit të aplikacionit në dispozicion të zhvilluesit kur zhvillon një formular të menaxhuar përmban shumë shembuj të këtyre parimeve.
Për shembull, metoda OpenForm(), një ndërfaqe tipike "e përafërt".
OpeningParameters = Struktura e re ("Parameter1, Parameter2, Parameter3", Vlera1, Vlera2, Vlera3); Forma = OpenForm(Emri i Formës, Parametrat e Hapjes);
Krahasoni me stilin e miratuar në v8.1.
Forma = GetForm(FormName); Forma.Parametri1 = Vlera1; Forma.Parametri2 = Vlera2; Forma.Open();

Në kontekstin e një formulari të menaxhuar, ka shumë "Objekte të Transferimit të të Dhënave". Ju mund të zgjidhni sistemike Dhe të përcaktuara nga zhvilluesi.
Ato të sistemit modelojnë një objekt aplikacioni në klient, në formën e një ose më shumë elementeve të të dhënave të formës. Është e pamundur të krijohen ato pa iu referuar detajeve të formularit.

  • DataFormsStructure
  • DataFormsCollection
  • DataFormStructureWithCollection
  • DataShapesTree
Konvertimi i objekteve të transferimit të të dhënave të sistemit në llojet e aplikacioneve dhe anasjelltas kryhet duke përdorur metodat e mëposhtme:
  • ValueInFormData()
  • FormDataValue()
  • CopyFormData()
  • ValueInFormAttributes()
  • FormAttributesValue()
Shpesh, konvertimi i qartë përdoret kur përshtatet një zgjidhje ekzistuese. Metodat mund të presin (përdorin veçori) parametra hyrës, të tillë si ValueTable dhe jo FormDataCollection, ose metoda është përcaktuar në kontekstin e një objekti aplikacioni dhe është bërë e padisponueshme për thirrje direkte nga formulari.
Shembulli 1C v8.1:
// në klient në kontekstin e formularit FillUserCache(DepartmentLink)
Shembulli 1C v8.2:
// në server në kontekstin e formës ProcessingObject = Form AttributesValue("Object"); ProcessingObject.FillUserCache(DepartmentRef); ValueВFormAttributes(ProcessingObject, "Object");

Objektet e transferimit të të dhënave, struktura e të cilave përcaktohet nga zhvilluesi, janë një nëngrup i vogël i llojeve të disponueshme si në klient ashtu edhe në server. Më shpesh, sa më poshtë përdoren si parametra dhe rezultate të metodave të një ndërfaqeje "të trashë":

  • Llojet primitive (varg, numër, boolean)
  • Struktura
  • Korrespondencë
  • Array
  • Lidhje me objektet e aplikacionit (identifikues unik dhe përfaqësim teksti)
Shembull: metoda pranon një listë porosish për të ndryshuar statusin dhe i kthen klientit një përshkrim të gabimeve.
&OnServerWithoutContext Funksioni ServerChangeOrderStatus(Orders, NewStatus) Gabime = Përputhje e re(); // [porosi][përshkrimi i gabimit] Për Çdo Porosi Nga Porositë Cikli StartTransaction(); Provoni DocOb = Order.GetObject(); …. veprime të tjera, të mundshme jo vetëm me porosinë... Përjashtim CancelTransaction(); Gabimet.Insert(Rend, ErrorDescription()); Përpjekja e Fundit; Cikli i Fundit; Gabim në kthim; FundFunksioni //Statusi i ndryshimit të Serverit()

Strukturimi i kodit

Qëllimet kryesore që moduli i formës së menaxhuar duhet të pasqyrojë dhe i afrohet zgjidhjes.
  • Ndarja e qartë e kodit të klientit dhe serverit. Të mos harrojmë se në momentin e ekzekutimit këto janë dy procese ndërvepruese, secila prej të cilave ka funksione të disponueshme dukshëm të ndryshme.
  • Identifikimi i qartë i ndërfaqes së qasjes në distancë, cilat metoda të serverit mund të thirren nga klienti dhe cilat jo? Emrat e metodave të ndërfaqes në distancë fillojnë me prefiksin "Server". Kjo ju lejon të shihni menjëherë transferimin e kontrollit në server gjatë leximit të kodit dhe thjeshton përdorimin e ndihmës kontekstuale. Vini re se rekomandimi zyrtar (ITS) sugjeron emërtimin e metodave me postfikse, për shembull, ChangeOrderStatusOnServer(). Sidoqoftë, ne përsërisim se jo të gjitha metodat e serverit mund të thirren nga klienti, dhe për këtë arsye aksesueshmëria logjike është më e rëndësishme sesa vendndodhja e përpilimit. Prandaj, me prefiksin "Server" ne shënojmë vetëm metodat e disponueshme për klientin; le të quajmë metodën shembull ServerChangeOrderStatus().
  • Lexueshmëria. Një çështje shije, ne pranojmë urdhrin kur moduli fillon me procedurat për krijimin e një formulari në server dhe metodat e aksesit në distancë.
  • Mirëmbajtja. Duhet të ketë një vend të qartë për shtimin e kodit të ri. Një pikë e rëndësishme është që shabllonet e metodave të krijuara automatikisht nga konfiguruesi shtohen në fund të modulit. Meqenëse mbajtësit e ngjarjeve për elementët e formës më së shpeshti krijohen automatikisht, blloku përkatës ndodhet i fundit, në mënyrë që të mos tërhiqet secili mbajtës në një vend tjetër në modul.
Më poshtë është struktura bazë e modulit që zbaton qëllimet e listuara.
  • Opsioni grafik - tregon qartë rrjedhën kryesore të ekzekutimit.
  • Opsioni i tekstit është një shembull i një modeli shabllon për futjen e shpejtë të një strukture në një modul të ri formulari.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор=""Data=""/> // <Описание> // // ///////////////////////////////////////////////////////////////// ////////////////////////// // VARIABLAT E MODULIT ///////////////// // /////////////////////////////////////////////////////////////////////// ////////// // NË SERVER //******* NGJARJET NË SERVER ******* &Në procedurën e serverit kur krijohen në server (Dështim, përpunim standard) / /Fut përmbajtjen e mbajtësit Fundi i procedurës //******* NDËRFAQJA E QASJES REMOTE ******* //******** LOGJIA E BIZNESIT NË SERVER ******* ///////// ////////////////////////////////////////////////////////// /////// /////////////////// // METODAT E PËRBASHKËTA TË KLIENTIT DHE SERVERIT /////////////// /////// //////////////////////////////////////////////////////////// ///// //////// // PËR KLIENTIN //******* LOGJIKA E BIZNESIT MBI KLIENTIN ******* //******** EKIPI * ****** //******** NGJARJET E KLIENTIT ******* ////////////////////////// ///// ////////////////////////////////////////////////////////////// // / / OPERATORËT KRYESORË TË PROGRAMIT

Pyetje të lidhura
Si përfundim, ne do të përshkruajmë disa fusha që janë të dobishme për t'u menduar gjatë programimit të ndërveprimit klient-server.
  • Opsionet e zbatimit të ndërfaqes së qasjes në distancë. Asinkronia, niveli i detajeve...
  • Caching. 1C mori një vendim arkitektonik të pasuksesshëm, duke futur caching vetëm në nivelin e metodave të thirrjes së moduleve të zakonshme dhe duke mos ofruar aftësi kontrolli (koha e rëndësisë, rivendosja sipas kërkesës).
  • Thirrjet e nënkuptuara të serverit. Mos harroni për veçoritë teknologjike; shumë operacione "të padëmshme" në klient provokojnë platformën të kontaktojë serverin.


Publikime të ngjashme