në shtëpi » Sport » Çelësat, aplikimi i rregullt, formularët e menaxhuar. Çelësat, aplikimi i rregullt, format e menaxhuara 1c probleme me format e menaxhuara

Çelësat, aplikimi i rregullt, formularët e menaxhuar. Çelësat, aplikimi i rregullt, format e menaxhuara 1c probleme me format e menaxhuara

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ërpalët"), "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 të shkarkoni përpunimin me shembuj të kërkimit programatik dhe ndryshimit të detajeve, komandave dhe elementeve të një forme të menaxhuar.

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.

Formularët në 1C: Enterprise janë të destinuara për shfaqjen dhe modifikimin e informacionit të përmbajtur në bazën e të dhënave. Formularët mund t'i përkasin objekteve specifike të konfigurimit ose ekzistojnë veçmas prej tyre dhe përdoren nga e gjithë zgjidhja e aplikacionit.

Për shembull, një drejtori Nomenklatura mund të ketë disa forma që do të përdoren për qëllime specifike - redaktimi i një elementi drejtorie, shfaqja e një liste, etj.:

Së bashku me këtë, mund të ketë forma të përgjithshme që nuk i përkasin objekteve specifike të konfigurimit - forma të përgjithshme.

Format bazë

Çdo objekt konfigurimi mund të përdoret për të kryer disa veprime standarde. Për shembull, për çdo drejtori mund t'ju duhet të shfaqni një listë të elementeve të tij, të shfaqni elementë individualë të drejtorisë, të shfaqni një grup drejtorie, të zgjidhni elemente dhe grupe elementesh nga drejtoria. Për çdo dokument, lista e veprimeve të tilla do të jetë shumë më e vogël: shikimi i një liste dokumentesh, përzgjedhja nga një listë dokumentesh dhe shikimi i një dokumenti të veçantë.

Për të siguruar që veprime të tilla standarde të kryhen me të dhënat e objekteve të zgjidhjes së aplikimit, për secilën prej tyre ekziston një grup formash bazë që do të përdoren gjatë kryerjes së veprimeve përkatëse. Cilido nga format në varësi të këtij objekti mund të caktohet si kryesor. Për shembull, në drejtori Nomenklatura Mund të ekzistojnë format e mëposhtme themelore:

Dhe dokumenti Pranimi i mallrave dhe shërbimeve përbërja e formave kryesore do të jetë e ndryshme:

Kështu, nëse përdoruesi dëshiron të shikojë listën e drejtorive Nomenklatura ose listën e dokumenteve Pranimi i mallrave dhe shërbimeve, sistemi do të hapë formularin përkatës të caktuar si formulari i listës për këto objekte.

Format e gjeneruara automatikisht

Një tipar i rëndësishëm i sistemit 1C:Enterprise 8 është mekanizmi i formave të gjeneruara automatikisht. Ky mekanizëm e çliron zhvilluesin nga nevoja për të krijuar të gjitha format e mundshme për çdo objekt konfigurimi. Zhvilluesi duhet vetëm të shtojë një objekt të ri konfigurimi dhe vetë sistemi do të gjenerojë, në momentet e duhura në punën e përdoruesit, format e nevojshme për të shfaqur informacionin që përmban ky objekt.

Kështu, zhvilluesi duhet të krijojë format e tij të objekteve të zgjidhjes së aplikimit vetëm nëse ato duhet të kenë dallime (dizajn të ndryshëm ose sjellje specifike) nga format e gjeneruara automatikisht nga sistemi.

Lidhja e një formulari me të dhënat

Nëse një formë i përket një objekti të caktuar konfigurimi nuk përcakton përbërjen e të dhënave që shfaqen në formë. Fakti që forma i përket, për shembull, një drejtorie Nomenklatura, ju lejon ta caktoni atë si një nga format kryesore për këtë direktori, por nuk përcakton në asnjë mënyrë se çfarë të dhënash do të shfaqë ky formular dhe si do të jetë sjellja e tij.

