Riadené formy programové pridávanie prvkov. Hlavným atribútom formulára. Pridávanie prvkov do formulára

Atribúty formulára poskytujú jeho spojenie s údajmi. V tomto prípade môže byť jeden (a iba jeden) z detailov priradený ako hlavný; nemusí byť nevyhnutne dátového typu k objektu, ktorého formulár kreslíme. Správanie formulára však bude závisieť od typu údajov hlavného atribútu. Okrem zmeny správania formulára dochádza aj k zmene kontextu modulu formulára. Spolu s metódami a vlastnosťami formulára sa v ňom sprístupňujú aj metódy a vlastnosti objektu, ktorý je hodnotou hlavného atribútu. Dôležité je, že formuláre typu „Voľná ​​forma“ nemajú hlavný atribút. V tomto prípade je správanie formulára určené iba nastaveniami používateľa. Poďme sa pozrieť na základy.

Otázka 10.05 skúšky 1C: Platformový profesionál. Na čo slúži hlavný atribút formulára?

1. Určuje zdroj údajov pre formulár ako celok
2. Definuje štandardné funkcie platformy pre formulár na prácu s údajmi typu špecifikovaného pre hlavný atribút
3. Poskytnúť možnosť programového prístupu k atribútom objektu z lokálneho kontextu formulára
4. Poskytuje vizualizáciu atribútov objektu v dialógovom okne formulára
5. Správne 2 a 3
6. Správne 1 a 2

Správna odpoveď je šiesta, pozri vyššie.

1. Na opis zloženia údajov, ktoré sa zobrazujú, upravujú alebo ukladajú vo formulári
2. Na zobrazenie a úpravu údajov vo formulári
3. Správne 1 a 2

Správna odpoveď je tretia – obe.

Otázka 10.07 skúšky 1C: Platformový profesionál. Ak chcete priradiť hlavný atribút ľubovoľnému riadenému formuláru...

1. musíte zaškrtnúť políčko "Hlavný atribút" vo vlastnostiach atribútu formulára
2. musíte vyplniť vlastnosť "Údaje" formulára výberom požadovaného atribútu formulára

Správna odpoveď je tá druhá:

1. formulár musí byť hlavný, hlavný atribút sa určí automaticky
2. musíte zaškrtnúť políčko "Hlavný atribút" vo vlastnostiach atribútu formulára
3. musíte vstúpiť do ponuky "Upraviť", položku "Hlavné atribúty" a vybrať požadovanú hodnotu
4. musíte vyplniť vlastnosť "Údaje" formulára výberom požadovaného atribútu formulára

Správna odpoveď je štvrtá:

Hlavné rekvizity sú zvýraznené tučným písmom:

1. To je nemožné
2. Je to možné priradením zodpovedajúca hodnota vlastnosti atribútu formulára
3. Dá sa vykonať iba programovo pri prístupe k objektu "Formulár".
4. Je to možné pridaním ďalšej hodnoty k zodpovedajúcej vlastnosti formulára

Správna odpoveď je prvá, hlavný atribút je striktne jeden, pretože spojenie s objektom musí byť jednoznačné.

Otázka 10.113 skúšky 1C: Platformový profesionál. Ktorý z detailov formulára znázorneného na obrázku je hlavný?

1. ZoznamCurrencyRates
2. DirectoryObject
3. Adresárové formuláre nemajú hlavný atribút
4. Formuláre adresárov majú všetky základné detaily

Editor formulárov sa používa na vytváranie a úpravu foriem objektov aplikačného riešenia. Objektové formuláre systém používa na vizuálne zobrazenie údajov počas práce používateľa.

Akákoľvek forma je kombináciou niekoľkých komponentov:

• prvky - objekty, ktoré definujú vizuálnu reprezentáciu formulára a interagujú s používateľom,
• príkazové rozhranie - súbor príkazov zobrazených vo formulári;
• atribúty - objekty, ktorých údaje formulár používa pri svojej práci.
• príkazy - akcie, ktoré sú definované v tejto konkrétnej forme,
• parametre - objekty, ktorých hodnoty charakterizujú samotný formulár, používajú sa pri jeho vytváraní a zostávajú konštantné počas „života“ formulára,
• modul - program v zabudovanom jazyku, ktorý je zodpovedný za prácu s prvkami a za obsluhu udalostí;

Editor formulárov obsahuje niekoľko záložiek, ktoré umožňujú úpravu všetkých komponentov formulára.

V samostatnom okne v spodnej časti editora sa zobrazí vzhľad formulára v režime 1C:Enterprise.

Editačné prvky

Editor formulárov umožňuje vývojárom využívať širokú škálu možností úprav vzhľad formulár - formulár, ktorý bude mať formulár v režime 1C:Enterprise. Uvádzame hlavné z týchto možností:

Stránky, záložky

