StavAnalit. Kontaktinfo. Hallatavate vormide kapoti all Näide hallatavate vormide arendamise kohta 1c-l

1C platvormi versiooniga 8.2 hakati kasutama uusi põhimõtteid liidese koostamiseks ja kasutaja interaktsiooniks andmebaasiga. Uut tehnoloogiat nimetatakse "Hallatud rakenduseks". Kõige rohkem on töödeldud vormide koostamise mehhanismid ning 1C-serveri kasutaja ja andmebaasi interaktsiooniskeem. Platvorm toetab endiselt tavarežiimi, kuid aja jooksul lülituvad kõik 1C kasutajad hallatud vormidele.

Tavakasutajate jaoks erineb 1C dokumendi hallatav vorm tavalisest ainult välimuse poolest. Arendaja jaoks on see uus mehhanism, millel on oma reeglid, seadused ja tingimused. Paljud valdkonnad on muutunud, kuid kogenud 1C arendajate seas peetakse võtmetähtsusega järgmisi uuendusi:

Vormistruktuuri iseseisev moodustamine ja väljade paigutus platvormi poolt. Kui varasemad arendajad kirjeldasid välja asukohta pikslite määramisega, siis nüüd on võimalik määrata vaid rühmitamise tüüp;
Vorm koosneb vormiandmeid esindavatest detailidest ning käskudest - teostatavatest protseduuridest ja funktsioonidest;
Vormi kood täidetakse nii serveri kui ka kliendi poolel. Vorm ise on ju serveris loodud ja kliendis kuvatav konfiguratsiooniobjekt. See tähendab, et see ühendab kliendi ja serveri osad;
Kliendi poolel on mitut tüüpi andmed muutunud kättesaamatuks ja infobaasis pole enam võimalik andmeid muuta;
Iga protseduuri või funktsiooni jaoks tuleb määrata spetsiaalne seadistus – kompileerimisdirektiiv. See vastutab selle eest, kus kood käivitatakse ja võib võtta järgmisi väärtusi:
- Naklient;
- serveris;
- OnServerWithoutContext;
- OnClientOnServer;
- Kliendil serveris ilma kontekstita.

Viimane punkt on hallatavate vormide režiimis eriti terav. Kui arendajal on vähe aru juhistest või kliendi-serveri interaktsioonidest, on tal hallatava vormi loomine äärmiselt keeruline. Kõiki hallatavate vormide loomise uusi põhimõtteid rakenduses 1C: Enterprise 8.3 ühendab kolmetasandilise arhitektuuri üldkontseptsioon. See sisaldab klientarvuteid, 1C-serverit ja DBMS-i, kus andmeid hoitakse.

Erinevaks on muutunud ka hallatava vormi redigeerimine konfiguraatoris. Paljud aspektid on muutunud ja versiooni 7.7 arendajad, millel polnud hallatud vorme, võivad olla üllatunud. Muutunud on isegi vormikujundaja välimus, mida saab näha ükskõik millise konfiguratsiooniobjekti vormi avades. Objekti avamisel näeme akent, mis on jagatud mitmeks osaks:

Vormi liidese elemendid. Üleval vasakul on aken, mis loetleb kõik valitud vormil kuvatavad väljad, mis tagavad programmi suhtluse kasutajaga;
Vormi üksikasjad. Paremas ülanurgas on kõik andmed, millega vorm töötab. Need on koht, kus teavet hoitakse kliendi poolel;
Kuvage hallatud vorm. Allpool näeme liideseelementidel põhinevat eelvaadet;
Vormi moodul. Jaotis, mis sisaldab selles vormis kasutatavaid protseduure ja funktsioone. Siit leiate algoritmide koodi programmi interaktsiooniks nii kasutaja kui ka andmebaasiga.

1C arendajad julgustavad kliente hallatud vormidele üle minema, seega on hallatud vormide arendamise põhimõtete õppimine aja küsimus. Kui hakkate seda tüüpi vormidega töötama, saate aru, et see on samm arenduse standardimise ja ühtsete reeglite järgimise suunas. Seetõttu tõstab 1C 8.3 hallatavate vormidega töötamise võimalus teie taset 1C arendajana.

Hallatud vormide kujundamise põhimõtted

Esiteks, 1C hallatava režiimi mehhanismi mõistmiseks peaksite meeles pidama, et vorm on olemas nii serveris kui ka kliendis. Veelgi enam, kliendil on see objekt ainult kasutaja ja programmiga suhtlemise liidese pilt. Kõik arvutused, algoritmid, arvutused ja töötlemine peavad toimuma ainult serveri poolel. Seda ei tingi mitte ainult suutmatus kasutada kliendil paljusid funktsioone ja parameetreid, vaid ka jõudlusnõuded.