Për të lidhur një formular me të dhënat, përdoren detajet e formularit, të cilat tregojnë listën e të dhënave të shfaqura nga formulari. Të gjitha format, vetë, kanë të njëjtën sjellje, pavarësisht se çfarë të dhënash shfaqin. Sidoqoftë, një nga atributet e formës mund të caktohet si atributi kryesor për të (është theksuar me shkronja të zeza), me ç'rast sjellja standarde e formës dhe vetitë e saj do të plotësohen në varësi të llojit të atributit të formës kryesore:

Për shembull, nëse një dokument caktohet si atributi kryesor i formës Pranimi i mallrave dhe shërbimeve, atëherë me mbylljen e formularit, sistemi do të kërkojë konfirmimin e regjistrimit dhe postimit të këtij dokumenti. Nëse caktoni, të themi, një direktori si atributin kryesor të formularit Nomenklatura, atëherë një kërkesë e tillë konfirmimi nuk do të shfaqet kur mbyllet formulari.

Struktura e formës

Tipari kryesor i formularëve është se ato nuk vizatohen nga zhvilluesi në detaje, "piksel pas piksel". Një formë në një konfigurim është një përshkrim logjik i përbërjes së formularit. Dhe vendosja specifike e elementeve kryhet automatikisht nga sistemi kur shfaqet forma.

Pjesa e shfaqur e formularit (e dukshme për përdoruesin) përshkruhet si një pemë që përmban elemente të formës.

Elementet mund të jenë fushat e hyrjes, kutitë e kontrollit, butonat e radios, butonat, etj. Për më tepër, një element mund të jetë një grup që përfshin elementë të tjerë. Një grup mund të përfaqësohet si një panel me një kornizë, një panel me faqe (shënues), një faqe në vetvete ose një panel komandimi. Përveç kësaj, elementi mund të jetë një tabelë, e cila gjithashtu përfshin elemente (kolona). Struktura e elementit përshkruan se si do të duket forma.

I gjithë funksionaliteti i formularit përshkruhet në formën e detajeve dhe komandave. Detajet janë të dhënat me të cilat funksionon forma, dhe komandat janë veprimet që duhen kryer. Kështu, zhvilluesi në redaktuesin e formularit duhet të përfshijë detajet dhe komandat e nevojshme në formular, të krijojë elementë të formës që i shfaqin ato dhe, nëse është e nevojshme, t'i rregullojë elementet në grupe.

Bazuar në këtë përshkrim logjik, sistemi gjeneron automatikisht pamjen e formularit për t'i shfaqur përdoruesit. Në këtë rast, sistemi merr parasysh vetitë e ndryshme të të dhënave të shfaqura (për shembull, llojin) në mënyrë që të rregullojë elementët e formularit sa më të përshtatshëm për përdoruesin.

Zhvilluesi mund të ndikojë në rregullimin e elementeve me cilësime të ndryshme. Mund të përcaktojë rendin e elementeve, të specifikojë gjerësinë dhe lartësinë e dëshiruar. Megjithatë, ky është vetëm disa informacione shtesë për të ndihmuar sistemin të shfaqë formularin.

Në forma, zhvilluesi mund të përdorë jo vetëm komandat e vetë formularit, por edhe komandat globale të përdorura në ndërfaqen e komandës së të gjithë konfigurimit. Përveç kësaj, është e mundur të krijohen komanda të parametrizueshme që do të hapin forma të tjera duke marrë parasysh të dhënat specifike të formularit aktual. Për shembull, kjo mund të jetë thirrja e një raporti mbi bilancet në magazinë që është përzgjedhur aktualisht në formularin e faturës.