Editor formulárov vám umožňuje pridať do formulára vlastné prvky, ktoré vám pomôžu dať formuláru jeho vlastný rozpoznateľný štýl, zjednodušia prístup k údajom a zmestia množstvo informácií do obmedzenej oblasti.

Editor umožňuje pridať do formulára viacero prvkov Skupina - Stránky, z ktorých každý môže obsahovať viacero prvkov Skupina - Stránka.

Napríklad formulár dokumentu môže obsahovať jeden prvok Skupina - Stránky, ktorému sú podriadené viaceré prvky Skupina - Stránka s hlavičkami Obrázok, Charakteristika a Popis:

Potom v režime 1C:Enterprise to bude vyzerať takto:

Názov každej skupiny – stránky sa zobrazuje na samostatnej karte. Vývojár má možnosť nastaviť režim zobrazenia záložiek: zdola alebo zhora:

Napríklad záložky je možné umiestniť dole:

Prvky

Editor umožňuje pridávať do formulára rôzne prvky. Prvky môžete pridať pomocou príkazu add alebo presunutím atribútov formulára do stromu prvkov:

Všetky prvky formulára sú reprezentované ako hierarchická štruktúra, ktorej koreňom je samotná forma. To vám umožní rýchlo prejsť na požadovaný prvok formulára:

Umiestnením prvkov vyššie/nižšie v strome, ich podriadením iným prvkom a nastavením vlastností prvkov skupiny môžete nastaviť poradie, v ktorom bude používateľ obchádzať ovládacie prvky formulára pri zadávaní a úprave údajov. V režime 1C:Enterprise sa prvky formulára budú prechádzať v poradí ich hierarchie a podľa toho, aký typ zoskupenia je vybraný pre skupiny: vertikálne alebo horizontálne.

Separátory

Rozdeľovače sú špeciálne prvky, ktoré možno použiť na prerozdelenie priestoru formulára bez zmeny jeho veľkosti. Platforma v režime 1C:Enterprise nezávisle pridáva tieto prvky do formulára. Oddeľovač má schopnosť "zachytiť" myšou a pohybovať sa vo formulári v rámci svojich limitov, berúc do úvahy možnosť umiestnenia ďalších prvkov a orientáciu oddeľovača:

Pri presúvaní rozdeľovača sa zmení veľkosť alebo sa presunú všetky prvky spojené s rozdeľovačom:

Modul formulára

Na úpravu modulu formulára konfigurátor zavolá editor textov a modulov. Tento editor poskytuje vývojárom širokú škálu možností na vytváranie a úpravu textu modulu.

Podrobnosti formulára

Atribúty formulára sa upravujú v zozname, čo vám umožňuje vytvárať nové atribúty, meniť existujúce a odstraňovať nepotrebné atribúty. Vlastnosti atribútu sa nastavujú pomocou palety vlastností.

Ak má formulár hlavný atribút, ktorý určuje správanie formulára, odlišný od typického, je zvýraznený tučným písmom.

Rozhranie príkazu formulára

Príkazové rozhranie formulára sa upravuje v strome. Hlavné vetvy stromu obsahujú príkazy pridané do navigačnej lišty okna, v ktorom sa formulár zobrazí, a do príkazovej lišty formulára. V rámci každej z týchto vetiev sú príkazy rozdelené do štandardných skupín.

Platforma automaticky pridáva niektoré príkazy do príkazového rozhrania. Spolu s tým môže vývojár nezávisle pridávať príkazy do príkazového rozhrania ich pretiahnutím zo zoznamu príkazov formulára alebo zo zoznamu dostupných globálnych príkazov. Pre všetky príkazy pridané do príkazového rozhrania môže vývojár nastaviť ich viditeľnosť pre rôzne roly definované v konfigurácii.

Príkazy tvaru

Príkazy formulára sa upravujú v zozname. Vývojár má možnosť pridávať, odstraňovať príkazy formulára a nastavovať ich vlastnosti pomocou palety vlastností. Vrátane priradenia procedúry k príkazu, ktorý sa vykoná, keď používateľ zavolá tento príkaz.

Záložka Štandardné príkazy a Globálne tímy vývojár dostane zoznam príkazov generovaných platformou a dostupných na použitie v tomto formulári. Ich vlastnosti nemôžete zmeniť, môžete ich iba pridať do formulára.

Pomocou myši môže vývojár pretiahnuť príkaz do príkazového rozhrania formulára. Príkaz môžete pretiahnuť aj priamo do stromu prvkov, ak chcete napríklad tento príkaz zobraziť ako tlačidlo umiestnené vo formulári.

Možnosti formulára

Parametre formulára sa upravujú v zozname. Vývojár má možnosť pridávať, odstraňovať parametre formulára a nastavovať ich vlastnosti pomocou palety vlastností.

Podrobnosti formulára