Seda, kus protseduur käivitatakse, saate aru saada käskkirja nimest, mis tuleb vormimoodulis kirjutada enne iga protseduuri ja funktsiooni. Sõnastus "Konteksti puudub" näitab, et hallatava vormi andmeid ei edastata serveris sellele protseduurile. Seega ei ole selliste protseduuride puhul võimalik kasutaja sisestatud väärtustel põhinevaid algoritme kirjutada. Kui seda sõnastust ei täpsustata, edastatakse vorm tervikuna koos kõigi üksikasjadega ja teil on neile juurdepääs.

1C arendajad soovitavad tungivalt kasutada mittekontekstuaalseid serverikõnesid, vähendada nende arvu nii palju kui võimalik ja püüda mitte kliendiga arvutusi teha. Ilma teoreetilise väljaõppeta algajatel arendajatel on raske kõiki neid reegleid järgida ja koodi õigesti muuta. Enne iseseisva töö alustamist on kasulik avada hallatud konfiguratsioonivorm ja vaadata süntaksit ning seda, kuidas klient ja server omavahel suhtlevad.

&Serveril maksete arveldusdokumentide vastuvõtmine salvestusruumist (uus aadress salvestusruumis) &serveris ilma kontekstita funktsioon Arvutused kliendiga (dokumendi alusel) &Serveris ilma kontekstita protseduur Täitke kontrollpunkti valikuloend (valikuloend, vastaspool, Teabe kuupäev) & Kliendi protseduuri kohta Peatäide täitmise kohta vastaspoole lõpetamine (valitud väärtus, lisaparameetrid) &serveri protseduuril Makse- ja arveldusdokumentide tekst() &Serveri funktsioonil IsFilledInitialDocuments()

1C vormide väljatöötamise uutest reeglitest on palju kasu, kui kõik arendajad neist kinni peavad. Veelgi enam, kõik tunnevad muutusi paremuse poole - programmeerijad, 1C-s töötavad ettevõtted, frantsiisivõtjad ja 1C arendajad. Hallatud vormide õige kasutamise peamised tagajärjed 1C-s:

Konfiguratsiooni hooldamise lihtsus ja parem koodi loetavus. Sellest võime järeldada, et ühe arendaja kirjutatud algoritmi saab alati teine töötaja parandada ilma palju aega kulutamata;
Kliendis ja serveris töötava koodi eraldamine. Arvestades, kui erinevad on mõlemal poolel saadaolevad funktsioonid, oleks nende eraldamine õige samm;
Arendajad mõistavad paremini platvormi loogikat, kliendi-serveri interaktsioone ja nende poolt kirjutatud algoritme. Versioonides 8.0 ja varasemates versioonides oli väga levinud dokumentide või teatmeteoste vormide leidmine, mis töötati välja ilma klient-serveri osast aru saamata;
Konfiguratsioonide jõudluse suurendamine ja klientarvutite koormuse vähendamine;
Töökohtade arvutite ostmise kulud vähenevad, kuna puudub vajadus võimsate personaalarvutite ostmiseks.

Hallatud vormi valimine peamiseks 1C käivitusrežiimiks võib tuua palju üllatusi. Kuid õige lähenemisviisi korral toob see samm suuri dividende, mistõttu otsustab üha rohkem 1C kasutajaid kogu Venemaal selle ette võtta. Arvestades asjaolu, et 1C ettevõte loodab tulevikus hallatavate vormide arendamisele, on riskantne jääda vananenud tavapäraste vormide juurde.

Head päeva.

Siin on nimekiri sellest, mida siit saate:

Kuvab dokumendi tabeliosa puuna ja teisendab selle tagasi tabeliosaks.
Töö tingimusvorminguga ja selle programmiline kasutamine.
Dünaamiline muutus vormi detailide kompositsioonis
Mugav liides puu redigeerimiseks

Ja nüüd on lahendatava probleemi algandmed:

Räägime hinnangutest millegi ehitamiseks. Olemas on tööde liikide (edaspidi lihtsalt töö) ja materjalide kataloog. Tööühiku kohta on materjalikulu määr. On vaja välja töötada dokument, milles kasutaja saaks iga töö jaoks määrata materjalide loetelu, mille kogus on vajalik teatud hulga selle töö tegemiseks hoone igal korrusel (tegelikult ei ole see mõnikord üldse korrus , aga ruum, sektsioon,... mida iganes soovid, et ehitusjärgus objekt on võimalik lõhkuda).

Need. Meil on dokumendi tabeliosa struktuur järgmine:

korrus – pole veel selge, mis see on

töö ulatus - number 15.3

materjalide kogus - number 15.3

Tundub lihtne, kuid praktikas saame palju korduvat teavet. Näiteks on meil kaks töökohta, millest igaühel on 10 materjali, ja 9 korrust. See on dokumendis 180 rida, milles veerg “töö” on peaaegu kõikjal sama, iga materjali korratakse 9 korda.