Të gjithë e dimë që kompania 1C kishte shumë versione të ndryshme të platformës 1C; tani do të jemi të interesuar për një nga versionet më të fundit në kohën e shkrimit të këtij artikulli, këto janë versionet 1C 8.2 dhe 1C 8.3. Nëse ju është dashur të punoni në të dyja këto versione, atëherë ka shumë të ngjarë vërejti dallime në ndërfaqet e këtyre versioneve, për përdoruesit ato ndryshojnë vetëm në pamje. Në thelb një zgjedhje aplikim i rregullt ose i menaxhuar i tregon sistemit se cilat forma të shfaqen për të ekzekutuar, të rregullta ose të kontrolluara, si dhe cili klient aplikacioni do të përdoret si parazgjedhje, i trashë apo i hollë. Për informacion më të detajuar mbi klientët, lexoni artikullin "Cilët janë klientët e trashë dhe të hollë në 1C, si dhe ndryshimet e tyre".

Aplikim i rregullt 1C (forma të rregullta, ndërfaqe e rregullt, versioni 1C 8.2)

Në 1C 8.2 është e mundur të punohet vetëm me forma të rregullta, në modalitetin e rregullt të aplikimit. Imazhi më poshtë tregon bazën e të dhënave në mënyrën e funksionimit "aplikimi i rregullt 1C" (forma të rregullta).

Aplikacioni i menaxhuar 1C (formularët e menaxhuar, ndërfaqja e menaxhuar, versioni 1C 8.3)

Në platformën 1C 8.3 ne mund të punojmë si me format e rregullta (në modalitetin e pajtueshmërisë) ashtu edhe me ato të menaxhuara. Për më tepër format e menaxhuara kanë dy lloje të ekranit, ky është standard dhe taksi. Një shembull i një konfigurimi 1C 8.3 me forma standarde të menaxhuara tregohet më poshtë, dhe pas tij shfaqet ndërfaqja "Taxi".

Cili është ndryshimi midis një aplikacioni të rregullt dhe të menaxhuar 1C?

Siç kemi zbuluar tashmë një aplikacion i rregullt dhe një aplikacion i menaxhuar janë këto lloje të nisjes së një programi 1C. Për më tepër, në varësi të vlerës së llojit të nisjes 1C ( aplikim i rregullt ose i menaxhuar), një ndërfaqe specifike do të ngarkohet si parazgjedhje ( forma të rregullta ose të menaxhuara), prandaj ka kaq shumë sinonime për këtë koncept. Ne dëshirojmë të theksojmë se ndryshimet në ndërfaqet janë mjaft domethënëse; ndërfaqja e menaxhuar është ridizajnuar plotësisht. Në parim, këto janë të gjitha ndryshimet që shohin përdoruesit e zakonshëm të programit 1C. Sa për programuesit, ndërfaqja e menaxhuar kërkon shkrimin e kodit të modifikuar, sepse zhvillimi është kryer tashmë në 1C 8.3, dhe jo në 1C 8.2, pra të gjitha pasojat që pasojnë. Kodi duhet gjithashtu të ndahet në klient dhe server; kjo tregohet duke përdorur direktivat përkatëse në konfigurues.

Klyuev V.V.

http://prof1c.kklab.ru

PUNA ME NDELES

Ju lutemi merrni parasysh të gjithë përdoruesit e shërbimit të faqes - Unë postoj materiale në seksionin Fillestar!!!

8.2 Format e menaxhuara

Ndërsa studiojnë sjelljen e formave të menaxhuara, programuesit ose zhvilluesit e ndërfaqes ballafaqohen me pyetjen se ku janë ndërprerësit në format e menaxhuara dhe si t'i shtojnë ato në formë. Është një gjë e vogël, por është e pakëndshme që harxhohet shumë kohë për gjëra të tilla të vogla, megjithëse kjo kohë mund të shpenzohet për zhvillimin dhe optimizimin e algoritmit, në vend që të hartohet forma.

Pra, le të krijojmë një konfigurim bosh për të kuptuar pyetjen, ose të zgjedhim ndonjë tipik.
Shkoni te grupi që përmban drejtoritë dhe shtoni një drejtori të re për të eksperimentuar. Dua të vërej se konfigurimi duhet të ketë modalitetin kryesor të nisjes - Aplikacioni i menaxhuar.

Pra, le të krijojmë një direktori të re dhe të shtojmë atributin "Property1", me llojin "Boolean"

Tani le të shkojmë te skeda Forms dhe të shtojmë një formë të re.