Sada atribútov formulára popisuje obsah údajov, ktoré sa zobrazujú, upravujú alebo ukladajú vo formulári. Podrobnosti formulára zároveň neposkytujú možnosť zobrazenia a úpravy údajov. Na zobrazenie a úpravu sa používajú prvky formulára (pozri časť „Prvky formulára“ tejto kapitoly) spojené s atribútmi formulára. Súhrn všetkých atribútov formulára sa bude nazývať údaje formulára.

Dôležité! Je potrebné mať na pamäti, že na rozdiel od konvenčných formulárov sú všetky údaje riadená forma by mali byť opísané vo forme podrobností. Nie je dovolené používať premenné modulu formulára ako zdroje údajov pre prvky formulára.

Je možné priradiť Hlavný atribút formulára, teda rekvizitu, ktorá bude definovať štandardnú funkcionalitu formulára (rozšírenie formulára). Malo by sa pamätať na to, že formulár môže mať iba jeden hlavný atribút.

Rozšírenie formulára sú dodatočné vlastnosti, metódy a parametre formulára objektu ManagedForm, ktoré sú špecifické pre objekt, ktorý je hlavným prvkom formulára.

V procese vývoja formulára môžete explicitne nastaviť schopnosť zobrazovať a upravovať špecifické atribúty formulára v kontexte rolí pomocou vlastností Zobraziť a Upraviť (ďalšie podrobnosti nájdete v časti „Nastavenia formulára založené na rolách“ kapitola Redakcia). Okrem toho je možné dostupnosť tohto alebo toho atribútu v samotnom formulári nakonfigurovať pomocou funkčných možností (viac informácií o funkčných možnostiach nájdete v kapitole „Správa konfiguračného rozhrania“).

Vlastnosť atribútu formulára Uložené údaje je náznak, že interaktívna zmena rekvizity bude mať za následok pokus o uzamknutie údajov formulára na úpravu, ako aj automatická inštalácia znak zmeny formy.

Dátové typy dostupné v spravovanom formulári

Spravovaný formulár sa od bežného formulára líši aj typmi údajov, s ktorými pracuje. Ak bežný formulár funguje s väčšinou typov poskytovaných 1C:Enterprise (vrátane typov DirectoryObject, DocumentObject atď.), potom v riadenom formulári možno rozlíšiť nasledujúce kategórie typov:

• typy, ktoré sa priamo používajú vo formulári, sú typy, ktoré existujú na strane tenkého a webového klienta (napríklad Number, ReferenceReference.Products, GraphicScheme, SpreadsheetDocument);

• typy, ktoré sa skonvertujú na špeciálne typy údajov, sú typy údajov riadeného formulára. Takéto typy sú zobrazené v zozname atribútov formulára v zátvorkách, napríklad (CatalogObject.Products);

• dynamický zoznam (podrobnosti nájdete v časti „Dynamický zoznam“ tejto kapitoly).

Konverzia aplikačných objektov na údaje formulára

Niektoré typy aplikácií (napríklad DirectoryObject atď.) neexistujú na strane tenkých a webových klientov (viac podrobností nájdete v kapitole Koncepcia riadenej aplikácie). Preto pre reprezentáciu vo forme takýchto typov aplikácií platforma zaviedla špeciálne dátové typy určené na prácu v riadených formulároch. Táto funkcia riadenej aplikácie si vyžaduje konverziu objektov aplikácie na údaje formulára (a naopak).

Používajú sa nasledujúce typy údajov:

• FormDataStructure – obsahuje množinu vlastností ľubovoľného typu. Vlastnosti môžu byť iné štruktúry, kolekcie alebo štruktúry s kolekciami. Tento typ je reprezentovaný napríklad vo forme DirectoryObject.

• DataFormCollection je zoznam napísaných hodnôt, podobne ako pole. K prvku kolekcie sa pristupuje pomocou indexu alebo identifikátora. Prístup ID nemusí byť v niektorých prípadoch k dispozícii. Je to kvôli typu aplikačného objektu reprezentovaného touto kolekciou. Identifikátor môže byť ľubovoľné celé číslo. Tento typ je zastúpený napríklad vo forme tabuľková časť.

• FormDataStructureWithCollection je objekt, ktorý je reprezentovaný ako štruktúra a kolekcia súčasne. Dá sa s ňou zaobchádzať ako s ktoroukoľvek z týchto entít. Tento typ je zastúpený napríklad vo forme súboru záznamov.

• FormDataTree – objekt určený na ukladanie hierarchických údajov.

Aplikačný objekt je reprezentovaný jedným alebo viacerými dátovými prvkami formulára. AT všeobecný pohľad hierarchia a zloženie údajov formulára závisí od zložitosti a vzťahu objektov aplikácie riadeného formulára.

Napríklad dokument obsahujúci tabuľkovú sekciu bude reprezentovaný objektom typu FormDataStructure (samotný dokument), ktorému je podriadený objekt typu FormDataCollection (tabuľková sekcia dokumentu).