Alloleval joonisel on kaks sama teabe esitust. 1 - lineaarselt, 2 - dünaamiliste koguseveergudega puu kujul. Selguse huvides tõin värvides esile erinevad andmed: punane - töö, sinine - materjal, põrand - lilla, roheline - töömaht, oranž - maksumus, must - materjalide kogus.

Teine võimalus säästab selgelt ekraaniruumi. Esimeses on meil 150 teabega lahtrit, teises - 52. Veelgi enam, mida rohkem põrandaid ja materjale töös, seda suurem on kokkuhoid.

See on teine võimalus, mida me selles õppetükis rakendame.

Niisiis, avage konfiguraator. Arvan, et kahest kataloogist, dokumendist ja inforegistrist saab andmestruktuuri visandada ise. Seetõttu alustan lugu sellest hetkest, kui meil on juba midagi sellist:

Kataloog "Töötab"
Kataloog "Materjalid" (või nomenklatuur - see pole oluline)
Dokument "..." (võite seda nimetada "hinnanguks" või millekski muuks)
Inforegister, perioodiline, milles mõõdud: töö, materjal; ressurss: kulukonto (sellele saab luua salvesti, saab jätta otsetoimetamise)

Esiteks peate otsustama tabeliosa puuks teisendamise meetodi. Esimene (lihtsaim) on kasutada päringut töövälja summade tegemiseks. Negatiivne külg on siin see, et me ei saa lisada tabeliosasse kahte identset erineva materjali koostisega teost, sest töö saab olema võtmevaldkond. Meie töö ühendatakse puu üheks sõlmeks ja selles olevad materjalid kombineeritakse. Teine võimalus on lisada võtmeväli, mis määrab, kas read kuuluvad samasse sõlme.

Minu arvates on selles tüütum teine meetod, dokumendil on lisadetailid, kuid kood muutub läbipaistvaks, arusaadavaks ja usaldusväärseks. Kasutame numbrit võtmena. Lisame töösse väljad töö number ja materjali number.

Siin puudub meil kolmas analüütika – põrand. Meie puhul on see positiivne täisarv. Mugavuse huvides lisame päisesse välja "Korruste arv". See valdkond lihtsustab meie elu oluliselt. Peame vastuvõetamatuks juhul, kui tabeliosas on korrus nr 9 ja maksimaalne korruste arv on 8.

Järgmise sammuna tuleb väljast “Töö hulk” lahti saada ja jätta alles vaid kogus. Ridadel, kus MaterialNumberInWork = 0, käsitleme kogust töö mahuna.

See on kõik struktuuriga, asume vormi. Loome vaikevormi, kuhu paigutame kõik, mis meil on.

Esiteks paneme numbri ja kuupäeva ühele reale, see toiming peaks alati toimuma automaatselt, see on nagu redel koodis.

Järgmisena joonistage vormi atribuut "Tööpuu" väärtuse tüübiga "Väärtuspuu". Lisame sellele veerud: Number, WorkMaterial, Expense, This isWork. Loome elementide hulgast kaks lehte: teeninduslehe, kuhu saadame reaalse tabeliosa ja puu, kuhu saadame puu. Kuvame kõik puu veerud, välja arvatud märkeruut "See on töö".

Nüüd asume koodi juurde. Vajame protseduuri, mis joonistab korruste arvu alusel veerud kogustega. Nimetagem seda "UpdateColumnComposition()". Selles loome/kustutame dünaamiliselt vormi üksikasju ja vormielemente. Seda protseduuri kutsutakse välja vormi loomisel ja korruste arvu muutumisel. Need. Protseduuri väljakutsumise ajal võivad meil juba mõned veerud olla ja peame need jätma, et mitte andmeid kaotada.

Siin on selle süntaks:

&Serveris
Protseduuri värskendamise veerukoostis()
//1. Vormi redaktsiooni redigeerimine, veergude lisamine puusse
tree = FormAttributesValue("WorkTree");
mCUremove = uus massiiv;
Max ColumnArv = 0;
Iga puidust valmistatud veeru jaoks
Kui Lev(Veerg.Nimi, 3) = "Loendamine", siis
KogusArv = number(keskm(Veerg.Nimi,4));
Kui QuantityNumber>Object.NumberofFloors Siis
mCUremove.Add(Veerg);
endIf;
Kui QuantityNumber>Max ColumnNumber Siis
MaxColumnNumber = KogusNumber;
endIf;
endIf;
EndCycle;
//2.
Kustutamise üksikasjad = Uus massiiv;
Iga elemendi MKUremove MKUremove tsüklist jaoks
Detailid kustutamiseks.Add("Tööpuu." + element MK kustutamiseks.Nimi);
//vormielement peab enne rekvisiite kokku jooksma
Elements.Delete(Elements["Tööpuu" + MKUdelete element.Nimi])
EndCycle;
//3.
DetailsToAdd = Uus massiiv;

