Přepínače, běžná aplikace, spravované formuláře. Přepínače, normální aplikace, spravované formuláře 1c problémy se spravovanými formuláři
Platforma 1C:Enterprise umožňuje programově přidávat a upravovat prvky spravovaného formuláře. Podívejme se, proč to může být potřeba.
Programová úprava formuláře může být vyžadována v několika případech:
- Při dokončování typických konfigurací pro usnadnění následného postupu aktualizace. V tomto případě se změní pouze modul formuláře. Moduly se aktualizují mnohem snadněji než formulář.
- Při implementaci některých obecných algoritmů. Například v subsystému „Zákaz editace detailů objektů“ pro všechny objekty připojené k subsystému je programově vytvořeno tlačítko pro umožnění možnosti editace detailů.
- Při implementaci některých specifických algoritmů. Například pole pro úpravu dalších podrobností se vytvářejí v referenční knize Nomenklatury.
Ve spravovaném formuláři můžete programově přidávat, upravovat a odebírat:
- náležitosti;
- místní příkazy;
- Prvky.
Všechny tyto operace jsou možné pouze na serveru.
Programatická změna tvaru má omezení:
- Můžete odstranit pouze programově přidané atributy/příkazy/prvky. Objekty vytvořené v konfigurátoru nelze programově odstranit.
- Není možné přiřadit atribut jako hlavní.
Změna příkazů formuláře
Správa složení příkazů pro objekt ManagedForm mít sbírku Týmy
Přidat (< ИмяКоманды >)
Množství ()
Nalézt (< ИмяКоманды >)
Vymazat (< Команда >)
Kolekce příkazů je k dispozici na klientovi i na serveru. Úprava kolekce (metody Přidat () a Odebrat () ) je možná pouze na serveru. Můžete vyhledávat a získat počet prvků (metody Find () a Quantity () ) jak na klientovi, tak na serveru.
Jako příklad práce s formulářovými příkazy si vytvoříme nový příkaz ChangeHistory s názvem „Historie změn ...“, který bude volat handler DisplayHistory() . Vytvoření se provádí při otevření formuláře.
&Na serveru
Postup OnCreateOnServer (selhání, standardní zpracování)
tým = Příkazy. Přidat( "Historie změn");
tým . Akce = ;
tým . Titul = "Historie změn...";
EndProcedure
&AtClient
Postup Connected_DisplayHistory(Command)
// akce příkazů
EndProcedure
Obsluha příkazu musí být umístěna ve formuláři a musí mít direktivu kompilace &AtClient .
Změna podrobností formuláře
Čtení složení atributů formuláře provádí funkce Získejte podrobnosti(< Путь >), které vrací pole typu FormAttributes. Parametr funkce určuje cestu k nadřazenému atributu (jako řetězec). Pokud je parametr vynechán nebo je zadán prázdný řetězec, vrátí se pověření nejvyšší úrovně.
Změna detailů se provádí metodou EditRequisites(<Přidány podrobnosti>, <Odnímatelné detaily>) objekt ManagedForm. Možnosti Přidány podrobnosti A Odnímatelné detaily jsou předána pole s prvky typu Form Requisite.
Pozornost!
Proces změny kompozice detailů je poměrně náročný na zdroje. Ve skutečnosti se formulář znovu vytváří. V tomto ohledu se práce s detaily formuláře provádí v dávkovém režimu.
Vytvořme nový atribut formuláře s názvem Kupující:
AddedAttributes = Nové pole;
Přidány podrobnosti. Add(Nový atribut formuláře("Kupující", New TypeDescription ("DirectoryReference.Counterparties"), "Klient");// Změny ve složení atributů
);
Změna prvků formuláře
Zvládnout kompozici prvků objektu ManagedForm mít sbírku Elementy. Sběr má několik metod:
Vložit (< Имя>, < ТипЭлемента>, < Родитель>, < Элемент >)
Přidat (< Имя>, < ТипЭлемента>, < Родитель >)
Množství ()
Nalézt (< Имя >)
Hýbat se(< Элемент>, < Родитель>, < МестоРасположения >)
Vymazat (< Элемент >)
Kolekce Elements je dostupná na klientovi i na serveru. Upravit kolekci (metody vložení () , Přidat () , Přesunout () a Odstranit () ) jsou dostupné pouze na serveru. Můžete vyhledávat a získat počet prvků (metody Find () a Quantity () ) jak na klientovi, tak na serveru. Prvky kolekce mohou být:
- GroupForm;
- TableForms;
- FormField;
- ButtonForms.
K prvkům formuláře můžete programově přiřadit obslužné rutiny událostí. Pro tento účel metoda SetAction(< ИмяСобытия>, < Действие >) .
Podívejme se na některé z nejběžnějších praktických příkladů práce s příkazy, atributy a formulářovými prvky.
Přidání příkazu a jeho přiřazeného tlačítka:
// Vytvořte tým
tým = Příkazy. Přidat( "Historie změn");
tým . Akce = "Connected_DisplayHistory"; // Formulář musí obsahovat proceduru se zadaným názvem
tým . záhlaví = "Historie změn...";
// Vytvořte tlačítko a přidružte jej k příkazu
Živel = Předměty. Přidat( "Historie změn", Type("FormButton" ));
Element.CommandName = "Historie změn";
Přidání atributu a jeho přidruženého vstupního pole:
// Popis přidaných detailů
AddedAttributes = Nové pole;
Přidány podrobnosti. Přidat(Nový atribut formuláře ("Kupující", Popis nového typu ( "Referenční odkaz. Protistrany"), "Klient" ));
// Změna složení atributů
EditAttributes(AddedAttributes);
// Vytvoření vstupního pole a propojení s atributem
Živel = Předměty. Add("Customer" , Type("FormField" ));
Živel . Zobrazit = ViewFormFields. Vstupní pole;
Živel . PathToData= "kupující" ;
Přiřazení obslužné rutiny události k prvku formuláře:
Kupující položky. SetAction("Když se to změní", "Plug-in_BuyerOnChange");
&AtClient
Postup Plugin_BuyerOnChange(prvek)
// Akce událostí
EndProcedure
Pozornost!
Procedury, které se instalují jako obslužné rutiny událostí z kódu pomocí metody SetAction(), doporučuje se použít předponu Connected_.
Pozornost!
Můžete si stáhnout zpracování s příklady programového vyhledávání a změny detailů, příkazů a prvků spravovaného formuláře.
A strukturování objektu pro přenos dat do kódu, spravovaná forma v prostředí 1C 8.2.
Úvod
Začněme krátkým popisem konceptu „řízené formy“ a souvisejících konceptů platformy 1C. Odborníci na platformy mohou tuto sekci přeskočit.V roce 2008 byla k dispozici nová verze platformy 1C: Enterprise 8.2 (dále jen Managed Application), která kompletně mění celou vrstvu práce s rozhraním. To zahrnuje příkazové rozhraní, formuláře a systém oken. To nejen mění model vývoje uživatelského rozhraní v konfiguraci, ale také navrhuje novou architekturu pro oddělení funkčnosti mezi klientskou aplikací a serverem.
Spravovaná aplikace podporuje následující typy klientů:
- Tlustý klient (normální a řízený režim spouštění)
- Tenký klient
- Webový klient
Hlavní rozdíly spravovaných formulářů pro vývojáře:
- Deklarativní, nikoli "po pixelech" popis struktury. Konkrétní umístění prvků provede systém automaticky při zobrazení formuláře.
- Veškerá funkčnost formuláře je popsána ve formuláři podrobnosti A příkazy. Podrobnosti jsou data, se kterými formulář pracuje, a příkazy jsou prováděné akce.
- Formulář se spouští jak na serveru, tak na klientovi.
- V kontextu klienta nejsou dostupné téměř všechny typy aplikací, a proto není možné měnit data v infobázi.
- Pro každou proměnnou metody nebo formuláře musí být zadána kompilační směrnice A, které určuje, zda umístění provádění (klient nebo server) a přístup ke kontextu formuláře.
- &AtClient
- &Na serveru
- &OnServerWithoutContext
- &U klientaNa serveruBezKontextu
Všechny další diskuse se budou týkat pravé strany obrázku, jak strukturovat kód modulu a jaké principy vám umožní implementovat efektivní interakci klient-server.
Pojďme definovat problém
Od doby, kdy byla aktivně používána nová verze platformy 1C, uplynulo několik let a společnost 1C a její četní partneři vydali mnoho řešení (konfigurací).Vyvinuli vývojáři během této doby společné chápání principů interakce klient-server při vytváření formulářů a změnil se přístup k implementaci programových modulů v nové architektonické realitě?
Zvažte strukturu kódu (modul formuláře) v několika formách stejné typické konfigurace a pokuste se najít vzory.
Pod strukturou máme na mysli sekce kódu (nejčastěji se jedná o bloky komentářů) přidělené vývojářem pro seskupování metod a direktivy pro kompilaci těchto metod.
Příklad 1:
Sekce obsluhy událostí Metoda - na klientovi Metoda - na serveru Metoda - na klientovi Sekce servisních procedur a funkcí Pomocné funkce řízení vstupu
Příklad 2:
Servisní postupy a funkce Platební doklady Cennosti Obslužné jednotky událostí
Příklad 3:
Servisní procedury na serveru Servisní procedury na klientovi Servisní procedury na serveru bez kontextu Obslužné rutiny událostí záhlaví Příkazové obslužné rutiny událostí
Příklad 4:
Univerzální procedury Obsluha událostí formuláře Procedury subsystému "kontaktní informace".
Ve skutečnosti chybí struktura kódu, nebo mírně řečeno, je podobná tomu, co bylo ve formulářích 8.1:
- Neinformativní slova "General, Service, Auxiliary."
- Nesmělé pokusy oddělit metody klienta a serveru.
- Metody jsou často seskupeny podle prvků rozhraní "Práce s tabulkovou částí Produkty, Kontaktní informace".
- Libovolné uspořádání metod a kódových skupin. Obslužné rutiny událostí mohou být například v jednom formuláři nahoře, v jiném dole, ve třetím nejsou vůbec zvýrazněny a tak dále.
- A nezapomínejme, že to vše je v rámci stejné konfigurace.
- Ano, existují konfigurace, ve kterých jsou slova „General, Service, Auxiliary“ vždy na stejných místech, ale ...
Proč potřebujete strukturu kódu?
- Zjednodušení údržby.
- Zjednodušte učení.
- Upevnění obecných/důležitých/úspěšných zásad.
- …vaše možnost
Proč stávající vývojový standard od 1C nepomáhá?
Podívejme se na zásady publikované na discích ITS a v různých „Příručkách pro vývojáře...“, které se doporučují při psaní spravovaného formuláře.- Minimalizujte počet volání serveru.
- Maximální výpočetní výkon na serveru.
- Nekontextová volání serveru jsou rychlejší než kontextová volání.
- Program s ohledem na interakci klient-server.
- a tak dále.
Designové vzory nebo generační moudrost
Interakce klient-server se v různých softwarových technologiích používá již desítky let. Odpověď na otázky nastíněné v předchozí části je již dávno známá a je shrnuta do dvou základních principů.- Vzdálená fasáda(dále jen rozhraní vzdáleného přístupu)
- Objekt přenosu dat(dále jen objekt přenosu dat)
- … každý objekt potenciálně určený pro vzdálený přístup musí mít rozhraní s nízkou granularitou, což minimalizuje počet volání potřebných k provedení konkrétního postupu. … Namísto samostatného vyžádání faktury a všech jejích bodů je nutné přečíst a aktualizovat všechny body faktury v rámci jedné výzvy. To ovlivňuje celou strukturu objektu...Pamatujte si: rozhraní vzdáleného přístupu neobsahuje doménovou logiku.
- ... kdybych byla starostlivá matka, určitě bych svému dítěti řekla: "Nikdy nepište objekty přenosu dat!" Ve většině případů nejsou objekty migrace dat ničím jiným než nabubřelý fieldset… Hodnota tohoto nechutného monstra spočívá pouze v možnosti přenášet více položek informací po síti v jednom hovoru- technika, která má velký význam pro distribuované systémy.
Příklady šablon na platformě 1C
Rozhraní API, které má vývojář k dispozici při vývoji spravovaného formuláře, obsahuje mnoho příkladů těchto principů.Například metoda OpenForm(), typické „hrubé“ rozhraní.
OpenParameters = New Structure("Parametr1, Parametr2, Parametr3", Hodnota1, Hodnota2, Hodnota3); Form = OpenForm(FormName, OpenParameters);
Porovnejte se stylem v8.1.
Form = GetForm(FormName); Form.Parameter1 = Hodnota1; Form.Parameter2 = Hodnota2; Form.Open();
V kontextu spravovaného formuláře sada "Objektů přenosu dat". Lze rozlišit systémové A definovaný vývojářem.
Systémové modelují aplikační objekt na klientovi ve formě jednoho nebo více formulářových datových prvků. Nemůžete je vytvořit mimo vazbu na podrobnosti formuláře.
- DataFormsStructure
- DataFormsCollection
- DataFormStructureCollection
- DataFormsTree
- ValueVDataForm()
- FormDataToValue()
- CopyFormData()
- ValueVFormProps()
- FormAttributeToValue()
Příklad 1C v8.1:
// na klientovi v kontextu formuláře FillUsersCache(DepartmentReference)
Příklad 1C v8.2:
// na serveru v kontextu formuláře ProcessingObject = FormAttributeToValue("Object"); ProcessingObject.FillCacheUsers(DepartmentReference); ValueVFormAttribute(ProcessingObject, "Object");
Objekty migrace dat, jejichž struktura je definována vývojářem, jsou malou podmnožinou typů dostupných na klientovi i na serveru. Nejčastěji se jako parametry a výsledky metod "hrubého" rozhraní používají následující:
- Primitivní typy (řetězec, číslo, boolean)
- Struktura
- Korespondence
- pole
- Odkazy na objekty aplikace (jedinečný identifikátor a textová reprezentace)
Funkce &OnServerWithoutContext ServerChangeOrderStatus(Orders, NewStatus) Errors = New Match(); // [objednávka][popis chyby] Pro každou objednávku z objednávek smyčka StartTransaction(); Pokus DocOb = Order.GetObject(); …. další akce, případně nejen s objednávkou... Výjimka CancelTransaction(); Errors.Insert(Order, DescriptionError()); Konec pokusu; EndCycle; Return Error; EndFunction // ServerChangeOrderStatus()
Strukturování kódu
Hlavní cíle, které by měl modul spravovaného formuláře odrážet, a přístupy k řešení.- Jasné oddělení kódu klienta a serveru. Nezapomínejme, že v okamžiku provedení se jedná o dva vzájemně se ovlivňující procesy, z nichž se u každého výrazně liší dostupná funkčnost.
- Jasný výběr rozhraní vzdáleného přístupu, které serverové metody lze volat z klienta a které ne? Názvy metod vzdáleného rozhraní začínají předponou "Server". To vám umožní okamžitě vidět přechod řízení na server při čtení kódu a zjednoduší použití kontextových nápověd. Všimněte si, že oficiální doporučení (ITS) navrhuje metody pojmenování s postfixy, jako je ChangeOrderStatusOnServer(). Abychom však zopakovali, ne všechny serverové metody lze volat z klienta, a proto je logická dostupnost důležitější než umístění kompilace. Předponou „Server“ tedy označíme pouze metody dostupné klientovi, ukázková metoda se bude jmenovat ServerChangeOrderStatus().
- Čitelnost. Věc vkusu, objednávku přijímáme, když modul začíná s procedurami pro vytvoření formuláře na serveru a metodami vzdáleného přístupu.
- Udržitelnost. Místo pro přidání nového kódu musí být jasně definováno. Důležitým bodem je, že na konec modulu jsou přidány pahýly metod automaticky vytvořené konfigurátorem. Vzhledem k tomu, že obslužné rutiny událostí prvků formuláře jsou nejčastěji vytvářeny automaticky, odpovídající blok je umístěn jako poslední, aby nedošlo k přetažení každého ovladače na jiné místo v modulu.
- Grafická možnost - jasně ukazuje hlavní tok provádění.
- Možnost text je příkladem návrhu šablony pro rychlé vložení struktury do nového modulu formuláře.
//////////////////////////////////////////////////////////////////////////////// // <(c) Автор=""Datum=""/> // <Описание> // // ////////////////////////////////////////////////// /////////////////////////////// PROMĚNNÉ MODULU ///////////////// ////////////////////////////////////////////////// ////////////// // NA SERVERU //******* UDÁLOSTI NA SERVERU ******* &Na serveru Postup Při vytvořeníNa serveru(selhání, StandardProcessing) //Vložit obsah handleru EndProcedure //******* ROZHRANÍ PRO VZDÁLENÝ PŘÍSTUP ******* //******* OBCHODNÍ LOGIKA NA SERVERU ****** * ///////// //////////////////////////////////////// ////////// ////////////////////// METODY GENERÁLNÍHO KLIENTA A SERVERU //////////// ////////////////////////////////////////////////// //////////// ///////// NA KLIENTA //******* OBCHODNÍ LOGIKA NA KLIENTOVI ******* //** ***** PŘÍKAZY ******** //******* UDÁLOSTI NA KLIENTOVI ****** /////////////////// ////////////////////////////////////////////////// //////////// / HLAVNÍ OPERÁTORY PROGRAMU
Související otázky
Na závěr nastíníme několik oblastí, na které je užitečné myslet při programování interakce klient-server.- Možnosti implementace rozhraní vzdáleného přístupu. Asynchronnost, granularita...
- ukládání do mezipaměti. 1C udělalo nešťastné architektonické rozhodnutí, zavedlo cachování pouze na úrovni volání metod běžných modulů a neposkytlo možnosti ovládání (aktuální čas, reset na vyžádání).
- Implicitní volání serveru. Nezapomeňte na technologické vlastnosti, mnoho „neškodných“ operací na klientovi vyprovokuje platformu k přístupu na server.
formuláře v 1C:Enterprise jsou navrženy tak, aby zobrazovaly a upravovaly informace obsažené v databázi. Formuláře mohou patřit ke konkrétním konfiguračním objektům nebo mohou existovat odděleně od nich a být používány celým aplikačním řešením jako celkem.
Například průvodce Nomenklatura může mít několik forem, které budou použity pro specifické účely - úprava prvku adresáře, zobrazení seznamu atd.:
Spolu s tím mohou existovat obecné formuláře, které nepatří ke konkrétním konfiguračním objektům - obecné formuláře.
Základní formy
Každý konfigurační objekt lze použít k provedení určitých standardních akcí. Například pro libovolný adresář můžete potřebovat zobrazit seznam jeho prvků, zobrazit jednotlivé prvky adresáře, zobrazit skupinu adresáře, vybrat prvky a skupiny prvků z adresáře. Pro jakýkoli dokument bude seznam takových akcí mnohem menší: zobrazení seznamu dokumentů, výběr ze seznamu dokumentů a zobrazení jednoho dokumentu.
Aby bylo zajištěno provádění takových standardních akcí s daty objektů aplikovaného řešení, pro každý z nich existuje sada základních formulářů, které budou použity při provádění odpovídajících akcí. Hlavní lze přiřadit kterémukoli z formulářů podřízených tomuto objektu. Například adresář Nomenklatura mohou existovat následující hlavní formy:
A dokument Příjem zboží a služeb složení hlavních forem se bude lišit:
Pokud tedy uživatel chce vidět seznam adresářů Nomenklatura nebo seznam dokumentů Příjem zboží a služeb, systém otevře odpovídající formulář přiřazený jako formulář seznamu pro tyto objekty.
Automaticky generované formuláře
Důležitou vlastností systému 1C:Enterprise 8 je mechanismus automaticky generovaných formulářů. Tento mechanismus osvobozuje vývojáře od nutnosti vytvářet všechny možné formuláře pro každý z konfiguračních objektů. Stačí, aby vývojář přidal nový konfigurační objekt a systém sám ve správných okamžicích práce uživatele vygeneruje potřebné formuláře pro zobrazení informací obsažených v tomto objektu.
Vývojář tedy potřebuje vytvářet vlastní formy objektů aplikačního řešení pouze v případě, že se musí lišit (jiný design nebo specifické chování) od formulářů automaticky generovaných systémem.
Propojení formuláře s daty
Skutečnost, že formulář patří k jednomu nebo druhému konfiguračnímu objektu, neurčuje složení dat, která jsou ve formuláři zobrazena. Že formulář patří například do adresáře Nomenklatura, umožňuje přiřadit jej k jednomu z hlavních formulářů pro tento adresář, ale nijak neurčuje, jaký druh dat bude tento formulář zobrazovat a jaké bude jeho chování.
Pro propojení formuláře s daty se používají atributy formuláře, které označují seznam údajů zobrazených formulářem. Všechny formuláře samy o sobě mají stejné chování bez ohledu na to, jaká data zobrazují. Jeden z atributů formuláře však lze nastavit jako primární atribut formuláře (je zvýrazněn tučně), v takovém případě bude standardní chování formuláře a jeho vlastnosti doplněno v závislosti na typu primárního atributu formuláře:
Pokud je například dokument přiřazen jako hlavní atribut formuláře Příjem zboží a služeb, poté po uzavření formuláře systém požádá o potvrzení zaevidování a zaúčtování tohoto dokladu. Pokud je jako hlavní atribut formuláře přiřazena například referenční kniha Nomenklatura, pak při zavírání formuláře nebude takový požadavek na potvrzení.
Struktura formuláře
Hlavním rysem formulářů je, že nejsou vývojářem kresleny podrobně, „po pixelech“. Formulář v konfiguraci je logický popis složení formuláře. A konkrétní umístění prvků provádí systém automaticky při zobrazení formuláře.
Část formuláře, která je zobrazena (viditelná pro uživatele), je popsána jako strom obsahující prvky formuláře.
Prvky mohou být vstupní pole, zaškrtávací políčka, přepínače, tlačítka atd. Kromě toho může být prvkem skupina dalších prvků. Skupina může být reprezentována jako panel s rámečkem, panel se stránkami (záložkami), samotná stránka, příkazový panel. Kromě toho může být prvkem tabulka, která také obsahuje prvky (sloupce). Struktura prvku popisuje, jak bude formulář vypadat.
Veškerá funkčnost formuláře je popsána formou detailů a příkazů. Podrobnosti jsou data, se kterými formulář pracuje, a příkazy jsou prováděné akce. Vývojář v editoru formulářů tedy musí do formuláře zahrnout potřebné detaily a příkazy, vytvořit prvky formuláře, které je zobrazí, a v případě potřeby prvky uspořádat do skupin.
Na základě tohoto logického popisu systém automaticky vygeneruje vzhled formuláře pro zobrazení uživateli. Systém zároveň zohledňuje různé vlastnosti zobrazovaných dat (například typ), aby prvky formuláře uspořádal pro uživatele co nejpohodlněji.
Vývojář může ovlivňovat uspořádání prvků různým nastavením. Dokáže určit pořadí prvků, uvést požadovanou šířku a výšku. Toto jsou však jen některé doplňující informace, které pomohou systému zobrazit formulář.
Ve formulářích může vývojář používat nejen příkazy samotného formuláře, ale také globální příkazy používané v příkazovém rozhraní celé konfigurace. Navíc byla implementována možnost vytvářet parametrizovatelné příkazy, které otevřou další formuláře s přihlédnutím ke konkrétním údajům aktuálního formuláře. Může se například jednat o vyvolání přehledu o zůstatcích na skladě, který je aktuálně vybrán ve formuláři faktury.
Všichni víme, že společnost 1C měla mnoho různých verzí platformy 1C, nás nyní bude zajímat jedna z nejnovějších verzí v době psaní tohoto článku, jedná se o verze 1C 8.2 a 1C 8.3. Pokud jste museli pracovat v obou těchto verzích, pak jste s největší pravděpodobností zaznamenali rozdíly v rozhraních těchto verzí, pro uživatele se liší pouze navenek. V podstatě výběr běžná nebo spravovaná aplikaceříká systému, které formuláře se mají zobrazit, aby se spustil, pravidelné nebo kontrolované a také který aplikační klient bude standardně používán, tlustý nebo tenký. Další informace o klientech naleznete v článku "Co je tlustý a tenký klient v 1C a také jejich rozdíly."
Běžná aplikace 1C (běžné formuláře, normální rozhraní, verze 1C 8.2)
V 1C 8.2 je možná pouze práce s normálními formami, v normálním aplikačním režimu. Obrázek níže ukazuje základnu v provozním režimu "běžná aplikace 1C" (běžné formy).
Spravovaná aplikace 1C (spravované formuláře, spravované rozhraní, verze 1C 8.3)
Na platformě 1C 8.3 můžeme pracovat jak s běžnými formami (v režimu kompatibility), tak s těmi spravovanými. A spravované formuláře mají dva typy zobrazení, jedná se o standardní a taxi. Níže je uveden příklad konfigurace 1C 8.3 se standardními spravovanými formuláři a za ním je zobrazeno rozhraní Taxi.
Jaký je rozdíl mezi běžnou a spravovanou aplikací 1C?
Jak jsme již zjistili běžná aplikace a spravovaná aplikace jsou takové typy spouštění programu 1C. Navíc v závislosti na hodnotě typu startu 1C ( běžná nebo řízená aplikace), ve výchozím nastavení se načte konkrétní rozhraní ( běžné nebo řízené formuláře), proto existuje tolik synonym pro tento pojem. Rádi bychom poznamenali, že rozdíly v rozhraních jsou poměrně značné, spravované rozhraní bylo zcela přepracováno. V zásadě jde o všechny rozdíly, které vidí běžní uživatelé programu 1C. Pokud jde o programátory, spravované rozhraní vyžaduje psaní upraveného kódu, protože vývoj již probíhá v 1C 8.3, a ne v 1C 8.2, z toho plynou všechny důsledky. Kód je také nutné rozdělit na klient a server, což je indikováno pomocí příslušných direktiv v konfigurátoru.
Klyuev V.V.
http://prof1c.kklab.ru
PRÁCE SE SPÍNAČI
Žádám Vás o zohlednění všech uživatelů služby webu - materiály umisťuji do sekce Začátečníci !!!
8.2 Spravované formuláře
Při studiu chování spravovaných formulářů čelí programátoři nebo vývojáři rozhraní otázce - kde jsou přepínače ve spravovaných formulářích a jak je do formuláře přidat. Maličkost, ale nepříjemně mnoho času se stráví na takových maličkostech, i když tento čas by se dal věnovat spíše vývoji a optimalizaci algoritmu než návrhu formuláře.
Vytvořme tedy prázdnou konfiguraci, abychom problému porozuměli, nebo zvolíme jakoukoli typickou konfiguraci.
Přejděte do skupiny obsahující adresáře a pro experiment přidejte nový adresář. Chci poznamenat, že konfigurace musí mít hlavní režim spuštění - Spravovaná aplikace.
Pojďme tedy vytvořit nový adresář a přidat rekvizity "Props1", s typem "Boolean"
Nyní přejděte na kartu Formuláře a přidejte nový formulář.
Spravovaný formulář je tedy vytvořen, nyní pracujme s formulářem a zjistěme, kde se nachází přepínač.
Zde je náš formulář a na něm vidíme naše rekvizity, ale ve formě zaškrtávacího políčka
Co jsme tedy udělali špatně?
Podívejme se do vlastností rekvizit, zda tam není přepnutí do pohledu na ovládací prvek.
A vidíme, že Switch Field tady není! (Kde jsme udělali chybu?
Vzhled ovládacího prvku na formuláři zřejmě závisí na datovém typu, vraťme se k vlastnostem formuláře, konkrétně na záložku detaily a změňme vlastnosti našeho atributu – konkrétně jeho typ „Boolean“, na typ „Číslo“.
Nyní se vraťme k vlastnostem ovládacího prvku a zkontrolujeme, zda v jeho vlastnostech byl přidán Pohled ovládacího prvku - - - A urra, vidíme tam pohled - pole Přepnout.
Nyní se podívejte na formulář, co vidíme:
Vidíme - 3 výchozí hodnoty, 3 přepínače, ale potřebujeme dva z nich, přejděte znovu na vlastnosti rekvizit a podívejte se na vlastnosti "Počet sloupců" tam
Pro 2 - nastavte Počet sloupců - 2.
To by unaveného programátora mohlo trochu zastavit)), ale teď to ví on i my!
8.2 Společné formuláře.
Nervozita se spínači v obvyklých formách.
Jsou takové momenty, a ty se stávají), když potřebujete upravit nějaký hotový formulář, ve kterém už nějaké přepínače jsou, a potřebujete do tohoto formuláře přidat další přepínač. Zde vzniká určitá zdlouhavost, která zabere spoustu času a ne čas na programování kódu - ale ztráta času, aby se tyto přepínače zobrazily uživateli.
Podívejme se tedy na příklad. Existuje takový dokument pro úpravu účtenek v 1C SCP - určitě existuje. Jednou jsme k tomu potřebovali přidat přepínače, aby se vykreslily trochu jiné účtování pro účetnictví. V čem je problém, zdá se to nutné, pak je to nutné, uděláme to. Ale tento formulář již má 2 přepínače.
Takto vypadá formulář, do kterého potřebujeme připevnit další vypínače
Na kartě Upřesnit bychom rádi umístili další dva přepínače. První akcí je tedy odvážné přidání nového ovládacího prvku na místo, kam jej potřebujeme vložit.
Zdálo by se, že vše je jednoduché. Vytvoříme nový atribut s typem - "Číslo" a vložíme 2 přepínače, z nichž jeden bude moci zapisovat data do atributu a druhý ne.
Přidejte nový ovladač - Switch, v tabulce s počtem a popisem přepínačů přidejte Switch2, nastavte Switch1 jako první ve skupině a stiskněte ok. Vytvořené ovládací prvky umístíme na formulář. Aktualizujte konfiguraci databáze (F7) a spusťte ladění.
Při spuštění (při vytváření nového dokumentu v režimu 1C:Enterprise) vidíme, že ať se snažíme na Switch2 klikat sebevíc, nic se neděje. Prvky nefungují tak, jak by měly. Je zde jedna funkce.
Vraťte se do konfigurátoru. Vyberte položku v menu Formulář -> Nastavení pořadí průchodu ... (důležité je, aby byl formulář otevřený na obrazovce)
Aby naše Switche fungovaly, musíte přerušit automatický příkaz a souhlasit s tím ručním. A vložte formulář tak, aby naše spínače šly - jeden po druhém v pořadí.
OK. Aktualizujte konfiguraci a zkuste spustit.
Skvělý. Všechno fungovalo.
Volitelné - video (bez zvuku, takže je vše jasné)