Dôležité! Pri navrhovaní konfigurácie je dôležité pamätať na to, že aplikačné objekty sú dostupné len na serveri, zatiaľ čo dátové objekty formulára je možné použiť na serveri aj na klientovi.

Prenos údajov medzi klientskou a serverovou stranou spravovaného formulára

V skutočnosti môžeme povedať, že údaje formulára sú jednotnou reprezentáciou údajov rôznych aplikačných objektov, s ktorými formulár pracuje rovnakým spôsobom a ktoré sú prítomné na serveri aj na klientovi. To znamená, že formulár obsahuje určitú „projekciu“ dát objektov aplikácie vo forme vlastných dátových typov a v prípade potreby medzi nimi konvertuje. Ak však vývojár konfigurácie implementuje svoj vlastný algoritmus spracovania údajov, potom musí vykonať konverziu údajov (zo špecializovaných typov na typy aplikácií a naopak) sám.

Pri úprave atribútov formulára v špecializovanom editore (podrobnejšie v časti „Atribúty formulára“ v kapitole „Editory“) je možné ovplyvniť prenos dát medzi klientom a serverom počas prevádzky formulára. Na tento účel použite stĺpec editora atribútov. Vždy používajte. Účinok tejto vlastnosti sa líši pre tri typy atribútov:

• Pre atribút podriadený dynamickému zoznamu (stĺpec dynamický zoznam):
  • vlastnosť povolená – atribút je vždy načítaný z databázy a zahrnutý do údajov formulára;
  • vlastnosť vypnutá – atribút sa načíta z databázy a zahrnie do údajov formulára iba vtedy, keď je k atribútu alebo jeho podriadenému atribútu priradený aktuálne viditeľný prvok formulára.

• Pre rekvizity podriadené kolekcii pohybu:
  • vlastnosť je povolená – pohyby dokladov sa načítajú z databázy a budú prítomné v údajoch formulára;
  • vlastnosť je zakázaná - pohyby dokladov nebudú načítané z databázy a nebudú zahrnuté do údajov formulára (ak neexistuje prvok formulára, ktorý odkazuje na pohyby dokladov).

• Ďalšie podrobnosti formulára:
  • vlastnosť povolená – atribút bude prítomný v údajoch formulára bez ohľadu na to, či existuje alebo nie je aspoň jeden prvok formulára, ktorý je spojený s atribútom alebo jeho podriadeným atribútom;
  • vlastnosť je vypnutá – atribút bude prítomný v údajoch formulára iba vtedy, ak je k atribútu alebo jeho podriadenému atribútu priradený prvok formulára. Na rozdiel od dynamických zoznamových rekvizít tu nezáleží na viditeľnosti prvku spojeného s rekvizitou.

Poznámka. Malo by sa pamätať na to, že vlastnosť nastavená na nadradenom atribúte ovplyvňuje všetky podriadené atribúty. Napríklad, ak je vlastnosť Použiť vždy vymazaná pre tabuľkovú časť dokumentu, potom systém usúdi, že táto vlastnosť je vymazaná aj pre všetky podriadené atribúty (napriek skutočnému stavu vlastnosti).

Metódy prevodu údajov aplikačného objektu na údaje formulára

Na konverziu objektov aplikácie na údaje formulára a naopak existuje súbor globálnych metód:

• ValueInFormData(),
• FormDataToValue(),
• CopyFormData().

Dôležité! Metódy, ktoré pracujú s objektmi aplikácie, sú dostupné iba v procedúry servera. Metóda kopírovania hodnôt medzi údajmi formulára je dostupná na serveri a na klientovi, pretože nevyžaduje aplikačné objekty ako parametre.

Pri prevode údajov formulára na objekt aplikácie je potrebné vziať do úvahy kompatibilitu.

• ValueToFormData() – konvertuje objekt typu aplikácie na údaje formulára;
• FormDataToValue() – konvertuje údaje formulára na objekt typu aplikácie;
• CopyFormData() – skopíruje údaje formulára, ktoré majú kompatibilnú štruktúru. Vráti hodnotu True, ak je kopírovanie úspešné, alebo False, ak je štruktúra objektov nekompatibilná.

Poznámka. Pri vykonávaní štandardných akcií (otvorenie formulára, vykonanie štandardného príkazu Uložiť a pod.) formulára s hlavným atribútom sa konverzia vykoná automaticky.

Uveďme príklad, ako použiť transformáciu údajov vo vlastných algoritmoch.

&OnServerCreateProcedureOnServer(zlyhanie, štandardné spracovanie)

ObjectProduct = Directories.Products.FindBy Name("Kávovnička").GetObject(); ValueVFormData(ObjectItem, Object);

EndProcedure

&OnClient Procedure Write()

WriteOnServer();