NewFormAttributes = NewFormAttributes("Arv"+UusNumber, NewTypeDescription("Arv", UusNumberQualifiers(15,3)), "Tööpuu", "to "+UusNumber);
DetailsToAdd.Add(NewFormAttributes);
EndCycle;
//4.
Muuda üksikasju (üksikasjad lisamiseks, üksikasjad kustutamiseks);
//5. Joonistame uued vormielemendid, need tuleb lisada peale atribuutide loomist
For f = 1 Korruste arvu järgi – maksimaalne veergude arv
UusNumber = Max ColumnNumber + w;
UusVeerg = Elements.Add("Tööveerupuu"+UusNumber, Tüüp("Vormiväli"), Elements.WorkTree);
NewColumn.View = FormFieldView.InputField;
NewColumn.DataPath = "TreeWork.Number"+UusNumber;
Uus veerg.Laius = 7;
NewColumn.SetAction("OnChange", "QuantityOnChange");
NewColumn.Header = "kuni" + w;
EndCycle;
Menetluse lõpp

Kommenteerime selle töö etappe:

1. Käime läbi kõik puu veerud, et teada saada, kui palju meil juba on. Siin määrame selle numbri veeru nime järgi ja kui see on nõutavast kogusest suurem, lisame selle kustutamiseks loendisse. Samuti leiame olemasoleva veeru maksimaalse arvu. (töötame vormi üksikasjadega!!!)

2. Teisendage kustutatavate veergude loend andmenimedega ridade loendiks. Esiteks hävitame kohe vormi elemendid, sest... Vormil kuvatavaid atribuute ei saa kustutada.

3. Koostage loend veergudest, mis tuleb luua.

4. Kutsuge välja sisseehitatud protseduur Muuda üksikasju, mille järel meil enam täiendavaid veerge pole ja puuduvad on ilmunud.

Tegelikult nägime selles protseduuris, kuidas vormi detaile ja vormielemente õigesti dünaamiliselt joonistada. Olulistest nüanssidest:

-te ei saa kustutada üksikasju, mis pole programmiliselt loodud

-vormielementides kasutatud üksikasju ei saa kustutada

Pärast ettevõtte salvestamist ja käivitamist näeme, et olemasoleva dokumendi avamisel joonistatakse koheselt vajalik arv veerge ja kui korruste arv muutub, joonistatakse kõik kohe dünaamiliselt ümber.

Nüüd kirjutame protseduuri tabeli puuks teisendamiseks. Testi jaoks täitke dokumendi tabeliosa nagu joonisel:

Selleks jätsime vormile päris vahekaardi osa, et saaksime siluda ja tulemust kontrollida.

&Serveris
Protseduur TabPartInTree()
Tree = FormAttributesValue("Tööpuu");
Tree.Rows.Clear();
lineWork = "";
TööNumber = "";
Materjalinumber = "";
Object.TabularPart1.Sort("TööNumber,MaterialNumberInJob");
Iga valiku jaoks objektist.Tabularpart1 Loop
//Korruste arvu juhtimine
Korrus = Select.Floor;
Kui Korrus > Objekt.Korruste arv Siis
Jätka;
endIf;
Kui põrand = 0, siis
Jätka;
endIf;
Kui töönumber<>Seejärel valige Töönumber
rowWorks = Tree.Lines.Add();
ridaJob.Number = Valige Töönumber;
lineWork.WorkMaterial = Vali.Töö;
stringJob.ThisJob = tõene;
//järgmine töö on alanud, hakkame materjale lugema algusest
Materjalinumber = "";
TööNumber = Valige TööNumber;
endIf;
Kui SelectedMaterialNumberInJob = 0, siis//see on töörida
lineWork["Kogus"+Põrand] = Vali.Kogus;
Muidu // see on materjaliga rida
Kui materjali number<>Seejärel valige töös materjali number
stringMaterial = stringWork.Strings.Add();
stringMaterial.Number = Select.MaterialNumberInJob;
stringMaterial.WorkMaterial = Select.Material;
lineMaterial.KConsumption = Vali.KConsumption;
stringMaterial.ThisWork = Vale;
MaterialNumber=SelectedMaterialNumberInJob;
endIf;
lineMaterial["Kogus"+põrand] = Vali.Kogus;
endIf;
EndCycle;
ValueВFormAttributes(Tree,"WorkTree");
Menetluse lõpp

Siin pole palju kommenteerida. Kasutades välju “Töö number” ja “Material NumberInJob” tuvastan, et meil on rida vastavalt töö või materjaliga, lisan rea juurele või tööle. Kui ainult põrand on muutunud, siis võtame ainult koguse. Lisapõrandad lõigatakse ära, puuduvad põrandad ei riku puu struktuuri.

Kutsume seda protseduuri serveris loomisel pärast "UpdateColumnComposition()".

Nüüd saate seda testida, käivitades ettevõtte ja avades eelnevalt loodud dokumendi.

