Subsystém v 1C 8.3— objekt stromu metadat, který je zodpovědný za vytvoření rozhraní konfiguračního příkazu.

Níže v článku budeme hovořit o podsystémech počínaje verzí 8.2.

Faktem je, že verze 8.1 (stejně jako běžná aplikace 8.2) měla také subsystémy, které však sloužily úplně jiným účelům, spíše pro vývojáře než pro uživatele. Pomocí subsystémů v 8.1 byly obvykle odděleny různé funkce. Subsystémy také pomohly při kombinování různých konfigurací 1C - bylo možné určit, který systém přenést.

1C subsystémy a programátorské rozhraní

Ve verzích 8.3 a 8.2 jsou subsystémy hlavním nástrojem pro vytváření příkazového uživatelského rozhraní. Subsystémy metadatové objekty mají hierarchická struktura Chcete-li nakonfigurovat „podnabídku“ v rozhraní, musíte přidat podřízený podsystém:

Vlastnosti a nastavení

Podívejme se na nastavení a vlastnosti subsystémů v konfigurátoru:

Získejte 267 videolekcí na 1C zdarma:

Zahrnout do příkazového rozhraní— pokud jste zapomněli nastavit tento příznak, subsystém se nezobrazí v rozhraní.

Tlačítko otevře panel nastavení rozhraní, kde můžete konfigurovat rozhraní v závislosti na roli aktuálního uživatele:

Obrázek— obrázek přiřazený subsystému se zobrazí v podnikovém režimu. Můžete vybrat standardní obrázek nebo přidat svůj vlastní tím, že jej nejprve vytvoříte jako konfigurační objekt Obrázek:

Na kartě Funkční možnosti označuje seznam funkčních možností, ve kterých se tento subsystém používá.

Tab Sloučenina definuje sadu objektů metadat účastnících se daného subsystému.

Na kartě jiný můžete popsat nápovědu pro subsystém a zadat nastavení Zahrnout do obsahu nápovědy— zda zahrnout tuto část nápovědy do obecné informace o pozadí podle konfigurace.

Pokud ve spravovaném rozhraní nevidíte sestavu nebo zpracování

Tento problém se velmi často objevuje mezi začínajícími vývojáři - zdá se, že do subsystému byla přidána zpráva nebo zpracování, ale není vidět.

Prvním důvodem může být to, že objekt nemá definovanou řízenou formu.

Druhým důvodem je, že na kartě Příkazy objektu je zaškrtnuto políčko „Použít standardní příkazy“. To je způsobeno tím, že k otevření zpracování lze popsat buď vlastní postup, nebo lze použít standardní:

Článek pokračuje v sérii „První kroky ve vývoji 1C“.

V konfiguraci na platformě 1C:Enterprise se při zobrazování informací nejčastěji používají tabulky, které zobrazují různé informační seznamy. Práce s takovými seznamy může probíhat jak ve formě seznamu, tak ve formě prvku (zpracování).

V tomto článku se seznámíme s těmito možnostmi přizpůsobení seznamů a také se podíváme na další funkce přizpůsobení formulářů ze strany uživatele.

Použitelnost

Článek pojednává o Managed Interface ve verzi „Version 8.2“ konfigurace vyvinuté na platformě 1C 8.3.4.482.

Pokud pracujete s konfiguracemi, které toto rozhraní podporují, pak jsou informace pro vás relevantní a aktuální verze platformy.

Pokud pracujete v novém rozhraní Taxi, mohou se názvy některých konfiguračních příkazů a také obecný sled akcí mírně lišit.

Současná verze platformy navíc přidala nové možnosti vyhledávání v seznamech.

Nastavení formulářů a práce se seznamy

U spravovaných formulářových prvků je možné změnit viditelnost a některé další vlastnosti. Pro tyto účely v ve zvládnutelné formě v nabídce Všechny akce slouží jako položka Změnit formulář.

Po kliknutí na tento příkaz se zobrazí okno „Nastavení formuláře“.

V okně, které se zobrazí, můžete pomocí zaškrtávacích polí změnit viditelnost některých detailů. V tomto případě se měřítko formuláře automaticky změní.

Můžete změnit pořadí podrobností. Přidejte novou skupinu a umístěte do ní některé detaily (prvky), definující možnost jejich seskupení (horizontální, vertikální).

Podrobnosti obsažené ve skupině budou odpovídajícím způsobem zveřejněny. Kromě toho můžete pro prvky nakonfigurovat vlastnosti, jako je šířka, výška a data záhlaví.