EndProcedure

&AtServer Postup WriteAtServer()

ObjectProduct = FormDataToValue(Object, Type("CatalogObject.Products")); ObjectItem.Write();

EndProcedure

Objekt ManagedForm má na serveri dostupné aj metódy:

• ValueVFormAttribute() – konvertuje objekt typu aplikácie na špecifikovaný atribút formulára.
• FormAttributeToValue() – konvertuje atribút údajov formulára na objekt typu aplikácie.

Použitie týchto metód je zvyčajne pohodlnejšie, pretože majú napríklad informácie o type atribútu formulára. Okrem toho metóda FormAttributeToValue() nastavuje súlad medzi údajmi formulára a objektom, ktorý sa používa pri generovaní správ. Viac sa o tom dočítate v kapitole „Možnosti služby navigácie“.

Uveďme príklad použitia týchto metód.

&AtServer Procedúra RecalculateAtServer()

// Skonvertuje atribút Object na aplikačný objekt. Dokument = FormAttributeToValue("Object"); // Vykoná prepočet metódou definovanou v module dokumentu. Document.Recalculate(); // Skonvertuje objekt aplikácie späť na rekvizity. ValueVFormAttribute(Dokument, "Objekt");

EndProcedure

Softvérové ​​rozhranie

FormDataTree (FormDataTree)

• FindById (FindById)
• GetItems (GetItems)

Popis:

Navrhnuté na modelovanie stromu v údajoch spravovaného formulára.

Tento objekt je možné serializovať do/z XDTO. V mennom priestore je definovaný typ XDTO zodpovedajúci danému objektu. Názov typu XDTO:

GetItems (GetItems)

Syntax:

GetItems()

Návratová hodnota:

Typ: FormDataTreeItemsCollection.

Popis:

Získa kolekciu prvkov stromu najvyššej úrovne.

Dostupnosť: klient, server, tenký klient, webový klient.

FindById (FindById)

Syntax:

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

Možnosti:

<Идентификатор>(požadovaný)

Typ: Číslo. ID prvku stromu.

Návratová hodnota:

Typ: FormDataTreeElement.

Popis:

Získa prvok kolekcie podľa ID.

Dostupnosť: klient, server, tenký klient, webový klient.

FormDataTreeItem (FormDataTreeItem)

Vlastnosti:

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

• GetId (GetId)
• GetParent (GetParent)
• GetItems (GetItems)
• Nehnuteľnosť

Popis:

Prvok stromu údajov formulára.

FormDataTreeItemCollection (FormDataTreeItemCollection)

Položky zbierky: DataFormElementTree

Pre objekt je možné prechádzať zberom pomocou operátora Pre každý ... Od ... Slučka. Priechod vyberá prvky kolekcie. K prvku kolekcie je možné pristupovať pomocou operátora [...]. Index prvku sa odovzdá ako argument.

• Vložiť
• Pridať
• Index (IndexOf)
• počítať
• jasný
• Získať (získať)
• Pohybujte sa
• Odstrániť

Popis:

Zbierka prvkov stromu.

Dostupnosť: klient, server, tenký klient, webový klient.

Pozri tiež:

• DataFormItemTree, metóda GetItems
• FormDataTree, metóda GetItems

Vlastnosti práce so stromom hodnôt

Aktualizácia stromu

Je tu problém pád platformy pri aktualizácii stromu.

Ak bol v strome rozšírený uzol a bol vybratý podriadený uzol, potom pri aktualizácii stromu pomocou funkcie ValueInDataForms pády platformy.

Riešenie: Pred aktualizáciou musíte vymazať strom.

Napríklad:

&Procedúra na serveri ClearTree(elements) Pre každý prvok prvkov Loop ClearTree(element.GetElements()); EndCycle; elementy.Clear(); EndProcedure

&AtServer Procedúra FillConceptTree() dConcepts = cProperties.BuildConceptTree(OnDate, Meta.CurrentIB()); ClearTree(Strom konceptu.GetItems()); ValueVFormData(dConcept, ConceptTree); EndProcedure

&Pri procedúre klienta OnDateOnChange(Element) FillConceptTree(); EndProcedure

Formulár sa ovláda pomocou rôznych formulárových prvkov, ktoré sú hierarchicky umiestnené na záložke Prvky konštruktor formulárov. Najdôležitejším prvkom je samotný formulár, ktorý sa nachádza na vrchole hierarchie prvkov a ostatné prvky sú mu podriadené.

Všetky prvky formulára možno rozdeliť do piatich skupín: polia, prvky zoskupovania, tlačidlá, dekorácie a tabuľky. Vo svojich článkoch rozoberiem každú zo skupín. V tomto článku začneme skúmať jeden z typov prvkov poľa − vstupné pole, ale predtým sa naučíme, ako pridať prvok do formulára.

Pridávanie prvkov do formulára