Nüüd peame enne dokumendi kirjutamist tegema vastupidist, salvestades puu tabeliosasse. Kirjutame protseduuri:

&OnClient
Protseduur PlaceTreeВTabPart()
Objekt.Materjalid.Clear();
Iga TreeWork.GetElements() Loopi lehetöö jaoks

p.Põrand = w;
str.Kogus = strWork["Kogus"+w];
EndCycle;
Iga PageWork.GetElements() Loopi lehematerjali jaoks
Kui w = 1 Korruste arvu tsükkel
str = Objekt.Materjalid.Lisa();
p.Töönumber = p.Töönumber;
p.MaterialNumberInWork = p.Material.Number;
p.Töö = str.Töö.Töömaterjal;
str.Material = strMaterial.WorkMaterial;
str.KConsumption = str.Material.KConsumption;
p.Põrand = w;
str.Kogus = strMaterjal["Kogus"+f];
EndCycle;
EndCycle;
EndCycle;
Menetluse lõpp

1C 8 tingimuslikku vormikujundust kasutatakse hallatava vormi tabelielementide nähtavuse, juurdepääsetavuse ja värvide juhtimiseks (ja seda kasutatakse ka ACS-is ja dünaamilistes loendites). Selle kasutamise mugavus seisneb selles, et olete kord seadnud tingimuse, mille võrra teie vormi kujundus peaks muutuma. Pärast seda, kui kasutaja vormiga töötab, muutub tingimuse käivitamisel kujundus automaatselt. Pole vaja kasutada vormisündmusi ja kirjutada mittevajalikku koodi.

Tuleks asendada, et tingimusliku vormi kujundus töötab ainult hallatavat rakendust kasutavates konfiguratsioonides (Accounting 3.0, ZUP 3.0/3.1, Trade Management 11 jne)

Tingimuslik disain 1s. Interaktiivne seadistus

Tingimusliku stiili teine eelis on see, et saate seda kohandada ilma ühtki koodirida kirjutamata. Selleks on vormil vaja:

Ava vormi omadused -> välimus vahekaart -> Tingimuslik välimus Avatud;

Avaneb laud ;
Esimeses veerus peate valima kujunduse (või mitu korraga);
Teises veerus määrake tingimus, mille korral valitud kujundus käivitatakse;
Kolmandas veerus tuleb valida vormielemendid, mida valitud kujundus mõjutab.

Pange tähele, et tingimuslik stiil mõjutab ainult vormitabeli veerge. Veerus saate valida ka muid vormielemente Vormindatud väljad, kuid see ei anna mingit tulemust.

Tingimuslik vormikujundus. Interaktiivse seadistuse näide

Näitena kirjutasin lihtsa töötluse, mille vormidele lisati atribuut koos tüübiga Väärtuste tabel, kolme veeruga. Ja ka kolm detaili koos tüübiga tõeväärtus. Töötlemise saate alla laadida.

Töötlemisvorm näeb välja selline:

Seadistame selle vormi jaoks järgmise tingimusliku kujunduse: detailide määramisel Peida veerg1 tähenduses Tõsi, peida üksikasjad vormitabelis Veerg1.

Avage tingimusvormi sätete sätted;
Lisame tabelisse uue rea;
Kolumnis Dekoratsioon Klõpsake kolme punktiga nuppu ja valige suvand Nähtavus, tähendus Ei;

Kolumnis Seisund Klõpsake kolme punktiga nuppu ja lisage avanevas aknas uus valik. Sisestame sinna järgmised väärtused: Vasak väärtus – Peida veerg1, võrdluse tüüp – võrdne, parem väärtus – jah;

Kolumnis Vormindatud väljad klõpsake kolme punktiga nuppu, lisage avanevas aknas uus element ja valige väärtus TabeliKujundidVeerg1;
Selle tulemusena peaks meil olema tingimuslik välimuse seadistus, mis on sarnane järgmisel joonisel olevaga;

Vajutame nuppu Okei, salvestage meie töötlemine ja käivitage see režiimis 1C ettevõte;
Kasti kontrollimisel Peida veerg 1, toimuvad vormi kujunduses järgmised muudatused.

Tingimuslik registreerimine 8.3. Tarkvara konfiguratsiooni näide

Kasutades sama välist töötlemist nagu eelmises lõigus, toome näite tingimusliku välimuse programmilisest seadistusest. Peate tegema järgmist: rekvisiitide paigaldamisel Muuda värve veerge2 tähenduses Tõsi, värvige tabeli kujus taust 2. veerud, rekvisiitide seadmisel Muutke veerg 3 kättesaamatuks tähenduses Tõsi, muuda vormitabelis kättesaamatuks rekvisiidid Veerg 3.

Loome vormimoodulis serveriprotseduuri ja kutsume selle välja Määra tingimuslik välimus ja lisage kohe selle kutse protseduurile Kui CreatedOnServer.