Můžete definovat atributy, které se aktivují při otevření formuláře.

Důležitou funkcí je možnost přidávat do formuláře nová pole. To je možné díky atributům typu odkazu.

Například mít ve formuláři atribut typu odkazu Protistrana, může přidat Kontaktní osoba, Pokud tato rekvizita je přítomen v adresáři „Protistrany“.

V případě potřeby lze odstranit další pole. Pole vytvořená v konfigurátoru nelze smazat. Všechna nastavení provedená uživatelem se uloží.

Návrat ke standardnímu nastavení v okně Nastavení formuláře v nabídce Všechny akce měli byste vybrat položku Nainstalujte standardní nastavení .

Kromě přizpůsobení formulářů ve spravovaném rozhraní je možné přizpůsobit seznamy (prvky adresáře, dokumenty).

Ve formě seznamu v nabídce Všechny akce obsahuje speciální příkaz Přizpůsobte seznam.

Otevře se okno „Nastavení seznamu“. V tomto okně můžete vybírat, třídit, definovat podmíněné formátování a seskupování.

Na obrázku je formulář pro úpravu výběru.

Výběr lze provést pomocí několika polí. V tomto případě bude výběr standardně fungovat podle podmínky AND, můžete také použít podmínky OR a NOT.

Chcete-li použít podmínku OR (NOT), musíte přidat příslušnou skupinu (OR Group, NOT Group) pomocí příkazu Group Conditions.

Obrázek ukazuje formulář pro definování třídicích polí.

Seskupování lze konfigurovat. Na obrázku je vybráno pole pro seskupení Protistrana.

Následující obrázek ukazuje, jak se bude seskupování provádět.

Seznam můžete libovolně obarvit nebo aplikovat další prvky podmíněného návrhu (výběr písma, specifické formátování) podle dané podmínky a také vybrat seznam polí k formátování.

Obrázek ukazuje výsledek podmíněného návrhu pozadí pole Součet.
Když je částka > 100 000.

Je třeba poznamenat, že je možné prohlížet adresáře v režimu hierarchie.

Hierarchické prohlížení adresářů lze konfigurovat prostřednictvím položky Režim zobrazení v nabídce Všechny akce. Můžete si vybrat jednu z možností: Hierarchický seznam, Seznam, Strom.

Je také možné nakonfigurovat vlastní seskupení prvků adresáře podle určitých detailů.

Můžete například seskupit položky podle dodavatele. Příklad je podobný tomu, kde jsme se zabývali seskupováním dokumentů „Prodej zboží a služeb“ podle protistran.

Pohodlnou funkcí je vícenásobný výběr v seznamech a následné provádění skupinových akcí (zaúčtování, zrušení, odškrtnutí smazání).

Objekty v seznamu se vybírají podržením klávesy Posun nebo Ctrl.

Hledání určité hodnoty v seznamu má své vlastní charakteristiky. Vyhledávání funguje v režimu výběru. Zůstanou pouze ty řádky, které splňují podmínku vyhledávání.

Pro vyhledávání podle hodnoty v aktuálním sloupci stačí umístit kurzor na požadovaný sloupec a kliknout na tlačítko Nalézt v příkazovém panelu. Zobrazí se okno, ve kterém byste také měli kliknout na tlačítko Nalézt.

Chcete-li vyhledávání upřesnit, můžete použít zaškrtávací políčko Hledat v nalezeném.

Při hledání řádku dat referenčního typu (například měrných jednotek) byste měli vybrat příslušnou možnost vyhledávání ...(po řádku).

To končí seznamy a způsoby jejich konfigurace. V dalším článku budeme pokračovat v seznamování s rozhraním a podíváme se na pohodlný nástroj pro informování uživatele, o kterém jsme dosud nemluvili. Co je to za nástroj? :)

Domnívám se, že není třeba vysvětlovat, co je systém kontroly přístupu, skladatel nastavení a obecně celá sada objektů navržených pro práci se systémem kontroly přístupu. Hlavními oblastmi použití, nepočítaje záludné akce v kódu, jsou dynamické seznamy a sestavy, přičemž v obou případech zůstává velmi významná funkcionalita v pozadí. Často ani nepřemýšlíme o logice chování a vztahů všech účastníků procesu, protože Obvykle řešíme poměrně jednoduché problémy nebo se spoléháme na výchozí nastavení platformy. Ale tam, kde jsou mlčení, existuje také vnitřní logika, jakási „medvědí služba“ 1C, jejíž plody je někdy obtížné a zjevné překonat, aby bylo dosaženo požadovaného účinku, a přitom stačí jen správně používat nástroje.