To sa robí celkom jednoducho: musíte vybrať prvok Formulár v okne Prvky návrhu formulára a kliknite na tlačidlo Pridať. Potom sa otvorí okno, v ktorom musíte vybrať požadovaný typ prvku.

Po výbere sa v okne zobrazí požadovaná položka Prvky.

Prvok spravovaného formulára Lúka

Poďme sa pozrieť na prvok spravovaného formulára Lúka. Tento prvok je potrebný na zadanie informácií do formulára. A tiež na zobrazenie akýchkoľvek informácií. Po pridaní tohto prvku do formulára sa vpravo otvorí paleta vlastností prvku formulára. Zatiaľ by vás mali zaujímať dve vlastnosti – DataPath a View.

Vo vlastnosti DataPath môže vývojár priradiť element formulára k požadovanému atribútu formulára. Všimnite si, že po pridaní prvku Vstupné pole na formulári to nebolo zobrazené na samotnom formulári. Je to preto, že náš nový prvok nesúvisí s . Vo formulári spracovania som napríklad vytvoril niekoľko atribútov s rôznymi primitívnymi typmi a jeden atribút s typom odkazu.

Teraz priraďme náš novo pridaný prvok formulára k jednému z atribútov, na tento účel vyberieme požadovaný atribút z vlastnosti DataPath prvku.

Potom sa vyplnia vlastnosti DataPath a View a samotný prvok sa zobrazí v zobrazení formulára.

Venujte pozornosť vlastnosti prvku vyhliadka. Táto vlastnosť definuje funkčnosť vstupného poľa. Pre túto vlastnosť môžete vybrať rôzne hodnoty.

V závislosti od zvolenej hodnoty sa určí funkčnosť. Na obrázkoch vyššie je vybratá hodnota - vstupné pole, t.j. do tohto vstupného poľa môžeme zadať ľubovoľné hodnoty a ak vyberieme hodnotu nápisové pole, potom nemôžeme zadať nič.

Táto hodnota nehnuteľnosti vyhliadka vstupné polia sú vhodné na výber, keď ich potrebujete len zobraziť informácie o pozadí užívateľ.

Teraz pridajme nový prvok formulára s typom Vstupné pole a prepojiť ho s rekvizitami PodrobnostiDátum cez už známu vlastnosť DataPath

Ako vidíte, zmenil sa vzhľad vstupného poľa a zmení sa aj možný výber hodnôt pre vlastnosť View.

Dospeli sme teda k záveru, že funkčnosť vstupného poľa závisí od typu atribútu.

Pre rekvizity s typom boolovská hodnota budú dostupné nasledujúce hodnoty vlastnosti View.

A pre atribút s typom odkazu budú k dispozícii ďalšie hodnoty vlastnosti Kind.

Podrobnejšia práca s formulárovými prvkami pomocou praktických príkladov je uvedená v knihe „Základy rozvoja v 1C: Taxi. Vývoj spravovanej aplikácie v 12 krokoch.

Niekedy sa zdá, že naučiť sa programovací jazyk v 1C je ťažké a ťažké. V skutočnosti je programovanie v 1C jednoduché. Moje knihy vám pomôžu ľahko a rýchlo zvládnuť programovanie v 1C: a „Základy vývoja v 1C: Taxi“

Naučte sa programovať v 1C pomocou mojej knihy „Programovanie v 1C v 11 krokoch“

1. Žiadne zložité technické výrazy.
2. Viac ako 700 strán praktického materiálu.
3. Každá úloha je doplnená obrázkom (snímka obrazovky).
4. Zbierka úloh na domáce štúdium.
5. Kniha je písaná zrozumiteľne a jednoduchý jazyk- pre začiatočníka.

Táto kniha je vhodná pre tých, ktorí už s programovaním začali a majú s touto témou určité ťažkosti a pre tých, ktorí programujú už dlho, ale nikdy nepracovali s riadenými formulármi 1C.

1. Žiadne zložité technické výrazy;
2. Viac ako 600 strán praktického materiálu;
3. Každý príklad je doplnený obrázkom (snímka obrazovky);
4. Kniha je odoslaná na email v vo formáte PDF. Dá sa otvoriť na akomkoľvek zariadení!

Promo kód na 15% zľavu - 48PVXHeYu

Ak vám táto lekcia pomohla vyriešiť akýkoľvek problém, páčila sa vám alebo bola užitočná, môžete podporiť môj projekt prevodom akejkoľvek sumy:

je možné zaplatiť manuálne:

Yandex.Money — 410012882996301
Web Money - R955262494655

Pridajte sa k mojim skupinám.

A štruktúrovanie objektu prenosu údajov do kódu, riadená forma v prostredí 1C 8.2.

Úvod

