S verziou 8.2 platformy v 1C sa začali používať nové princípy konštrukcie rozhrania a interakcie používateľa s databázou. Nová technológia sa nazýva „Managed Application“. Mechanizmy na vytváranie formulárov a diagram interakcie medzi používateľom servera 1C a databázou prešli najväčším spracovaním. Platforma stále podporuje normálny režim, ale časom všetci používatelia 1C prejdú na spravované formuláre.
Pre bežných používateľov sa spravovaná forma dokumentu 1C líši od bežnej len vzhľadom. Pre developera ide o nový mechanizmus s vlastnými pravidlami, zákonmi a podmienkami. Mnoho oblastí prešlo zmenami, ale medzi skúsenými vývojármi 1C sa za kľúčové považujú nasledujúce inovácie:
- Samostatné formovanie štruktúry formulára a umiestnenie polí platformou. Ak predchádzajúci vývojári popisovali polohu poľa špecifikovaním pixelov, teraz je možné určiť iba typ zoskupenia;
- Formulár pozostáva z detailov reprezentujúcich údaje formulára a príkazov – procedúr a funkcií, ktoré sa majú vykonať;
- Kód formulára sa vykonáva na strane servera aj klienta. Koniec koncov, samotný formulár je konfiguračný objekt vytvorený na serveri a zobrazený na klientovi. To znamená, že kombinuje časť klienta a servera;
- Na strane klienta sa mnohé typy údajov stali nedostupnými a teraz nie je možné údaje v informačnej databáze meniť;
- Pre každú procedúru alebo funkciu musí byť špecifikované špeciálne nastavenie – kompilačná direktíva. Je zodpovedný za to, kde sa kód spustí a môže nadobudnúť nasledujúce hodnoty:
- Naklient;
- Na serveri;
- OnServerWithoutContext;
- OnClientOnServer;
- Na klientovi Na serveri bez kontextu.
Posledný bod je obzvlášť naliehavý v režime spravovaných formulárov. Ak vývojár málo rozumie direktívam alebo interakciám klient-server, potom bude pre neho mimoriadne ťažké vytvoriť riadený formulár. Všetky nové princípy pre vytváranie spravovaných formulárov v 1C:Enterprise 8.3 sú zjednotené všeobecným konceptom trojvrstvovej architektúry. Zahŕňa klientske počítače, 1C server a DBMS, kde sú uložené dáta.
Odlišná je aj úprava spravovaného formulára v konfigurátore. Veľa aspektov sa zmenilo a vývojári verzie 7.7, ktorá nemala spravované formuláre, môžu byť prekvapení. Zmenil sa dokonca aj vzhľad návrhára formulára, čo možno vidieť otvorením ľubovoľného formulára konfiguračného objektu. Pri otvorení objektu vidíme okno rozdelené do niekoľkých sekcií:
- Prvky rozhrania formulára. Vľavo hore je okno so zoznamom všetkých polí zobrazených vo vybranom formulári, ktoré zabezpečujú interakciu programu s používateľom;
- Podrobnosti formulára. Vpravo hore sú všetky údaje, s ktorými formulár pracuje. Sú tam, kde sú informácie uložené na strane klienta;
- Zobrazte spravovaný formulár. Nižšie vidíme predbežný vzhľad založený na prvkoch rozhrania;
- Modul formulára. Časť obsahujúca postupy a funkcie používané týmto formulárom. Tu nájdete kód pre algoritmy interakcie programu s používateľom aj s databázou.
Vývojári 1C povzbudzujú klientov, aby prešli na spravované formuláre, takže osvojenie si princípov vývoja spravovaných formulárov je otázkou času. Keď začnete pracovať s týmto typom formulára, uvedomíte si, že ide o krok k štandardizácii vývoja a dodržiavaniu jednotných pravidiel. Preto schopnosť pracovať so spravovanými formulármi v 1C 8.3 zvyšuje vašu úroveň vývojára 1C.
Princípy návrhu riadených formulárov
V prvom rade, aby ste pochopili mechanizmus spravovaného režimu 1C, mali by ste si uvedomiť, že formulár existuje na serveri aj na klientovi. Navyše na klientovi je tento objekt iba obrazom rozhrania pre interakciu používateľa s programom. Všetky výpočty, algoritmy, výpočty a spracovanie musia prebiehať iba na strane servera. Je to dané nielen nemožnosťou využitia mnohých funkcií a parametrov na klientovi, ale aj požiadavkami na výkon.
Kde sa procedúra vykonáva, zistíte podľa názvu smernice, ktorý musí byť napísaný pred každou procedúrou a funkciou v module formulára. Formulácia „Bez kontextu“ znamená, že údaje v riadenom formulári nebudú odovzdané tejto procedúre na serveri. V takýchto postupoch teda nebude možné písať algoritmy založené na hodnotách zadaných používateľom. Ak toto znenie nie je uvedené, formulár sa odošle celý so všetkými podrobnosťami a budete k nim mať prístup.
Vývojári 1C dôrazne odporúčajú používať nekontextové serverové volania, čo najviac znížiť ich počet a snažiť sa nevykonávať výpočty na klientovi. Pre začínajúcich vývojárov bez teoretickej prípravy je ťažké dodržať všetky tieto pravidlá a správne zmeniť kód. Predtým, ako začnete pracovať sami, bude užitočné otvoriť formulár riadenej konfigurácie a pozrieť sa na syntax a interakciu medzi klientom a serverom.
&Na serverovej procedúre Prijať dokumenty o vysporiadaní platieb z úložiska (nová adresa v úložisku) &Na serveri bez kontextovej funkcie sú výpočty s klientom (základ dokumentu) &Na serveri bez kontextovej procedúry Vyplňte zoznam pre výber kontrolných bodov (výberový zoznam, protistrana, Informácie Dátum) & Na Klientskej procedúre pre vyplnenie Head CounterpartyCompletion (SelectedValue, Ďalšie parametre) &Na serverovej procedúre SetText of Payment and Settlement Documents() &Na serverovej funkcii IsFilledInitialDocuments()Nové pravidlá pre vývoj formulárov 1C budú veľkým prínosom, ak ich budú dodržiavať všetci vývojári. Navyše všetci pocítia zmeny k lepšiemu - programátori, spoločnosti pracujúce v 1C, franšízanti a vývojári 1C. Hlavné dôsledky správneho používania spravovaných formulárov v 1C:
- Jednoduchá údržba konfigurácie a zvýšená čitateľnosť kódu. Z toho môžeme vyvodiť záver, že algoritmus napísaný jedným vývojárom môže vždy opraviť iný zamestnanec bez toho, aby trávil veľa času;
- Oddelenie kódu bežiaceho na klientovi a serveri. Vzhľadom na to, aké odlišné sú funkcie dostupné na každej z týchto strán, ich oddelenie by bolo správnym krokom;
- Hlbšie pochopenie logiky platformy, interakcií klient-server a algoritmov, ktoré píšu vývojári. Vo verziách 8.0 a starších bolo veľmi bežné nájsť formuláre dokumentov alebo referenčné knihy vyvinuté bez pochopenia časti klient-server;
- Zvýšenie výkonu konfigurácií a zníženie zaťaženia klientskych počítačov;
- Znížené náklady na nákup počítačov na pracoviská z dôvodu absencie potreby nákupu výkonných počítačov.
Výber spravovanej formy ako hlavného režimu spustenia 1C môže priniesť mnohé prekvapenia. Ale so správnym prístupom tento krok prinesie veľké dividendy, a preto sa ho stále viac a viac používateľov 1C v celom Rusku rozhoduje. Vzhľadom na to, že spoločnosť 1C počíta do budúcnosti s vývojom riadených foriem, je riskantné zotrvať pri tých zastaraných konvenčných.
Dobrý deň.
Tu je zoznam toho, čo tu môžete získať:
- Zobrazí tabuľkovú časť dokumentu ako strom a skonvertuje ju späť na tabuľkovú časť.
- Práca s podmieneným formátovaním a jeho programové využitie.
- Dynamická zmena kompozície detailov formulára
- Pohodlné rozhranie na úpravu stromu
A teraz sú počiatočné údaje o riešenom probléme:
Budeme sa baviť o odhadoch na výstavbu niečoho. Existuje adresár druhov prác (ďalej len práca) a materiálov. Existuje miera spotreby materiálu na jednotku práce. Je potrebné vypracovať dokument, v ktorom by používateľ mohol špecifikovať pre každú zákazku zoznam materiálov v množstve potrebnom na vykonanie určitého množstva tejto práce na každom poschodí budovy (v skutočnosti to niekedy vôbec nie je podlaha). , ale miestnosť, časť,... čo len chcete, že je možné rozostavaný objekt rozbiť).
Tie. Máme nasledujúcu štruktúru tabuľkovej časti dokumentu:
poschodie - zatiaľ nie je jasné, čo to je
náplň práce - číslo 15.3
množstvo materiálov - číslo 15.3
Vyzerá to jednoducho, no v praxi dostávame množstvo opakujúcich sa informácií. Napríklad máme dve diela, každé s 10 materiálmi a 9 poschodiami. Bude to 180 riadkov v dokumente, v ktorom je stĺpec „práca“ takmer všade rovnaký, každý materiál sa opakuje 9-krát.
Nižšie sú uvedené dve reprezentácie tých istých informácií. 1 - Lineárne, 2 - vo forme stromu so stĺpcami dynamických veličín. Pre prehľadnosť som farebne zvýraznil rôzne údaje: červená - práca, modrá - materiál, podlaha - lila, zelená - objem práce, oranžová - náklady, čierna - množstvo materiálov.
Druhá možnosť jednoznačne šetrí miesto na obrazovke. V prvej máme 150 buniek s informáciami, v druhej - 52. Navyše, čím viac podláh a materiálov v práci, tým väčšie úspory.
Toto je druhá možnosť, ktorú v tejto lekcii implementujeme.
Otvorte teda konfigurátor. Myslím si, že dátovú štruktúru môžete načrtnúť z dvoch adresárov, dokumentu a informačného registra. Preto príbeh začnem od momentu, keď už niečo také máme:
- Adresár "Works"
- Adresár "Materiály" (alebo nomenklatúra - na tom nezáleží)
- Dokument "..." (môžete to nazvať "Odhad" alebo inak)
- Register informácií, periodický, v ktorom sú merania: práca, materiál; zdroj: nákladový účet (môžete si preň vytvoriť záznamník, môžete nechať priame úpravy)
Najprv sa musíte rozhodnúť o spôsobe prevodu tabuľkovej časti na strom. Prvým (najjednoduchším) je použiť požiadavku na vytvorenie súčtu pre pracovné pole. Tu je nevýhodou, že do tabuľkovej časti nemôžeme pridať dve rovnaké diela s rôznym zložením materiálov, pretože práca bude kľúčovou oblasťou. Naša práca bude spojená do jedného uzla stromu a materiály v ňom budú kombinované. Druhým spôsobom je pridanie kľúčového poľa, ktoré určí, či riadky patria do rovnakého uzla.
Druhý spôsob mi pripadá otravnejší, dokument má navyše detaily, ale kód sa stáva transparentným, zrozumiteľným a spoľahlivým. Ako kľúč použijeme číslo. Pridajme k zákazke polia číslo zákazky a číslo materiálu.
Tu nám chýba tretia analytika – poschodie. V našom prípade to bude kladné celé číslo. Pre pohodlie pridáme do hlavičky pole „Počet poschodí“. Toto pole nám výrazne zjednoduší život. Prípad, keď tabuľková časť obsahuje poschodie č. 9 a maximálny počet poschodí je 8, považujeme za neprijateľný, tieto riadky budú chýbať.
Ďalším krokom je zbaviť sa poľa „Množstvo práce“ a ponechať iba množstvo. V riadkoch, kde MaterialNumberInWork = 0, budeme množstvo považovať za objem práce.
To je so štruktúrou všetko, poďme do formy. Vytvoríme si predvolený formulár, do ktorého umiestnime všetko, čo máme.
Najprv urobíme číslo a dátum v jednom riadku, táto akcia by mala byť vždy vykonaná automaticky, je to ako rebrík v kóde.
Ďalej nakreslite atribút formulára „Strom práce“ s typom hodnoty „Strom hodnôt“. Pridajme k tomu stĺpce: Number, WorkMaterial, Expense, This isWork. Medzi prvkami vytvoríme dve stránky: servisnú, kam pošleme skutočnú tabuľkovú časť a strom, kam pošleme strom. Zobrazíme všetky stĺpce stromu okrem začiarkavacieho políčka „Toto je úloha“.
Teraz poďme do kódu. Budeme potrebovať postup, ktorý nakreslí stĺpce s množstvami na základe počtu poschodí. Nazvime to "UpdateColumnComposition()". V ňom budeme dynamicky vytvárať/odstraňovať detaily formulára a prvky formulára. Tento postup sa vyvolá pri vytváraní formulára a pri zmene počtu poschodí. Tie. V čase volania procedúry už môžeme mať nejaké stĺpce a musíme ich opustiť, aby sme nestratili dáta.
Tu je jeho syntax:
&Na serveri
Postup UpdateColumnComposition()
//1. Úprava revízie formulára, pridávanie stĺpcov do stromu
strom = FormAttributesValue("WorkTree");
mCUremove = Nové pole;
MaxColumnNumber = 0;
Pre každý stĺpec vyrobený z dreva cyklus
Ak Lev(Názov stĺpca, 3) = "Počet", potom
QuantityNumber = číslo(avg(Názov stĺpca,4));
Ak MnožstvoČíslo>Object.NumberofFloors Then
mCUremove.Add(Stĺpec);
koniec Ak;
Ak QuantityNumber>MaxColumnNumber Then
MaxColumnNumber = QuantityNumber;
koniec Ak;
koniec Ak;
EndCycle;
//2.
Podrobnosti pre vymazanie = Nové pole;
Pre každý prvokMKUremove From MKUremove Cycle
Podrobnosti pre vymazanie.Add("Pracovný strom." + prvok pre vymazanie.Názov);
//prvok formulára musí byť zrútený pred rekvizitami
Elements.Delete(Elements["Pracovný strom" + prvokMCUdelete.Name])
EndCycle;
//3.
DetailsKAdd = Nové pole;
NewFormAttributes = NewFormAttributes("Number"+NewNumber, NewTypeDescription("Number", NewNumberQualifiers(15,3)), "WorkTree", "to "+NewNumber);
DetailsToAdd.Add(NewFormAttributes);
EndCycle;
//4.
ChangeDetails(DetailsToAdd,DetailsToDelete);
//5. Nakreslíme nové prvky formulára, ktoré sa musia pridať po vytvorení atribútov
Pre w = 1 Podľa objektu Počet poschodí - Cyklus maximálneho počtu stĺpov
NewNumber = MaxColumnNumber + w;
NewColumn = Elements.Add("WorkTreeNumber"+NewNumber, Type("FormField"), Elements.WorkTree);
NewColumn.View = FormFieldView.InputField;
NewColumn.DataPath = "TreeWork.Number"+NewNumber;
NewColumn.Width = 7;
NewColumn.SetAction("OnChange", "QuantityOnChange");
NewColumn.Header = "do" + w;
EndCycle;
Koniec procedúry
Dovoľte nám komentovať etapy jeho práce:
1. Prejdeme všetky stĺpce stromu, aby sme zistili, koľko ich už máme. Tu určíme jeho číslo názvom stĺpca a ak je väčšie ako požadované množstvo, pridáme ho do zoznamu na vymazanie. Nájdeme aj maximálny počet existujúceho stĺpca. (pracujeme s detailmi formulára!!!)
2. Skonvertujte zoznam stĺpcov, ktoré sa majú vymazať, na zoznam riadkov s názvami údajov. Jednak okamžite zničíme prvky formy, pretože... Nie je možné odstrániť atribúty, ktoré sú zobrazené vo formulári.
3. Vytvorte zoznam stĺpcov, ktoré je potrebné vytvoriť.
4. Zavolajte vstavanú procedúru Zmeniť podrobnosti, po ktorej už nemáme stĺpce navyše a objavili sa chýbajúce.
V skutočnosti sme v tomto postupe videli, ako správne dynamicky kresliť detaily formulára a prvky formulára. Z dôležitých nuancií:
- nemôžete odstrániť detaily, ktoré neboli vytvorené programovo
- nemôžete odstrániť podrobnosti použité v prvkoch formulára
Po uložení a spustení podniku uvidíme, že keď otvoríme existujúci dokument, okamžite sa vykreslí požadovaný počet stĺpcov a keď sa zmení počet poschodí, všetko sa okamžite dynamicky prekreslí.
Teraz si napíšeme postup na prevod tabuľky na strom. Pre test vyplňte tabuľkovú časť v dokumente ako na obrázku:
Na tento účel sme na formulári ponechali reálnu záložku, aby sme mohli odladiť a skontrolovať výsledok.
&Na serveri
Procedúra TabPartInTree()
Strom = FormAttributesValue("WorkTree");
Tree.Rows.Clear();
lineWork = "";
JobNumber = "";
MaterialNumber = "";
Object.TabularPart1.Sort("JobNumber,MaterialNumberInJob");
Pre každý Select From Object.TabularPart1 Slučka
//Ovládanie počtu poschodí
Poschodie = Select.Floor;
Ak Poschodie > Objekt.Počet poschodí Potom
Ďalej;
koniec Ak;
Ak je podlaha = 0, potom
Ďalej;
koniec Ak;
Ak Číslo úlohy<>Potom vyberte Číslo úlohy
rowWorks = Tree.Lines.Add();
lineJob.Number = SelectJobNumber;
lineWork.WorkMaterial = Select.Work;
stringJob.ThisJob = True;
//ďalšia práca začala, začneme počítať materiály od začiatku
MaterialNumber = "";
JobNumber = SelectJobNumber;
koniec Ak;
Ak SelectedMaterialNumberInJob = 0, potom//toto je riadok úlohy
lineWork["Množstvo"+Podlaha] = Vyberte.Množstvo;
Inak // toto je riadok s materiálom
Ak číslo materiálu<>Potom vyberte číslo materiálu v diele
stringMaterial = stringWork.Strings.Add();
stringMaterial.Number = Select.MaterialNumberInJob;
stringMaterial.WorkMaterial = Select.Material;
riadokMateriál.KSpotreba = Vyberte.KSpotreba;
stringMaterial.ThisWork = False;
MaterialNumber=VybranéMaterialNumberInJob;
koniec Ak;
lineMaterial["Množstvo"+Podlaha] = Vyberte.Množstvo;
koniec Ak;
EndCycle;
ValueВFormProps(Strom,"PracovnyStrom");
Koniec procedúry
Tu nie je veľmi čo komentovať. Pomocou polí „Číslo úlohy“ a „Číslo materiálu v práci“ určím, že máme pred sebou riadok so zákazkou alebo materiálom a podľa toho pridám riadok ku koreňu alebo k dielu. Ak sa zmenila iba podlaha, berieme len množstvo. Extra poschodia sú odrezané, chýbajúce poschodia nepoškodia štruktúru stromu.
Túto procedúru nazývame pri jej vytváraní na serveri po „UpdateColumnComposition()“.
Teraz to môžete otestovať spustením podniku a otvorením predtým vytvoreného dokumentu.
Teraz musíme pred napísaním dokumentu urobiť opak, uložiť strom do tabuľkovej sekcie. Píšeme postup:
&OnClient
Postup PlaceTreeВTabPart()
Object.Materials.Clear();
Pre každú PageWork z TreeWork.GetElements() slučka
p.Podlaha = w;
str.Quantity = strWork["Množstvo"+w];
EndCycle;
Pre každý PageMaterial zo slučky PageWork.GetElements().
Pre w = 1 Počet poschodí Cyklus
str = Object.Materials.Add();
p.Job.Number = p.Job.Number;
p.MaterialNumberInWork = p.Material.Number;
p.Work = str.Work.WorkMaterial;
str.Material = strMaterial.WorkMaterial;
str.KSpotreba = str.Materiál.KSpotreba;
p.Podlaha = w;
str.Množstvo = strMateriál["Množstvo"+f];
EndCycle;
EndCycle;
EndCycle;
Koniec procedúry
Návrh podmieneného formulára v 1C 8 sa používa na ovládanie viditeľnosti, dostupnosti a farby prvkov tabuľky spravovaného formulára (a používa sa aj v ACS a dynamických zoznamoch). Pohodlie jeho používania spočíva v tom, že si raz nastavíte podmienku, podľa ktorej sa má zmeniť dizajn vášho formulára. Potom, keď používateľ pracuje s formulárom, po spustení podmienky sa dizajn automaticky zmení. Nie je potrebné používať udalosti formulára a písať nepotrebný kód.
Malo by sa nahradiť, že návrh podmieneného formulára funguje iba v konfiguráciách pomocou spravovanej aplikácie (účtovníctvo 3.0, ZUP 3.0/3.1, Správa obchodu 11 atď.)
Podmienené prevedenie 1s. Interaktívne nastavenie
Ďalšou výhodou podmieneného štýlu je, že si ho môžete prispôsobiť bez písania jediného riadku kódu. Na tento účel formulár vyžaduje:
- Otvoriť vlastnosti formulára -> karta vzhľad -> Otvoriť podmienený vzhľad;
- Otvorí sa stôl ;
- V prvom stĺpci musíte vybrať dizajn (alebo niekoľko naraz);
- V druhom stĺpci nastavte podmienku, ktorou sa spustí vybraný dizajn;
- V treťom stĺpci je potrebné vybrať prvky formulára, ktoré budú ovplyvnené vybratým dizajnom.
Upozorňujeme, že podmienený štýl ovplyvňuje iba stĺpce tabuľky formulárov. V stĺpci môžete vybrať aj iné prvky formulára Formátované polia, ale to neprinesie žiadny výsledok.
Návrh podmieneného formulára. Príklad interaktívneho nastavenia
Ako príklad som napísal jednoduché spracovanie, na formulároch ktorého bol pridaný atribút s typom Tabuľka hodnôt, s tromi stĺpcami. A tiež tri detaily s typom boolovská hodnota. Spracovanie si môžete stiahnuť.
Formulár na spracovanie vyzerá takto:
Nastavme pre tento formulár nasledujúci podmienený návrh: pri nastavovaní podrobností Skryť stĺpec1 vo význame Pravda, skryť podrobnosti v tabuľke formulára Stĺpec 1.
- Otvorte nastavenia podmieneného formulára;
- Pridajme do tabuľky nový riadok;
- V stĺpci Dekor Kliknite na tlačidlo s tromi bodkami a vyberte možnosť Viditeľnosť, čo znamená Nie;
- V stĺpci Podmienka Kliknite na tlačidlo s tromi bodkami a v okne, ktoré sa otvorí, pridajte nový výber. Zadáme tam nasledujúce hodnoty: Ľavá hodnota - HideColumn1, Typ porovnania - Rovná sa, Pravá hodnota - Áno;
- V stĺpci Formátované polia kliknite na tlačidlo s tromi bodkami, v okne, ktoré sa otvorí, pridajte nový prvok a vyberte hodnotu TableShapesColumn1;
- V dôsledku toho by sme mali mať nastavenie podmieneného vzhľadu podobné tomu na nasledujúcom obrázku;
- Stlačíme tlačidlo OK, uložte naše spracovanie a spustite ho v režime 1C Enterprise;
- Pri zaškrtávaní políčka Skryť stĺpec 1, nastanú v dizajne formulára nasledujúce zmeny.
Podmienečná registrácia 8.3. Príklad konfigurácie softvéru
Použitím rovnakého externého spracovania ako v predchádzajúcom odseku uvedieme príklad programového nastavenia podmieneného vzhľadu. Musíte urobiť nasledovné: pri inštalácii rekvizít ChangeColorColumns2 vo význame Pravda, v tvare tabuľky vyfarbite pozadie Stĺpce 2, pri nastavovaní rekvizít Stĺpec 3 bude nedostupný vo význame Pravda, zneprístupníte v tabuľke formulárov rekvizity Stĺpec 3.
Vytvorme serverovú procedúru v module formulára a zavolajme ju Nastavte podmienený vzhľad a okamžite pridajte jeho volanie do procedúry Keď CreatedOnServer.
&OnServerProcedureWhenCreatingOnServer(Failure, StandardProcessing) SetConditionalDesign(); Koniec procedúry &Na serveri Procedúra Nastaviť podmienený vzhľad() Koniec procedúry
Celý nasledujúci kód napíšeme v procedúre Nastavte podmienený vzhľad. Potrebujeme pridať nový podmienený prvok formulára, používame na to štandardnú kolekciu formulárov Podmienená formácia.
Element = ConditionalDesign.Elements.Add();
Rovnako ako v interaktívnej verzii musíme vo vytvorenom prvku vyplniť dizajn, podmienky a polia. Aby sme mohli zadať pole, musíme vytvoriť pole zloženia údajov s názvom stĺpca, na ktorý sa bude návrh aplikovať. Ak existuje niekoľko polí, pridajte požadovaný počet polí na zloženie údajov. Pre výbery vytvoríme prvky výberu pre skladbu údajov a vyplníme k nim ľavú hodnotu, pravú hodnotu a typ porovnania. Pre nastavenie požadovaných vzorov vyplňte parametre dostupných vzorov. Náš príklad vytvára nasledujúci kód:
Element = ConditionalDesign.Elements.Add(); ElementField = Element.Fields.Elements.Add(); ItemField.Field = NewDataCompositionField(Items.FormTableColumn2.Name); Element Selection = Element.Selection.Elements.Add(Type("Prvok výberu DataComposition")); Element Selection.LeftValue = NewDataCompositionField("ChangeColumnColor2"); Element Selection.ComparisonView = DataCompositionComparisonView.Equals; ElementSelect.RightValue = True; Element.Design.SetParameterValue("BackgroundColor", NewColor(255, 0, 0));
Takto sme vytvorili návrh pre druhý stĺpec tabuľky. Pre tretí stĺpec sa to robí podobným spôsobom, takže sa ním nebudeme podrobne zaoberať. Kód konečného postupu Nastavte podmienený vzhľad bude vyzerať takto:
&Na serveri Postup SetConditionalAppearance() Element = ConditionalAppearance.Elements.Add(); ElementField = Element.Fields.Elements.Add(); ItemField.Field = NewDataCompositionField(Items.FormTableColumn2.Name); Element Selection = Element.Selection.Elements.Add(Type("Prvok výberu DataComposition")); Element Selection.LeftValue = NewDataCompositionField("ChangeColumnColor2"); Element Selection.ComparisonView = DataCompositionComparisonView.Equals; ElementSelect.RightValue = True; Element.Design.SetParameterValue("BackgroundColor", NewColor(255, 0, 0)); Element = ConditionalDesign.Elements.Add(); ElementField = Element.Fields.Elements.Add(); ItemField.Field = NewDataCompositionField(Items.FormTableColumn3.Name); Element Selection = Element.Selection.Elements.Add(Type("Prvok výberu DataComposition")); Item Selection.LeftValue = New DataCompositionField("Make Column3 Unavailable"); Element Selection.ComparisonView = DataCompositionComparisonView.Equals; ElementSelect.RightValue = True; Element.Design.SetParameterValue("Dostupnosť", False); Koniec procedúry
Pripomínam, že spracovanie napísané na základe analyzovaných príkladov si môžete stiahnuť.
Formuláre v 1C:Enterprise sú určené na zobrazovanie a úpravu informácií obsiahnutých v databáze. Formuláre môžu patriť ku konkrétnym konfiguračným objektom alebo môžu existovať oddelene od nich a sú využívané celým aplikačným riešením.
Napríklad adresár Nomenklatúra môže mať viacero podôb, ktoré budú použité na špecifické účely – úprava prvku adresára, zobrazenie zoznamu atď.:
Spolu s tým môžu existovať všeobecné formuláre, ktoré nepatria do špecifických konfiguračných objektov - všeobecné formuláre.
Základné formy
Každý konfiguračný objekt možno použiť na vykonanie niektorých štandardných akcií. Napríklad pre ľubovoľný adresár môže byť potrebné zobraziť zoznam jeho prvkov, zobraziť jednotlivé prvky adresára, zobraziť skupinu adresára, vybrať prvky a skupiny prvkov z adresára. Pre každý dokument bude zoznam takýchto akcií oveľa menší: zobrazenie zoznamu dokumentov, výber zo zoznamu dokumentov a zobrazenie samostatného dokumentu.
Aby sa zabezpečilo, že sa takéto štandardné akcie vykonávajú s údajmi objektov aplikačného riešenia, pre každý z nich existuje súbor základných formulárov, ktoré sa použijú pri vykonávaní zodpovedajúcich akcií. Ktorýkoľvek z formulárov podriadených tomuto objektu môže byť priradený ako hlavný. Napríklad v adresári Nomenklatúra Môžu existovať tieto základné formy:
A dokument Príjem tovaru a služieb zloženie hlavných foriem sa bude líšiť:
Ak teda chce používateľ zobraziť zoznam adresárov Nomenklatúra alebo zoznam dokladov Príjem tovaru a služieb, systém otvorí príslušný formulár označený ako formulár zoznamu pre tieto objekty.
Automaticky generované formuláre
Dôležitou vlastnosťou systému 1C:Enterprise 8 je mechanizmus automaticky generovaných formulárov. Tento mechanizmus oslobodzuje vývojára od nutnosti vytvárať všetky možné formuláre pre každý konfiguračný objekt. Vývojár potrebuje iba pridať nový konfiguračný objekt a systém sám vygeneruje potrebné formuláre v správnych momentoch práce používateľa na zobrazenie informácií obsiahnutých v tomto objekte.
Vývojár teda potrebuje vytvárať vlastné formy objektov aplikačného riešenia len vtedy, ak sa musia odlišovať (odlišný dizajn alebo špecifické správanie) od formulárov automaticky generovaných systémom.
Prepojenie formulára s údajmi
To, či formulár patrí ku konkrétnemu konfiguračnému objektu, neurčuje zloženie údajov, ktoré sú zobrazené vo formulári. To, že formulár patrí napr. do adresára Nomenklatúra, umožňuje priradiť ho ako jeden z hlavných formulárov pre tento adresár, ale nijako neurčuje, aké údaje bude tento formulár zobrazovať a aké bude jeho správanie.
Na priradenie formulára k údajom sa používajú podrobnosti formulára, ktoré označujú zoznam údajov zobrazených formulárom. Všetky formuláre samotné majú rovnaké správanie bez ohľadu na to, aké údaje zobrazujú. Jeden z atribútov formulára však môže byť preň určený ako hlavný atribút (je zvýraznený tučným písmom), v takom prípade sa štandardné správanie formulára a jeho vlastnosti doplnia v závislosti od typu hlavného atribútu formulára:
Napríklad, ak je dokument priradený ako hlavný atribút formulára Príjem tovaru a služieb, následne pri zatváraní formulára si systém vyžiada potvrdenie zaevidovania a zaúčtovania tohto dokladu. Ak priradíte, povedzme, adresár ako hlavnú náležitosť formulára Nomenklatúra, potom sa takáto žiadosť o potvrdenie pri zatváraní formulára nezobrazí.
Štruktúra formulára
Hlavnou črtou formulárov je, že nie sú detailne nakreslené vývojárom „pixel po pixeli“. Formulár v konfigurácii je logickým popisom zloženia formulára. A konkrétne umiestnenie prvkov vykoná systém automaticky pri zobrazení formulára.
Zobrazená časť formulára (viditeľná pre používateľa) je opísaná ako strom obsahujúci prvky formulára.
Prvky môžu byť vstupné polia, zaškrtávacie políčka, prepínače, tlačidlá atď. Okrem toho môže byť prvkom skupina, ktorá obsahuje ďalšie prvky. Skupina môže byť reprezentovaná ako panel s rámom, panel so stránkami (záložkami), samotná stránka alebo príkazový panel. Okrem toho môže byť prvkom tabuľka, ktorá obsahuje aj prvky (stĺpce). Štruktúra prvkov popisuje, ako bude formulár vyzerať.
Všetky funkcie formulára sú popísané vo forme detailov a príkazov. Podrobnosti sú údaje, s ktorými formulár pracuje, a príkazy sú akcie, ktoré sa majú vykonať. Vývojár v editore formulárov teda musí do formulára zahrnúť potrebné detaily a príkazy, vytvoriť prvky formulára, ktoré ich zobrazia a v prípade potreby usporiadať prvky do skupín.
Na základe tohto logického popisu systém automaticky vygeneruje vzhľad formulára na zobrazenie používateľovi. V tomto prípade systém zohľadňuje rôzne vlastnosti zobrazovaných údajov (napríklad typ), aby usporiadal prvky formulára čo najpohodlnejšie pre používateľa.
Rozmiestnenie prvkov môže vývojár ovplyvniť rôznymi nastaveniami. Dokáže určiť poradie prvkov, uviesť požadovanú šírku a výšku. Toto je však len niekoľko dodatočných informácií, ktoré pomôžu systému zobraziť formulár.
Vo formulároch môže vývojár využívať nielen príkazy samotného formulára, ale aj globálne príkazy používané v príkazovom rozhraní celej konfigurácie. Okrem toho je možné vytvárať parametrizovateľné príkazy, ktoré otvoria ďalšie formuláre s prihliadnutím na špecifické údaje aktuálneho formulára. Môže to byť napríklad vyvolanie prehľadu o zostatkoch na sklade, ktorý je aktuálne vybraný vo formulári faktúry.
Hlavným problémom je, že za 10-15 rokov už bolo skompilovaných veľa kódu pre bežné formuláre. Nikomu sa nechce toto všetko prepisovať na klient-server + veľa ľudí je vyškolených na prácu s rozhraním. Povinný prechod na BP 3.0 od budúceho roka vyvoláva paniku v mysliach vývojárov a účtovníkov. Spätná väzba bude veľmi nepríjemná. Navyše latka vstupu do profesie stúpa, programovanie je náročnejšie a štandardné ešte ťažšie. Aké sú náklady na nový algoritmus v štandardných dokumentoch? UV vyzerá skvele, keď máte na dokumentoch 2-3 tlačidlá, UV je skvelé na prácu na mobilných zariadeniach, no používa ho len 0,01 % firiem. Ak 1C nepríde s niečím novým, budete musieť prejsť, ale pre každého to bude dlhé a bolestivé. A peniaze budú musieť zaplatiť samotné firmy.
Aj ja som zatiaľ zažil len negatívne veci z kontrolovaných foriem, tu sú ďalšie nevýhody inovácie:
- Nič? No ja som na to par krat narazil, napriklad napis a prilozenie externeho tlacoveho formulara do ZUP conf, spracovanie tam je cely epos, plny navodov na internete a stranky kodu by mali.
na hrubom klientovi je jedna procedúra s parametrami t.j. vývoj je otázkou niekoľkých minút.
a brzdy sú tenké viditeľné voľným okom - Čo sa týka schopnosti pripravovať zvládnuteľné formuláre – to je umenie pre umenie, ale aký to má praktický význam, najmä pre verziu súboru?
- Vyrezával som v UV 3 roky, ale teraz som prešiel späť k jednoduchým formám a verte mi, tento prechod bol psychologicky dosť náročný, ale toto je moja vedomá voľba, pretože to, čo 1c ponúka v UV, je úplne UG…. možno o pár rokov 1c prelomí, ale teraz len hľadá miesto, kde tento prielom urobiť...
- Otvorenie UV v konfigurátore trvá oveľa dlhšie.
Potom je otváranie formulárov v 8.1 ako prestup z nákladného auta do lietadla! - Pre každého je viac problémov, používatelia sú šokovaní novým rozhraním (nie každý to prizná, ale v menších veciach sú oveľa hlúpejší), polovica programátorov sa stala nevhodnou pre profesionalitu, pre priemerného špecialistu je ťažšie nájsť si prácu a ako vyrobiť kvalitný produkt. A najúžasnejšia marketingová téma UV je, že stúpajú všade, kde k prechodu dôjde jednoduchou aktualizáciou, ale každý zabúda, že od začiatku musíte doháňať najnovšie vydania! Ale v princípe sa mi ten nápad páči!
- Neviem, moja skúsenosť ukazuje opak. Tam, kde boomy v prísnych formách udierajú automaticky už niekoľko rokov, v nových štandardných UV sa každý mesiac spustí „prečo, kde je teraz 1C po aktualizácii tohto tlačidla a prečo teraz nefunguje“, čo, vidíte , nepridáva rýchlosť.
- - existuje viac kódu
- kód sa stal zložitejším
— úprava štandardných je oveľa náročnejšia
- užívatelia, ktorým som dal UT11 nenašli žiadne výhody oproti 10.x
— zistili však určité spomalenia a nedostatok niektorých funkcií, ako je vyhľadávanie (z nejakého dôvodu chceli vyhľadávanie dopredu a dozadu a nie výber)
Môj názor je, že obete sú príliš veľké v záujme webového klienta a tabletov. Navyše osobne som ešte vôbec nevidel reálnu prácu s webovým klientom, ktorý potrebuje úspešne využívať vzdialený prístup - Klient-server bedlam by mal poskytnúť zvýšenie výkonu a škálovateľnosti, pričom náklady zároveň zahŕňajú zvýšenie kódovania.
Nie všetci však zažili nárast, preto to sklamanie. A zároveň boli všetci naklonení nákladom na kódovanie.
P.S. Vlastne tie ovládané sa mi páčia, pokojne si z nich kreslím. Ale tie typické sa stali zvrátenými. - Doma (normálny počítač) riadim pitie podľa jednotlivých podnikateľov.
8,3, BP3, kockovaný. Hlavný dojem je, že nepracujem, ale stále čakám. hemoroidná odpoveď. SOĽ na účet je tvorená ako čert kríža - vyzerá to ako karta k účtu na rok v megaholdingu. - UT11 je divoká brzda, hrôza a celkovo nočná mora.
UT10 lieta v porovnaní s UT11.
Čo sa týka UV - ploštice sú zamorené roky, všetko je krivé, stĺpy sa nikdy nezmestia na jednu obrazovku, naťahovanie je v mnohých prípadoch strašné.
A stále môžem vymenovať veľa mínusov, ale o plusoch pravdepodobne nepoviem nič. Jednoducho neexistujú.
Firmy špecificky skončili s týmito formulármi, pretože vývoj stojí viac, neboli tam špeciálne a nie sú normálne.
Výhod je málo, ale samozrejme existujú...
klady:
Odpoveď je tu už dlho, čo dal UP:
multiplatformový klient
- pracuje na zlých komunikačných linkách
- schopnosť pracovať cez prehliadač (bez inštalácie klienta)
Načítava...