&OnServerProcedureServeri loomisel(tõrge, StandardProcessing) SetConditionalDesign(); Protseduuri lõpp &serveris protseduuride määramine tingimuslik välimus() Protseduuri lõpp

Kirjutame protseduuri käigus kogu järgmise koodi Määra tingimuslik välimus. Peame lisama uue tingimusliku vormi elemendi, selleks kasutame standardvormikogu Tingimuslik kujunemine.

Element = ConditionalDesign.Elements.Add();

Nii nagu interaktiivses versioonis, peame ka loodud elemendis täitma kujunduse, tingimused ja väljad. Välja määramiseks peame looma andmekoosseisu väli veeru nimega, millele kujundus rakendatakse. Kui välju on mitu, lisage vajalik arv andmekoosseisu välju. Valikute jaoks loome andmete koostamiseks valikuelemendid ja täidame nende jaoks vasakpoolse väärtuse, parema väärtuse ja võrdlustüübi. Vajalike kujunduste seadmiseks täitke saadaolevate kujunduste parameetrid. Meie näide loob järgmise koodi:

Element = ConditionalDesign.Elements.Add(); ElementField = Element.Fields.Elements.Add(); Kaubaväli.Välja = NewDataCompositionField(Items.FormTable Column2.Name); Element Selection = Element.Selection.Elements.Add(Type("DataComposition Selection Element")); Elemendi valik.LeftValue = NewDataCompositionField("Change ColumnColor2"); Element Selection.ComparisonView = DataCompositionComparisonView.Equals; ElementSelect.RightValue = Tõene; Element.Design.SetParameterValue("BackgroundColor", NewColor(255, 0, 0));

Nii lõime tabeli teise veeru kujunduse. Kolmanda veeru puhul tehakse seda sarnaselt, nii et me ei peatu sellel üksikasjalikult. Lõplik protseduurikood Määra tingimuslik välimus näeb välja selline:

&Serveri protseduuris SetConditionalAppearance() Element = ConditionalAppearance.Elements.Add(); ElementField = Element.Fields.Elements.Add(); Kaubaväli.Välja = NewDataCompositionField(Items.FormTable Column2.Name); Element Selection = Element.Selection.Elements.Add(Type("DataComposition Selection Element")); Elemendi valik.LeftValue = NewDataCompositionField("Change ColumnColor2"); Element Selection.ComparisonView = DataCompositionComparisonView.Equals; ElementSelect.RightValue = Tõene; Element.Design.SetParameterValue("BackgroundColor", NewColor(255, 0, 0)); Element = ConditionalDesign.Elements.Add(); ElementField = Element.Fields.Elements.Add(); Kaubaväli.Välja = NewDataCompositionField(Items.FormTable Column3.Name); Element Selection = Element.Selection.Elements.Add(Type("DataComposition Selection Element")); Üksuse valik.LeftValue = New DataCompositionField("Muuda veerg 3 kättesaamatuks"); Element Selection.ComparisonView = DataCompositionComparisonView.Equals; ElementSelect.RightValue = Tõene; Element.Design.SetParameterValue("Saadaval", False); Menetluse lõpp

Tuletan meelde, et analüüsitud näidete põhjal kirjutatud töötluse saab alla laadida.

Vormid 1C: Enterprise'is on ette nähtud andmebaasis sisalduva teabe kuvamiseks ja redigeerimiseks. Vormid võivad kuuluda kindlatesse konfiguratsiooniobjektidesse või eksisteerida neist eraldi ning neid kasutab kogu rakenduslahendus.

Näiteks kataloog Nomenklatuur võib olla mitu vormi, mida kasutatakse konkreetsetel eesmärkidel - kataloogielemendi redigeerimine, loendi kuvamine jne:

Koos sellega võivad esineda üldvormid, mis ei kuulu konkreetsete konfiguratsiooniobjektide hulka – üldvormid.

Põhivormid

Iga konfiguratsiooniobjekti saab kasutada teatud standardtoimingute tegemiseks. Näiteks võib mis tahes kataloogi puhul olla vaja kuvada selle elementide loend, kuvada kataloogi üksikud elemendid, kuvada kataloogi rühm, valida kataloogist elemente ja elementide rühmi. Iga dokumendi puhul on selliste toimingute loend palju väiksem: dokumentide loendi vaatamine, dokumentide loendist valimine ja eraldi dokumendi vaatamine.

Tagamaks selliste standardtoimingute sooritamist rakenduslahenduse objektide andmetega, on igaühe jaoks olemas põhivormide komplekt, mida vastavate toimingute tegemisel kasutatakse. Mis tahes sellele objektile alluvaid vorme saab määrata peamiseks. Näiteks kataloogis Nomenklatuur Võib esineda järgmised põhivormid:

Ja dokument Kaupade ja teenuste vastuvõtt põhivormide koostis on erinev:

Seega, kui kasutaja soovib vaadata kataloogide loendit Nomenklatuur või dokumentide loetelu Kaupade ja teenuste vastuvõtt, avab süsteem vastava vormi, mis on määratud nende objektide loendivormiks.

Automaatselt genereeritud vormid

1C:Enterprise 8 süsteemi oluline omadus on automaatselt genereeritud vormide mehhanism. See mehhanism vabastab arendaja vajadusest luua iga konfiguratsiooniobjekti jaoks kõik võimalikud vormid. Arendaja peab lihtsalt lisama uue konfiguratsiooniobjekti ja süsteem ise genereerib kasutaja töös õigetel hetkedel vajalikud vormid selles objektis sisalduva teabe kuvamiseks.

Seega on arendajal vaja luua oma vormid rakenduslahenduse objektidest ainult siis, kui need peavad erinema (erinev disain või konkreetne käitumine) süsteemi poolt automaatselt genereeritavatest vormidest.

Vormi sidumine andmetega

See, kas vorm kuulub konkreetsesse konfiguratsiooniobjekti, ei määra vormil kuvatavate andmete koostist. See, et vorm kuulub näiteks kataloogi Nomenklatuur, võimaldab määrata selle selle kataloogi üheks peamiseks vormiks, kuid ei määra mingil viisil, milliseid andmeid see vorm kuvab ja kuidas see käitub.

Vormi seostamiseks andmetega kasutatakse vormi detaile, mis näitavad vormi poolt kuvatavate andmete loendit. Kõik vormid ise käituvad samamoodi, olenemata nende kuvatavatest andmetest. Selle peamiseks atribuudiks saab aga määrata ühe vormiatribuudi (see on esile tõstetud paksus kirjas), sel juhul täiendatakse vormi standardset käitumist ja selle omadusi sõltuvalt sellest, mis tüüpi põhiatribuut on:

Näiteks kui dokument on määratud vormi põhiatribuudiks Kaupade ja teenuste vastuvõtt, siis küsib süsteem vormi sulgemisel selle dokumendi salvestamise ja postitamise kinnitust. Kui määrate vormi peamiseks atribuudiks näiteks kataloogi Nomenklatuur, siis sellist kinnitustaotlust vormi sulgemisel ei kuvata.

Vormi struktuur

Vormide peamine omadus on see, et arendaja ei joonista neid üksikasjalikult, “piksli haaval”. Vorm konfiguratsioonis on vormi koostise loogiline kirjeldus. Ja elementide konkreetse paigutuse teostab süsteem vormi kuvamisel automaatselt.

Vormi kuvatavat (kasutajale nähtavat) osa kirjeldatakse vormielemente sisaldava puuna.

Elemendid võivad olla sisestusväljad, märkeruudud, raadionupud, nupud jne. Lisaks võib element olla rühm, mis sisaldab muid elemente. Gruppi saab kujutada paneelina raamiga, lehtedega (järjehoidjatega), lehe enda või käsupaneelina. Lisaks võib elemendiks olla tabel, mis sisaldab ka elemente (veerge). Elemendi struktuur kirjeldab, kuidas vorm välja näeb.

Kõik vormi funktsioonid on kirjeldatud detailide ja käskude kujul. Üksikasjad on andmed, millega vorm töötab, ja käsud on sooritatavad toimingud. Seega peab arendaja vormiredaktoris kaasama vormile vajalikud detailid ja käsud, looma neid kuvavad vormielemendid ja vajadusel elemendid rühmadesse paigutama.

Selle loogilise kirjelduse alusel genereerib süsteem kasutajale kuvamiseks automaatselt vormi välimuse. Sel juhul võtab süsteem arvesse kuvatavate andmete erinevaid omadusi (näiteks tüüp), et vormielemendid kasutajale võimalikult mugavalt järjestada.

Arendaja saab elementide paigutust erinevate seadistustega mõjutada. See võib määrata elementide järjekorra, näidata soovitud laiust ja kõrgust. See on aga vaid lisateave, mis aitab süsteemil vormi kuvada.

Vormides saab arendaja kasutada mitte ainult vormi enda käske, vaid ka globaalseid käske, mida kasutatakse kogu konfiguratsiooni käsuliideses. Lisaks on võimalik luua parameetrilisi käske, mis avavad muid vorme, võttes arvesse praeguse vormi spetsiifilisi andmeid. Näiteks võib see olla praegu arve vormil valitud lao saldode aruande kutsumine.