Sprístupnený v roku 2008 novú verziu platforma 1C: Enterprise 8.2 (ďalej len Managed Application), ktorá úplne mení celú vrstvu práce s rozhraním. To zahŕňa príkazové rozhranie, formuláre a systém okien. Tým sa nielen mení model vývoja používateľského rozhrania v konfigurácii, ale navrhuje sa aj nová architektúra oddelenia funkčnosti medzi klientskou aplikáciou a serverom.
Spravovaná aplikácia podporuje nasledujúce typy klientov:

• Hrubý klient (normálny a riadený režim spustenia)
• Tenký klient
• Webový klient

• Deklaratívny, nie "po pixeloch" popis štruktúry. Konkrétne umiestnenie prvkov vykoná systém automaticky pri zobrazení formulára.
• Všetky funkcie formulára sú popísané vo formulári podrobnosti a príkazy. Podrobnosti sú údaje, s ktorými formulár pracuje, a príkazy sú vykonané akcie.
• Formulár sa spúšťa na serveri aj na klientovi.
• V kontexte klienta nie sú dostupné takmer všetky typy aplikácií, a preto nie je možné meniť údaje v infobáze.
• Pre každú metódu alebo premennú formulára musí byť špecifikovaná kompilačnej smernice A, ktoré určuje, či je miesto vykonania (klient alebo server) a prístup ku kontextu formulára.

• &AtClient
• &Na serveri
• &OnServerWithoutContext
• &Na klientoviNa serveriBezkontextu

Všetky ďalšie diskusie budú o pravej strane ilustrácie, o tom, ako štruktúrovať kód modulu a aké princípy vám umožnia implementovať efektívnu interakciu klient-server.

Definujme problém

Zvážte štruktúru kódu (modul formulára) v niekoľkých formách jedného typická konfigurácia a pokúsiť sa nájsť vzory.
Pod štruktúrou máme na mysli sekcie kódu (najčastejšie sú to bloky komentárov) pridelené vývojárom na zoskupovanie metód a direktívy na zostavovanie týchto metód.
Príklad 1:
Sekcia obsluhy udalostí Metóda - na klientovi Metóda - na serveri Metóda - na klientovi Sekcia servisných procedúr a funkcií Pomocné funkcie riadenia vstupu
Príklad 2:
Servisné postupy a funkcie Platobné doklady Cennosti Obsluhovatelia udalostí
Príklad 3:
Servisné procedúry na serveri Servisné procedúry na klientovi Servisné procedúry na serveri bez kontextu Obslužné nástroje udalostí hlavičky Príkazové obsluhy udalostí
Príklad 4:
Univerzálne postupy Obslužné nástroje udalostí formulára Postupy podsystému „kontaktné informácie“.
V skutočnosti chýba štruktúra kódu, alebo mierne povedané, je podobná tomu, čo bolo vo formulároch 8.1:

• Neinformatívne slová "General, Service, Auxiliary."
• Nesmelé pokusy oddeliť metódy klienta a servera.
• Metódy sú často zoskupené podľa prvkov rozhrania „Práca s tabuľkovou časťou Produkty, Kontaktné informácie“.
• Ľubovoľné usporiadanie metód a kódových skupín. Obslužné rutiny udalostí môžu byť napríklad v jednom formulári navrchu, v druhom na spodku, v treťom nie sú vôbec zvýraznené atď.
• A nezabúdajme, že toto všetko je v rámci rovnakej konfigurácie.
• Áno, existujú konfigurácie, v ktorých sú slová „General, Service, Auxiliary“ vždy na rovnakých miestach, ale ...

Prečo potrebujete štruktúru kódu?

• Zjednodušenie údržby.
• Zjednodušiť učenie.
• Stanovenie všeobecných/dôležitých/úspešných zásad.
• ...vaša možnosť

Prečo existujúci vývojový štandard od 1C nepomáha?

• Minimalizujte počet volaní servera.
• Maximálny výpočtový výkon na serveri.
• Nekontextové volania servera sú rýchlejšie ako kontextové volania.
• Program s ohľadom na interakciu klient-server.
• atď.

Dizajnové vzory či generačná múdrosť

• Vzdialená fasáda(ďalej len Rozhranie vzdialený prístup)
• Objekt prenosu údajov(ďalej len objekt prenosu údajov)

• … každý objekt potenciálne určený na vzdialený prístup musí mať rozhranie s nízkou granularitou, čo minimalizuje počet hovorov potrebných na vykonanie konkrétneho postupu. … Namiesto samostatného vyžiadania faktúry a všetkých jej bodov je potrebné prečítať a aktualizovať všetky body faktúry v rámci jednej výzvy. Toto ovplyvňuje celú štruktúru objektu...Pamätajte: rozhranie vzdialeného prístupu neobsahuje doménovú logiku.
• ... keby som bola starostlivá matka, určite by som svojmu dieťaťu povedala: „Nikdy nepíšte objekty prenosu dát!“ Vo väčšine prípadov nie sú objekty migrácie údajov ničím iným nafúknutý fieldset… Hodnota tohto nechutného monštra spočíva výlučne v možnosti prenášať viacero informácií cez sieť v rámci jedného hovoru- recepcia, ktorá má veľký význam pre distribuované systémy.