Pra, forma e kontrolluar është krijuar, tani le të punojmë me formularin dhe të gjejmë se ku ndodhet çelësi.
Këtu është forma jonë, dhe mbi të shohim rekuizitat tona, por në formën e një flamuri

Pra, çfarë kemi bërë gabim?
Le të shohim vetitë e mbështetësve për të parë nëse ka një ndryshim në llojin e kontrollit.
Dhe ne shohim që fusha Switch nuk është këtu! (Ku gabuam?

Me sa duket, lloji i kontrollit në formular varet nga lloji i të dhënave, le të kthehemi te vetitë e formularit, përkatësisht skeda e detajeve dhe të ndryshojmë vetitë e atributit tonë - përkatësisht llojin e tij "Boolean", në llojin "Numër". “.

Tani le të kthehemi te vetitë e kontrollit dhe të kontrollojmë nëse Pamja e kontrollit është shtuar në vetitë e tij - - - Dhe urah, ne shohim pamjen atje - Switch Field.

Tani shikoni formën, çfarë shohim:

Ne shohim - 3 vlera të paracaktuara, 3 çelsat, por na duhen dy prej tyre, shkoni përsëri te vetitë e atributit dhe shikoni vetitë "Numri i kolonave" atje

Për 2 - vendosni numrin e kolonave - 2.

Kjo mund të ndalojë pak një programues të lodhur)), por tani edhe ai dhe ne e dimë këtë!

8.2 Forma të rregullta.

I mërzitshëm me çelsat në forma të zakonshme.
Ka momente të tilla, dhe ato ndodhin) kur ju duhet të modifikoni një formë të gatshme, e cila tashmë ka disa çelësa, dhe ju duhet të shtoni një ndërprerës tjetër në këtë formë. Këtu lind një lloj lodhjeje, e cila kërkon shumë kohë, dhe jo kohë për programimin e kodit - por humbje kohe për t'i shfaqur përdoruesit këta ndërprerës.

Pra, le të shohim një shembull. Ekziston një dokument i tillë për rregullimin e faturave në 1C UPP - ai patjetër ekziston. Dikur na duhej t'i shtonim çelsat në mënyrë që të tërhiqeshin shënime paksa të ndryshme për kontabilitetin. Cili është problemi, duket se duhet, duhet, do ta bëjmë. Por kjo formë tashmë ka 2 butona radio.

Kështu duket forma në të cilën duhet të shtojmë më shumë ndërprerës

Në skedën Advanced, ne do të dëshironim të vendosnim dy butona radio të tjerë. Pra, hapi i parë është të shtojmë me guxim një element të ri kontrolli në vendin që na nevojitet dhe ta fusim atë.

Duket se gjithçka është e thjeshtë. Ne krijojmë një atribut të ri me tipin "Number" dhe futim 2 çelësa, njëri prej të cilëve do të jetë në gjendje të shkruajë të dhëna në atribut, dhe tjetri jo.

Shtoni një element të ri kontrolli - Switch, shtoni Switch2 në tabelë me numrin dhe përshkrimin e çelsave, vendosni Switch1 në fillim në grup dhe shtypni OK. Vendosni kontrollet e krijuara në formular. Ne përditësojmë konfigurimin e bazës së të dhënave (F7) dhe e ekzekutojmë atë për korrigjim.

Gjatë ekzekutimit (kur krijoni një dokument të ri në modalitetin 1C: Enterprise), shohim se sado që përpiqemi të klikojmë në Switch2, asgjë nuk ndodh. Elementet nuk funksionojnë siç duhet. Këtu ka një mashtrim.
Kthehuni te konfiguruesi. Zgjidhni artikullin e menysë Forma -> Vendosni rendin e kalimit... (është e rëndësishme që formulari të jetë i hapur në ekran)

Në mënyrë që çelësat tanë të funksionojnë, duhet të thyeni rendin automatik dhe të pranoni një manual. Dhe vendoseni në formë në mënyrë që çelsat tanë të shkojnë njëri pas tjetrit në rregull.