Põhiprobleem on selles, et 10-15 aasta jooksul on tavavormide jaoks juba palju koodi koostatud. Keegi ei taha seda kõike klient-serveris ümber kirjutada + palju inimesi on liidesega töötama koolitatud. Järgmisest aastast algav kohustuslik üleminek BP 3.0-le tekitab arendajates ja raamatupidajates paanikat. Tagasiside on väga ebameeldiv. Lisaks tõuseb erialale sisenemise latt, programmeerimine on keerulisem ja standardsed on muutunud veelgi keerulisemaks. Kui palju maksab uus algoritm standarddokumentides? UV näeb hea välja, kui sul on dokumentidel 2-3 nuppu, UV sobib suurepäraselt mobiilseadmetega töötamiseks, kuid seda kasutab vaid 0,01% ettevõtetest. Peate vahetama, kui 1C midagi uut välja ei paku, kuid see on pikk ja kõigile valus. Ja ettevõtted ise peavad raha maksma.

Ka mina olen kontrollitud vormidest seni ainult negatiivset kogenud, siin on veel mõned uuenduse miinused:

Mitte midagi? Noh, ma puutusin sellega paar korda kokku, näiteks kirjutades ja lisades ZUP confi välise trükivormi, seal töötlemine on terve eepos, täis juhiseid Internetis ja lehekülgi koodi peaks.
paksul kliendil on üks protseduur parameetritega st. areng on minutite küsimus.
ja pidurid on palja silmaga nähtavad
Mis puudutab hallatavate vormide ettevalmistamist – see on kunst kunsti pärast, aga mis on praktiline mõte, eriti failiversiooni puhul?
Skulptuurisin UV-s 3 aastat, kuid nüüd läksin tagasi lihtsate vormide juurde ja uskuge mind, seda üleminekut oli psühholoogiliselt üsna raske teha, kuid see on minu teadlik valik, sest see, mida 1c UV-s pakub, on täiesti UG…. võib-olla paari aasta pärast teeb 1c läbimurde, aga praegu ta alles otsib kohta, kus see läbimurre teha...
Konfiguraatoris olevad UV-kiirgused avanevad palju kauem.
Pärast seda on vormide avamine 8.1-s nagu veoautolt lennukile üleminek!
Probleeme on kõigi jaoks rohkem, kasutajad on uuest liidesest šokeeritud (kõik ei tunnista seda, aga väiksemate asjadega ollakse palju rumalam), pooled programmeerijad on muutunud professionaalsusele sobimatuks, keskmisel spetsialistil on muutunud raskemaks leida tööd ja kuidas toota kvaliteetset toodet. Ja UV-i kõige lahedam turundusteema on see, et nad hõljuvad kõikjal, kus üleminek toimub lihtsa värskendusega, kuid kõik unustavad, et algusest peale peate jõudma viimastele väljaannetele! Aga põhimõtteliselt mulle see idee meeldib!
Ma ei tea, minu kogemus näitab vastupidist. Seal, kus karmides vormides buumid löövad juba mitu aastat automaatselt, siis uutes UV-standardi omades hakkab iga kuu “miks, kus on 1C nüüd peale selle nupu uuendamist ja miks see nüüd ei tööta”, mis, näed. , kiirust ei lisa.
- koodi on rohkem
- kood on muutunud keerulisemaks
— standardsete muutmine on palju keerulisem
- kasutajad, kellele andsin UT11, ei leidnud eeliseid võrreldes 10.x-ga
— kuid nad leidsid aeglustumise ja mõnede funktsioonide (nt otsing) puudumise (millegipärast tahtsid nad edasi-tagasi otsingut, mitte valikut)
Minu arvamus on, et ohvrid on veebikliendi ja tahvelarvutite jaoks liiga suured. Pealegi pole ma isiklikult veel näinud päris tööd veebikliendiga, kellel on vaja edukalt kaugjuurdepääsu kasutada
Client-server bedlam peaks suurendama jõudlust ja mastaapsust, samas kui kulud hõlmavad kodeerimise suurenemist.
Kuid mitte kõik ei kogenud kasvu, sellest ka pettumus. Ja samal ajal olid kõik kodeerimiskulude kallal.
P.S. Tegelikult mulle meeldivad kontrollitud, ma tõmban rahulikult nende peale. Kuid tüüpilised on muutunud perversseks.
Kodus (tavalises arvutis) viin joomise läbi vastavalt üksikettevõtjatele.
8,3, BP3, ruuduline. Peamine mulje on, et ma ei tööta, vaid ootan kogu aeg. hemorroidiaalne reaktsioon. SOOL kontole moodustatakse pagana lihtsalt - tundub nagu aasta kontokaart megahoidlas.
UT11 on metsik pidur, õudus ja üldiselt õudusunenägu.
UT10 lendab võrreldes UT11-ga.
Seoses UV-ga - putukad on nakatunud aastaid, kõik on viltu, veerud ei mahu kunagi ühele ekraanile, venitamine on paljudel juhtudel kohutav.
Ja ma võin veel palju miinuseid loetleda, kuid plusside kohta ma ilmselt midagi ei ütle. Neid lihtsalt pole olemas.
Firmad konkreetselt sattusid nende vormidega, sest arendus maksab rohkem, eripakkumisi polnud ja normaalseid pole.