Príklady šablón na platforme 1C

V kontexte riadeného formulára množina „Objektov prenosu údajov“. Dá sa rozlíšiť systémový a definované vývojárom.
Systémové modelujú objekt aplikácie na klientovi vo forme jedného alebo viacerých dátových prvkov formulára. Nemôžete ich vytvoriť mimo väzby na podrobnosti formulára.

• DataFormsStructure
• DataFormsCollection
• DataFormStructureCollection
• DataFormsTree

• ValueVDataForm()
• FormDataToValue()
• CopyFormData()
• ValueVFormProps()
• FormAttributeToValue()

Objekty migrácie údajov, ktorých štruktúru definuje vývojár, sú malou podmnožinou typov dostupných na klientovi aj na serveri. Ako parametre a výsledky metód „hrubého“ rozhrania sa najčastejšie používajú:

• Primitívne typy (reťazec, číslo, boolean)
• Štruktúra
• Zhoda
• pole
• Odkazy na objekty aplikácie (jedinečný identifikátor a textová reprezentácia)

Štruktúrovanie kódu

• Jasné oddelenie kódu klienta a servera. Nezabúdajme, že v čase vykonávania ide o dva interagujúce procesy, pričom v každom sa dostupná funkcionalita výrazne líši.
• Jasný výber rozhrania vzdialeného prístupu, ktoré serverové metódy možno volať z klienta a ktoré nie? Názvy metód vzdialeného rozhrania začínajú predponou „Server“. To vám umožňuje okamžite vidieť prechod kontroly na server pri čítaní kódu a zjednodušuje používanie kontextových rád. Všimnite si, že oficiálne odporúčanie (ITS) navrhuje metódy pomenovania s postfixami, ako napríklad ChangeOrderStatusOnServer(). Aby sme však zopakovali, nie všetky serverové metódy je možné volať z klienta, a preto je logická dostupnosť dôležitejšia ako umiestnenie kompilácie. Preto predponou „Server“ označujeme len metódy dostupné klientovi, príklad metódy sa bude volať ServerChangeOrderStatus().
• Čitateľnosť. Vec vkusu, akceptujeme objednávku, keď modul začne s procedúrami vytvárania formulára na serveri a metódami vzdialeného prístupu.
• Udržiavateľnosť. Miesto na pridanie nového kódu musí byť jasne definované. Dôležitým bodom je, že na koniec modulu sú pridané metódy automaticky vytvorené konfigurátorom. Keďže obslužné rutiny udalostí prvkov formulára sa najčastejšie vytvárajú automaticky, príslušný blok sa umiestni ako posledný, aby sa každý obslužný program nepretiahol na iné miesto v module.

• Grafická možnosť - jasne zobrazuje hlavný tok vykonávania.
• Možnosť text je príkladom návrhu šablóny na rýchle vloženie štruktúry do nový modul formulárov.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор="" Dátum = ""/> // <Описание> // // ////////////////////////////////////////////////// / /////////////////////////////// PREMENNÉ MODULU /////////////// / ///////////////////////////////////////////////// // ////////////// // NA SERVERI //******* UDALOSTI NA SERVERI ******* &Na Serveri Postup Pri CreationNa Serveri( Zlyhanie, štandardné spracovanie) //Vložiť obsah obslužného programu EndProcedure //******* ROZHRANIE NA VZDALENÝ PRÍSTUP ******* //******* OBCHODNÁ LOGIKA NA SERVERI **** *** /////////////////////////////////////////////// /////////////////////////////////// METÓDY SPOLOČNÉHO KLIENTA A SERVERA ///////// ////////////////////////////////////////////////// //////////////// //////// // NA KLIENTOVI //******* OBCHODNÁ LOGIKA NA KLIENTOVI ******* //******* PRÍKAZY ******** //******* UDALOSTI U KLIENTA ****** /////////////// ////////////////////////////////////////////////// ///////////////// / HLAVNÍ OPERÁTORI PROGRAMU

Súvisiace otázky

• Možnosti implementácie rozhrania vzdialeného prístupu. Asynchrónnosť, granularita...
• ukladanie do vyrovnávacej pamäte. 1C urobilo nešťastné architektonické rozhodnutie, ktoré zaviedlo ukladanie do vyrovnávacej pamäte iba na úrovni metód volania bežných modulov a neposkytlo možnosti ovládania (aktuálny čas, resetovanie na požiadanie).
• Implicitné volania servera. Nezabudnite na technologické funkcie, veľa "neškodných" operácií na klientovi vyprovokuje platformu na prístup k serveru.