Zájemci mohou přeskočit díly 1-4 a přejít rovnou k příkladům.

Pokusím se trochu podrobněji pozastavit nad fungováním ACS výběrů pro případ jejich použití v reportech. Myslím, že chování v dynamické seznamy, s řadou rezervací, bude blízko. Takže výběry v reportech, trocha teorie a pak konkrétní příklady.

Jsou použity SP 8.3.6 a vyšší, sekce ITS (článek 10.3.7.5 atd.), kniha „Profesionální rozvoj v systému 1C-Enterprise 8“ (Kazan, 2012, druhý díl). V knize E. Khrustaleva nebylo na toto téma vůbec nic srozumitelného.

Část 1

Tvůrce nastavení, jak víte, má kolekce „Nastavení“, „Pevná nastavení“ (dále jen „FN“) a „Vlastní nastavení“ (dále jen „CU“). Zpráva může mít několik možností a spojení mezi možností N, PN a FN jsou velmi unikátní. Také nezapomínejme na zdroj dostupná nastavení, a jeho „předchůdce“, což je obvykle samotný obvod, který má také své vlastní výchozí nastavení.

* Nastavení – nastavení vytvořená v režimu Konfigurátor a změněná v režimu úpravy verze sestavy;

* UserSettings – nastavení, která uživatel změní v režimu „1C:Enterprise“ čistě přes rozhraní;

* FixedSettings – tato nastavení, která jsou nastavena z vestavěného jazyka, vč. jsou implicitně nastaveny systémem. Tato vlastnost obsahuje hodnoty výběru, které se přenášejí do formuláře pomocí jeho parametrů (struktura „Výběr“).

Nastavení a FN mají podobný design a mají kolekci „Výběr“ typu „Výběr složení dat“, která je k dispozici pro změnu složení kdykoli během existence zprávy. Současně jsou k dispozici Nastavení pro změny rozhraní prostřednictvím úpravy varianty, ale FN nejsou vůbec přístupné. PN je zase „kaše“, kde rovnými prvky mohou být jak samotný „Výběr“, tak jednotlivé objekty typu „Prvek výběru datové kompozice“ (tzv. vnořený objekt). Navzdory dostupnosti vhodných metod není možné programově změnit složení kolekce prvků PN, pokud se jedná o PN samotné sestavy a nejsou vytvořeny „od nuly“ návrhářem - 1C oznámí, že „Sbírka uživatelů nastavení nemůže změnit jeho složení, protože je spojeno s daty nastavení rozvržení." ITS říká: „Na nemovitost nelze zapisovat pomocí vestavěného jazyka.“, ale jak uvidíme později, je možné ovlivnit PN. „Kaše“ předmětů má interní komunikace– kontroluje se konzistence podmínek při generování zprávy a při změně složení. Na ITS čteme: „Prvky, které jsou samy označeny jako vlastní, nebudou přidány. Vlastní výběr například nebude obsahovat prvek výběru, který je označen jako vlastní. Prvky obsahující vlastní prvky nebudou přidány. Například skupina podmínek nebude přidána, pokud skupina obsahuje prvky označené jako vlastní. U vnořených prvků se vlastnost DisplayMode neanalyzuje. Přidávají se nebo nepřidávají spolu s rodičovské prvky." „Seniorita“ objektů tedy působí v zákulisí. V tomto případě můžete získat efekt, když vám rozhraní umožňuje zadat protichůdné výběry pro variantu a její PN, stejně jako v rámci PN.

Zdálo by se, že možností je „senior“. Ale kliknutím na „Více“ / „Možnost změny“ a potvrzením změn v otevřeném formuláři vyvoláte obsluhu události formuláře , v tomto případě se výběr objeví v panelu "Základní" ve formuláři vyvolaném z "Nastavení..." a objeví se ve formuláři zprávy, ale NENÍ zobrazen na kartě "Výběr"; Navíc se buď objeví okamžitě jak ve formuláři hlavní sestavy, tak ve formuláři „Nastavení...“ (pokud je příznak „Zahrnout do uživatelského nastavení“), nebo ani tam, ani tam. Ale v žádném případě NEBUDE na záložce „Výběr“ formuláře „Nastavení...“. Rozdíl mezi záložkou „Základní“, formulářem „Nastavení...“ a hlavním formulářem výkazu je dán polem „Režim úprav“ (normální – pouze v „Nastavení“, rychlý – i na samotném formuláři výkazu), ale myslím, že to ví každý. Mimochodem, hodnoty „Selection“ a „Fast“ nejsou nijak synchronizovány a mohou si odporovat, ale „Fast“ ve formuláři zprávy a ve formuláři nastavení jsou přísně synchronní. Takže, když upravíte variantu, sama se změní (ale její ID a název se nezmění), ale PN zůstanou nezměněny (tj. i když o nich mluvíme, tj. o příznaku pro zahrnutí toho či onoho). prvek v PN ).

Kliknutí na „Vybrat možnost...“ a potvrzení změn ve formuláři, který se otevře, spustí události v následujícím pořadí:

Při nahrávání OptionOn Server

Při aktualizaci složení uživatelských nastavení na serveru

V tomto případě se volba ani PN nijak nemění. Odtud je zřejmé, že možnost a nastavení, pokud jsou připojeny, nejsou v žádném případě přímo propojeny.

Kliknutím na „Nastavení...“ a potvrzením změn v otevřeném formuláři se pouze spustí událost Při aktualizaci složení uživatelských nastavení na serveru(v tomto případě se PN změní, ale pohledy a klíč (pokud tam nebyly) nejsou přijaty; pokud je pro prvky objektu PN „Výběr“ povoleno „Rychle“, pak kromě „Výběr“, jeho skutečné prvky se zobrazí jako pole, tj. chová se podobně jako vnořené prvky. Tato nastavení se uloží při zavření a obnoví se při příštím vstupu do formuláře. Možnost se nedotkne ani nemění.

Kliknutí na "Více"/"Nastavit standardní nastavení" ve formuláři nastavení (stejně jako na položku "Standardní nastavení" v editaci volby) pouze spustí událost Při aktualizaci složení uživatelských nastavení na serveru. V tomto případě se volba změní, ale změní se PN. Pokud byla volba změněna dříve, zůstane změněna (neresetuje se ani změněný příznak, ani se neresetují aktuální nastavení).

Kliknutím na „Vlastnosti prvku vlastního nastavení“ ve stromu struktury ve formuláři pro úpravu variant přidáte objekt „Výběr“, který se ukáže jako prázdný a není nijak synchronizován s existujícím výběrem varianty a existujícími vnořenými prvky výběru. varianta se nijak nemění.

Z toho plyne doporučení: pokud potřebujete nastavit určité výběry v režimu „Konfigurátor“, abyste se nevrtali s kódem a aby nebyly ve volbě, ale byly by v rozhraní sestavy, neměli byste s výběrem manipulovat prvků volby, změnou jejich vlastností, ale samotným výběrem pomocí tlačítek „Vlastnosti prvku…“ a „Vlastní nastavení“.

Přidání něčeho, co se objeví v Nastavení, do PN vyžaduje akce v kódu nebo rozhraní, ale smazání a vymazání Nastavení ovlivní PN okamžitě a bez jakýchkoli aktualizací, například:

Report.SettingsLitter.Settings.Selection.Items.Clear();

Před uzavřením formuláře hlášení se systém zeptá pouze na to, zda došlo ke změnám varianty. Pokud došlo ke změnám PN, budou automaticky uloženy bez jakýchkoliv otázek a také se automaticky pokusí uplatnit v další relaci práce s přehledem.

Poznámky:

V případě řady chyb v aplikaci nastavení se nejprve zobrazí hláška o problému a poté stále dochází ke skladbě, událost je tzv. a generování zpráv. V tomto případě jsou FN, i když existovaly, stále ignorovány a roli hrají pouze Nastavení.

Přidání výběru ve formuláři „Změnit možnost“ se provádí okamžitě s nastaveným příznakem „Zahrnout do PN“, ale opakuji, z hlediska vestavěného jazyka zůstává PN nezměněn.

Nastavení variace varianty a nastavení variace PN spolu přímo nesouvisí, jedná se o dva různé směry změn.

PN má mimo jiné „Další nastavení“. Nikdy jsem nedokázal pochopit, čím a v jakém okamžiku jsou naplněny. Zpráva sice obsahuje nastavení „označená ve výběru a podmíněném návrhu“ jako vlastní (podle společného podniku), ale další nastavení ve všech případech byly prázdné. Na ITS o tom nic není.

Navzdory prohlášení ve společném podniku jsou PN perfektně serializovány v xml.

Pokud jsou pro použití zahrnuty jak nezávislé prvky výběru, tak výběr samotný, je sestava sestavena správně, ale při zobrazení duplikuje informace o vytvořeném výběru v konečném rozložení.

Výchozí formulář pro úpravu verze sestavy obsahuje mnoho zajímavostí, ale nikde nefunguje s FN a PN a i se základním nastavením funguje spíše na čtení (až na to, že vymaže výběr, pořadí, konvence).

Část 2

Práce s Settings a FN prostřednictvím jejich kolekce je téměř vždy přijatelná, ale je důležité si uvědomit, že podstata „třetí úrovně“ se mění. První úroveň vždy obsahuje výchozí nastavení samotného systému řízení přístupu, která se také implicitně objevují ve zdroji dostupných nastavení; na druhé úrovni – nastavení použité volby. Zde však logika umožňuje buď „přepsat“ základní instrukce, nebo je ignorovat. Ale práce s PN již neumožňuje svobody a jemné manipulace musí být prováděny pomocí speciálních metod a někdy dočasných pomocných zprostředkovatelských objektů, například:

Comp=NewDataCompositionSettingsComposer; // můžete také spustit // comp.Initialize(SomeSettingsComposer.GetSourceofAvailableSettings()); comp.LoadSettings(SomeSettingsComposer.Settings); SomeSettingsComposer.LoadCustomSettings(comp.CustomSettings);

Tvůrce nastavení má metodu (), který načte hodnoty uživatelského nastavení předané jako parametr metodě. Metoda GetSettings() umožňuje získat kopii aktuálního nastavení (s ohledem na uživatelská nastavení). Metoda Stáhnout Nastavení() načte předaná nastavení do tvůrce nastavení (uživatelská nastavení se také znovu naplní na základě předaných dat s přihlédnutím k přítomnosti klíčů, viz příklad níže).

Použití vlastního nastavení na hlavní nastavení se provádí v metodě GetSettings() tvůrce nastavení. Provádějí se následující akce:

* U typů DataCompositionSelectionElement se obsah prvků zkopíruje do odpovídajících prvků vlastního nastavení.

* U typů Výběr rozvržení dat zůstávají prvky umístěné v hlavním nastavení a označené jako Nepřístupné beze změny. Prvky z PN se převádějí na hlavní. Jsou přidány na konec kolekce pro Selection.

* U typů DataCompositionSelectionElementGroup se vlastnost Usage nastavuje v odpovídajícím prvku hlavního nastavení (na základě znaménka použití prvku PN).

Část 3

Při vytváření konečných nastavení, abych citoval ITS, se různá nastavení kombinují následovně:

* Pokud je jakýkoli typ nastavení zcela označen jako vlastní, pak výsledná nastavení zahrnují PN. V tomto případě, pokud jsou některé prvky nastavení označeny jako nedostupné, pak tato nastavení budou umístěna do výsledného nastavení z vlastnosti Settings Composer.Settings.

* Pokud je jakýkoli typ nastavení označen jako vlastní ne zcela, ale prvek po prvku, pak prvky označené jako vlastní budou převzaty do výsledného nastavení z vlastnosti Settings Composer.CustomSettings a prvky označené jako nedostupné budou převzaty do výsledná nastavení z vlastnosti Settings Composer.Settings .

* Pevná nastavení jsou přidána k výsledným nastavením "tak jak jsou". V tomto případě je nepřijatelná situace, kdy FN a PN mají nastavení stejného názvu, například výběr se stejnou levou hodnotou v podmínce. Podotýkám, že i úplná shoda všech vlastností těchto podmínek je zakázána. Abych byl upřímný, je to trochu nelogické.

Chtěl bych poznamenat, že pokud jakýkoli fragment nastavení podléhá funkční možnosti a měl by být omezen, systém funguje „tiše“ - tento fragment odebere odkudkoli, nic nehlásí a během programových manipulací s takovým fragmentem , zpracovává „nečinné“ chyby, nevytváří, ale kód také nemá žádný účinek. Je však možné, že se různá vydání chovají odlišně.

Část 4.

Rozšíření formuláře reportu nám poskytuje parametry „FN“ a „PN“, ale nikde se nedoporučuje vyplňovat je přímo předáním do formuláře. Jak ukázaly experimenty, bez dalších tanečků s tamburínou je obsah těchto parametrů ignorován - je přepsán při inicializaci linkeru během procesu otevírání a při příjmu dříve uložených PN. Doporučuje se pracovat s PN klíči, pomocí kterých je můžete načíst z úložiště nastavení a následně je otevřít a použít, a to se děje automaticky na straně formuláře hlášení, nikoli na volacím formuláři.

Parametr „Source of AvailableSettings“ je automaticky přeložen do informací o tvůrci při vytvoření formuláře na serveru a nelze jej přepsat. Nebo spíše může, ale to se projeví až po úplném předefinování celého řetězce souvisejících objektů. V čem GetSourceAvailableSettings() vrátí Nedefinováno až do konce všech událostí otevření formuláře.

Dovolte mi poznamenat, že parametry formuláře, které v podstatě nejsou klíčovými parametry, „rozšíří“ svůj účinek na několik událostí, pokud je při otevírání nastaven příznak formace. Ano, v akci ProcessingCheckFillOnServer, vyvolané během otevírání a formování, bude k dispozici parametr „Výběr“, ale s ním, ale vyvolaný pouhým kliknutím uživatele na tlačítko „Generovat“, již nebude dostupný. To je způsobeno tím, že všechny tyto události jsou zpracovány v jedné „návštěvě“ na serveru, pokud je povolena formace při otevírání, a až na samém konci je řízení přeneseno na klienta a voláno PřiOtevření. V tomto případě se přirozeně ztratí neklíčové parametry.

Obecné pořadí provádění událostí při otevírání formuláře s příznakem pro vygenerování zprávy při otevření (o něco více, než je popsáno v části „Profesionální rozvoj“):

Když CreatedOnServer

Před nahráním možnosti na server

Při nahrávání OptionOn Server

Před nahráním uživatelských nastavení na server

Při načítání uživatelských nastavení na server

Při aktualizaci složení uživatelských nastavení na serveru

ProcessingCheckFillOnServer

PřiOtevření

V tomto případě se volba ani PN nemění, pokud nebylo vynaloženo zvláštní úsilí.

Část 5.

Nyní se podíváme podrobněji na úkol otevřít formulář sestavy s jeho konstrukcí a předem zadaným výběrem. Stručné informace jsou o tom informace na ITS a in metodická doporučení, ale je tam pokryt pouze samotný princip a nejsou odhaleny jemnosti. Chcete-li tedy kontextově volat sestavu, musíte do jejího formuláře předat parametr „GenerateOnOpen“ rovný True; a parametr Selection obsahující strukturu. Klíče struktury jsou názvy polí ACS nebo parametrů ACS a hodnoty jsou jejich hodnoty. Cituji SP, pokud existuje parametr ACS s názvem odpovídajícím názvu klíče struktury, pak bude hodnota nastavena na něj. Pokud není uveden žádný parametr, ale existuje pole, bude do tohoto pole přidán výběr. Přitom pokud je tam stejnojmenný parametr a pole, tak to systém prostě tiše ignoruje a nic nenainstaluje.

„Profesionální rozvoj“ poskytuje příklad změny (tj. zachycení a překonfigurování) PN „za běhu“ v události Před nahráním uživatelských nastavení na server, kde je předán argument obsahující aktuální PN. Ve skutečnosti tomu tak není vždy – mohou například nastat případy, kdy chyba při ukládání PN v předchozí relaci nebo nesrovnalosti mezi Nastaveními, FN a PN povedou k tomu, že argument „Nastavení“ bude prázdný. A co je nejzajímavější je, že v této události nebude možné jej plně překonfigurovat; to lze provést pouze „na konci“ sledu událostí, konkrétně v případě ProcessingCheckFillOnServer.

Podívejme se, co máme, než nahrajeme PN na server.

Pro jednoduchý případ, kdy v ACS není nic přednastaveno a v PN nejsou zahrnuty žádné prvky, je situace následující: Nastavení – prázdné; FN – obsahují správný výběr; Po obsahují prázdný výběr. Tvarování funguje správně, ale z uživatelského pohledu rozhraní odporuje vnitřnostem a odrazuje - výběr funguje, ale není vidět. Podobně, pokud povolíte Výběr v PN v nastavení struktury voleb, sestava se také sestaví s ohledem na výběr, ale uživatel také nevidí žádné výběry.

Nastavme předvolby (rovná se prázdným hodnotám) v nastavení ACS v Konfigurátoru a zahrneme je do PN. Teoreticky by měly FN vyplnit Nastavení a ty by měly vyplnit PN, ale ve skutečnosti máme: v Nastavení - Výběr s požadovaným prvkem, ale prázdnou pravou hodnotou, obsahují FN správný výběr a PN stále nic neobsahují. Navíc v tomto případě nebude sestava sestavena, protože pravá hodnota výběru je prázdná, navzdory hodnotě předané v parametru Vybrat.

Pokus o práci s prvky PN také nepřináší výsledky. U prvku PN můžete změnit pouze příznak „Použít“ a účast na „Rychle“. Hodnota výběru na rozhraní bude prázdná, systém nebude generovat žádné chyby. Podobně bude fungovat i pokus o práci s Výběrem PN, v debuggeru bude vidět správná hodnota jako správně vyplněná, ale na rozhraní nic neuvidíte. Připomínám, že změnit složení PN je nemožné. Jsou tedy nutné další triky. Například:

&Na serveru Procedura SetPresetSelections(UserSettings) If not Parameters.Property("Selection") Then Return EndIf; If Parameters.Selection.Quantity()=0 Then Return EndIf; rTypeEO=Type("Prvek výběru DataComposition"); Pro každý klíč From Parameters.Selection Loop pField=NewDataCompositionField(key.Key); // If (ValueType(kiz.Value)=Type("Array") orValueType(kiz.Value)=Type("ValueList")) a kiz.Value.Quantity()>1 Then pViewComparison=DataCompositionComparisonType.InL Jinak pComparisonType=DataCompositionComparisonType.Equals; endIf; // pNecessarySelection = Nedefinováno; // podívejte se, zda je v uživatelském nastavení Selection pNecessaryEO=Undefined; // zjistěte, zda existuje samostatný prvek výběru DataComposition v uživatelských nastaveních Pro každý elnastr From UserSettings.Elements Cycle If TypeValue(elnastr) = Type("DataComposition Selection") a pNecessarySelection=Undefined Then // může být pouze jeden pNecessarySelection= elnastr; // to by šlo udělat i mimo smyčku, ale kvůli prvkům je nutné protřídit uživatelská nastavení... Jinak If TypeZnch(elnastr) = pTypeEO Then // toto je výběrový prvek, může jich být mnoho z nich, ale nás zajímají ty, které nejsou inicializované nebo s povinným polem If elstr.LeftValue=pField nebo elstr.LeftValue=Nedefinováno a rNeedEO=Nedefinováno Then pNeedEO=elstr; endIf; endIf; EndCycle; // Pokud pRequiredSelection<>Undefined Potom // jde jako priorita pNecessaryEOFromSelection = Undefined; Pro každý elotb z cyklu pNecessarySelection.Elements If elotb.LeftValue=pField Then pNecessaryEOfromSelection=eloteb; Přerušit EndIf; EndCycle; If pNecessary EO from Selection = Undefined Then pNecessary EO from Selection = pNecessary Selection.Elements.Add(pType of EO); pNeedEOFromSelection.LeftValue=pPole; endIf; pNecessaryEOfromSelection.ComparisonType=pComparisonType; pNecessaryEOFromSelection.RightValue=kiz.Value; pNecessaryEOFromSelection.Use=True; // rNeededEO.Use=False; JinakIf pNecessarySelection=Nedefinováno a pNecessaryEO<>Undefined Potom // vložte prvek pNecessaryEO.LeftValue=pField; pNecessaryEO.ComparisonType=pComparisonType; pNeedEO.RightValue=kiz.Value; pNeedEO.Use=True; endIf; pNeed=Nedefinováno; Pro každý elotb Z Report.ComposerSettings.Settings.Selection.Elements Loop // přátelským způsobem by mělo existovat rekurzivní vyhledávání! If TypeValue(elotb)=pTypeEO a elotb.LeftValue=pField Then pNeed=elotb; Přerušit EndIf; EndCycle; If pNeed = Undefined Then pNeed = Report.Settings Composer.Settings.Selection.Elements.Add(pEOType); pNeed.LeftValue=pMargin; endIf; pNecessary.ComparisonType=pComparisonType; pNeed.RightValue=kiz.Value; pNeed.Use=True; //EndCycle; Report.Settings Composer.FixedSettings.Selection.Items.Clear(); // jinak to řekne, že se prvky protínají/protiřečí Konec procedury

Nejsprávnější způsob, jak to nazvat, je:

&Na serveru Postup Zpracování Vyplnění kontrol Na serveru (selhání, zkontrolované podrobnosti) Nastavte předdefinované výběry (Propojovač sestav. Nastavení. Uživatelská nastavení); Konec procedury

Potom bude kontextové volání, například z adresářového formuláře, vypadat takto:

&Procedura OnClient OpenReport(Command) If ValueFilled(Object.Link) Then ot=New Structure("LinkToDirectory",Object.Link); // takto se pole jmenuje v sestavě SDS Form Parameters = New Structure ("Selection, GenerateWhen Opening", select, True); OpenForm("Report.Report1.Form.ReportForm",FormParameters,ThisForm); endIf; Konec procedury

Část 6.

V případě potřeby změňte nastavení sestavy při práci s ní vč. jak při spuštění, tak po otevření je nejsprávnější změnit „od začátku“, tzn. z nastavení ACS. Změna schématu ACS se provádí pouze s objektem Zpráva (nebo Externí sestavou), nikoli s daty formuláře, a sama o sobě nic nemění - v Nastavení a v PN zůstává stejné jako bylo a může zůstat FN prázdný. Proto v závislosti na našich úkolech:

Po provedení

Report.Settings Composer.LoadSettings(SKD.DefaultSettings)

Změní se pouze možnost a nic víc;

Po provedení techniky uvedené v odstavci 2 (pomocí „prostředníka“ a metody NačístCustomSettings()

funguje pouze v případě, že resetujete aktuální PN pomocí rozhraní. Samy o sobě, pokud se volba změní, se nezmění. V tomto případě se výběr změní, ale nový prvek výběru nebude přidán.

Po provedení

ThisForm.CreateFormElementsUserSettings(,DisplayModeDataCompositionSettings.All)

plošina jen tiše padá. Testováno na několika různých verzích. A volat režim pro zobrazení nastavení jen pro rychlá nemá smysl – jejich složení jsme neovlivnili, takže se stejně nic nezmění.

A protože stále potřebujeme plně změnit nejen interní výběry, ale i zobrazení na formuláři sestavy a v souvisejících formulářích, musíme buď změnit pouze Výběr, nebo postupovat následovně:

&Na serveru Postup ChangeSKD() pObject = Form AttributesValue("Report"); selection=pObject.DataCompositionScheme.SettingsOptions.Get(0).Settings.Selection; eo = selection.Elements.Add(Type("DataCompositionSelectionElement")); eo.LeftValue=NewDataCompositionField("LinkToDirectory.Field1"); eo.ComparisonType=DataCompositionComparisonType.Equals; eo.RightValue=True; eo.Use=True; ValueВFormAttributes(pObject,"Report"); Report.SettingsLitter.LoadSettings(pObject.DataCompositionSchema.DefaultSettings); Report.SettingsComposer.Restore(); // žádoucí, i když to stále neovlivňuje FN. // ve skutečnosti je to přesně to, co lze nazvat změnou složení PN Pro každý e-mail From Report.ComponentSettings.Settings.Selection.Elements Cycle email.DisplayMode=ElementDisplayModeDataCompositionSettings.QuickAccess; If EmptyString(el.UserSettingsIdentifier) ​​​​Then // můžete pro prvek PN použít metodu electronicSetIdentifier, viz její nápověda v SP, tam je vše celkem jasné e.UserSettingsIdentifier="ID123"; // důležité - identifikátor může být JAKÝKOLI, nikoli UUID nebo GUID! el.ViewUserSettings="Test"; endIf; EndCycle; comp=NewDataCompositionSettingsComposer; comp.LoadSettings(pObject.DataCompositionSchema.DefaultSettings); Report.SettingsComposer.LoadCustomSettings(comp.CustomSettings); Pro každý e-mail From Report.Settings Composer.CustomSettings.Elements Cyklus email.DisplayMode=ItemDisplayModeDataLayoutSettings.QuickAccess; // vytáhněte EndCycle do formuláře zprávy; // a nyní to bude mít efekt: ThisForm.CreateFormElementsUserSettings(,DisplayModeDataCompositionSettings.QuickAccess); Konec procedury

Ve skutečnosti můžete tuto mechaniku studovat po dlouhou dobu. Tato publikace vyrostla ze studia způsobů řešení jednoho konkrétního problému, a je tedy značně jednostranná; ale mám podezření, že o vnitřní logice nastavení, zejména těch uživatelských, by se dala napsat samostatná kniha, o nic jemnější než ta Khrstalevova. Bohužel na to nemám čas ani energii. Kdo považuje konkrétní vývoj za užitečný, je již dobrý.

Některé věci byly experimentálně objasněny, a proto jsou kontroverzní. Ti, kteří vědí více, jsou vyzváni, aby kritizovali a komentovali.