Asynchronní volání pro rozšíření a externí komponenty. Proč dochází k chybě „Použití synchronních metod na klientovi je zakázáno“?

Implementováno ve verzi 8.3.5.1383, 8.3.6.1977.

Moderní tendence

Trendy vývoje prohlížečů vedou ke stále většímu procentu „asynchronie“ v platformě. První krok byl. Nyní existují asynchronní volání pro práci s kryptografickými rozšířeními, práci se soubory a externími komponentami.

Důvodem dalšího posunu k asynchronnosti bylo, že vývojáři prohlížeče Google Chrome opustili podporu předchozí technologie NPAPI (Netscape Plugin Application Programming Interface). Tato technologie byla použita pro připojení externích modulů - rozšíření - k prohlížeči.

Taková rozšíření jsou přesně to, co 1C:Enterprise používá pro práci s kryptografií, pro práci se soubory a pro připojení externích komponent. To je docela důležitá funkce. Kryptografie se používá při správě elektronických dokumentů a díky externím komponentám mohou aplikace spolupracovat se skenery čárových kódů a dalším vybavením maloobchodu.

A nyní, namísto předchozí synchronní technologie NPAPI, vytvořili vývojáři Google Chrome novou technologii Native Messaging. Zároveň důrazně doporučili všem vývojářům rozšíření nepoužívat starou technologii, protože nebude podporována.

Aniž bychom zacházeli do detailů, nová technologie je lepší a bezpečnější. To je dobré. Ale jedním z jeho významných rozdílů je, že poskytuje výhradně asynchronní interakci s rozšířeními prohlížeče. A to vyžaduje radikální změnu ve všech existujících metodách práce s rozšířeními a externími komponenty v 1C:Enterprise. Protože všechny jsou založeny na synchronní interakci.

Asynchronní metody

Tento problém jsme vyřešili stejným způsobem, jakým jsme vyřešili problém s modálním voláním. Pro všechny synchronní metody využívající technologii NPAPI jsme vytvořili jejich asynchronní protějšky. Liší se především přítomností předpony Začít a skutečnost, že je jim předán první parametr PopisUpozornění, od kterého bude po dokončení volané akce pokračovat provádění programového kódu.

Například místo metody Šifrovat() Nyní doporučujeme použít metodu StartEncrypt():

CryptographyManager.Encrypt(<ИсходныеДанные>, <Получатели>) Cryptography Manager.Start Encryption(<ОписаниеОповещения>, <ИсходныеДанные>, <Получатели>)

Místo metody GetFiles() - StartGettingFiles():

GetFiles(<ПолучаемыеФайлы>, <ПолученныеФайлы>, <РасположениеФайлов>, <Интерактивно>) Začněte přijímat soubory ((<ОписаниеОповещения>, <ПолучаемыеФайлы>, <РасположениеФайлов>, <Интерактивно>)

Namísto SetExternalComponent()- StartInstallingExternalComponents():

SetExternalComponent(<Местоположение>) Začněte instalovat externí součásti (<ОписаниеОповещенияОЗавершении>, <Местоположение>)

Ve skutečnosti je vše velmi podobné tomu, co jsme dělali předtím, když jsme se zbavili modality. Ale fungování nových asynchronních metod má zásadní vlastnost, kterou metody způsobující nemodální dialogy nemají.

Při asynchronním volání nemodálního dialogu očekáváme pouze nějakou reakci uživatele a nic víc. V tom smyslu, že se nemůže stát nic neočekávaného.

A v procesu volání asynchronních metod práce s rozšířeními a komponentami mohou nastat výjimečné situace. Rozšíření se nenainstalovalo, komponenta se nenačetla atd.

Zpracování takových výjimek obvykle poskytujete v kódu aplikace. Pomocí operátora Zkouším... Výjimka. Nyní se to však stává nemožným, protože v době asynchronního volání se kód aplikace nespustí. Operátor tedy nefunguje Zkouším... Výjimka.

  • NameProcedureProcessingErrors;
  • ErrorProcessingModule.

Pokud se během asynchronního volání něco pokazí a dojde k výjimce, bude provedena procedura, na kterou tyto vlastnosti ukazují. Tyto dvě vlastnosti má smysl používat pouze u asynchronních metod práce s rozšířeními. Při volání nemodálních dialogů tyto vlastnosti nepotřebujete.

Vlastnost konfigurace

Stejně jako v případě odmítnutí modality musí celé aplikační řešení jako celek vědět, „co to je“. Buď je modální nebo nemodální. Buď je synchronní nebo asynchronní.

Dříve jsme k vyřešení problému s modalitou přidali speciální konfigurační vlastnost Způsob použití modality. Nyní, abychom vyřešili problém se synchronicitou, jsme přidali vlastnost, která má podobný význam Režim použití synchronních volání poboček a externích komponent.

Podstata jeho použití je následující:

  • Nepoužívat- jedná se o nový, asynchronní režim provozu. U nových konfigurací se jedná o standardní režim. Používání starých, synchronních metod je zakázáno. Neprocházejí syntaktickou kontrolou, nejsou v kontextu vodítkem. Pokus o provedení synchronní metody vyvolá výjimku.
  • Používejte s varováním- tento režim je určen pro vývojáře. Nebrání použití starších, synchronních metod. Ale pokaždé, když je na klientovi zavolána synchronní metoda, vytvoří varovnou zprávu. Tento režim doporučujeme používat v konfiguracích „recyklace“. Je vhodný pro vizuální vyhledávání synchronních hovorů a jejich sledování během procesu revize.
  • Použití- režim, který zajišťuje kompatibilitu nové verze platformy se starými konfiguracemi, které používají synchronní metody pro práci s rozšířeními a externími komponentami.

Všechny metody a vlastnosti, o kterých jsme dosud hovořili, jsou implementovány ve verzi 8.3.5.1383 . Můžete je použít ve svých aplikačních řešeních. A vývojáři například přejdou na asynchronní operační subsystémy, které využívají kryptografické nástroje, pracují se soubory a externími komponentami.

Přirozeně, stejně jako u modálních volání, pravděpodobně máte otázku. Musím své aplikační řešení předělat? A obecně, musím tyto asynchronní metody používat ve svém novém aplikačním řešení?

Kdy je to potřeba?

Odpověď na tuto otázku je v podstatě stejná, jako jsme uvedli dříve. Když mluvili o opuštění modality.

Za prvé, ne každá verze technologické platformy podporuje režim asynchronního volání na rozšíření a externí komponenty. Tento provozní režim existuje od verze 8.3.5.1383. Pokud tedy pracujete na nižších verzích platformy, nemusíte se zatím bát opustit synchronní metody.

Za druhé, ne všechna aplikační řešení musí nutně používat tento režim. Kritické aplikace jsou ty, se kterými se bude pracovat pomocí webového klienta v prohlížeči Google Chrome. Takové aplikace jsou z velké části aplikace běžící . Pokud vaše aplikační řešení rozhodně nebude v tomto režimu použito, nemůžete prozatím opustit synchronní metody.

Navzdory prvnímu a druhému bodu však existují globální trendy, které mohou ovlivnit vaše plány. My, společnost 1C, vyvíjíme všechna standardní řešení na základě toho, že je lze použít jakýmkoliv z dostupných způsobů. Proto budeme implementovat nová aplikační řešení, stejně jako všechny v nich použité knihovny, v režimu bez použití synchronních volání.

To znamená, že je pro vás lepší začít ovládat tento režim provozu nyní. I když to vaše aplikace možná ještě nepoužívá, doporučujeme, pokud je to možné, začít s překladem hned. Doporučujeme vám však přistupovat k tomuto procesu kreativně. Ve stejném duchu jako při opuštění modality. To znamená, že není potřeba mechanicky nahrazovat synchronní metody asynchronními. Nejprve je užitečné zamyslet se nad tím, zda je možné změnit algoritmus nebo skript tak, abychom v tomto místě zcela opustili používání synchronních metod?

Refaktorování

Na jednu stranu, pokud je konfigurace velká a je v ní hodně synchronních volání, pak může být „ruční“ přepracování takové konfigurace časově velmi náročným úkolem.

Na druhou stranu od verze 8.3.5.1068 má platforma funkce, které vám umožňují převádět synchronní volání na jejich asynchronní protějšky.

Proto jsme vzali tyto již existující nástroje, rozšířili je a přeorientovali je z „odklonu od modality“ k „přechodu k asynchronii“. V jádru je přechod na asynchronní metody podobný akcím, které se provádějí při opuštění modality. Staré, „nemoderní“, synchronní (modální) hovory je třeba nahradit novými, „módními“, asynchronními hovory pomocí Zpracování upozornění.

V této aktualizované podobě jsou vám ve verzi k dispozici nástroje pro refaktorování 8.3.6.1977 .

Protože se "důraz" těchto nástrojů posunul směrem k asynchronii, přejmenovali jsme některé příkazy. Místo výrazu „nemodální“ se nyní používá výraz „zastaralý synchronní“:

Navíc jsme přidali novou záložku do nastavení konfigurátoru Refaktorování. Ve výchozím nastavení jsou povoleny obě transformace. Pokud ji však potřebujete, můžete s její pomocí provádět pouze jeden z typů transformací při automatickém refaktorování.

05.12.2014

Implementováno ve verzi 8.3.5.1383, 8.3.6.1977.

Moderní tendence

Trendy vývoje prohlížečů vedou ke stále většímu procentu „asynchronie“ v platformě. Prvním krokem bylo opustit modalitu. Nyní existují asynchronní volání pro práci s kryptografickými rozšířeními, práci se soubory a externími komponentami.

Důvodem dalšího posunu k asynchronnosti bylo, že vývojáři prohlížeče Google Chrome opustili podporu předchozí technologie NPAPI (Netscape Plugin Application Programming Interface). Tato technologie byla použita pro připojení externích modulů - rozšíření - k prohlížeči.

Taková rozšíření jsou přesně to, co 1C:Enterprise používá pro práci s kryptografií, pro práci se soubory a pro připojení externích komponent. To je docela důležitá funkce. Kryptografie se používá při správě elektronických dokumentů a díky externím komponentám mohou aplikace spolupracovat se skenery čárových kódů a dalším vybavením maloobchodu.

A nyní, namísto předchozí synchronní technologie NPAPI, vytvořili vývojáři Google Chrome novou technologii Native Messaging. Zároveň důrazně doporučili všem vývojářům rozšíření nepoužívat starou technologii, protože nebude podporována.

Aniž bychom zacházeli do detailů, nová technologie je lepší a bezpečnější. To je dobré. Ale jedním z jeho významných rozdílů je, že poskytuje výhradně asynchronní interakci s rozšířeními prohlížeče. A to vyžaduje radikální změnu ve všech existujících metodách práce s rozšířeními a externími komponenty v 1C:Enterprise. Protože všechny jsou založeny na synchronní interakci.

Asynchronní metody

Tento problém jsme vyřešili stejným způsobem jako problém s modálním voláním. Pro všechny synchronní metody využívající technologii NPAPI jsme vytvořili jejich asynchronní protějšky. Liší se především přítomností předpony Start a tím, že prvním parametrem je Popis výstrahy, od kterého bude po dokončení volané akce pokračovat provádění programového kódu.

Například místo metody Encrypt() nyní doporučujeme použít metodu StartEncrypt():

CryptographyManager.Encrypt(<ИсходныеДанные>, <Получатели>) Cryptography Manager.Start Encryption(<ОписаниеОповещения>, <ИсходныеДанные>, <Получатели>)

Místo metody GetFiles() - StartGettingFiles():

GetFiles(<ПолучаемыеФайлы>, <ПолученныеФайлы>, <РасположениеФайлов>, <Интерактивно>) Začněte přijímat soubory ((<ОписаниеОповещения>, <ПолучаемыеФайлы>, <РасположениеФайлов>, <Интерактивно>)

Místo InstallExternalComponent() - StartInstallingExternalComponent():

SetExternalComponent(<Местоположение>) Začněte instalovat externí součásti (<ОписаниеОповещенияОЗавершении>, <Местоположение>)

Ve skutečnosti je vše velmi podobné tomu, co jsme dělali předtím, když jsme se zbavili modality. Ale fungování nových asynchronních metod má zásadní vlastnost, kterou metody způsobující nemodální dialogy nemají.

Při asynchronním volání nemodálního dialogu očekáváme pouze nějakou reakci uživatele a nic víc. V tom smyslu, že se nemůže stát nic neočekávaného.

A v procesu volání asynchronních metod práce s rozšířeními a komponentami mohou nastat výjimečné situace. Rozšíření se nenainstalovalo, komponenta se nenačetla atd.

Ošetření takových výjimek obvykle poskytujete v kódu aplikace. Pomocí operátoru Try... Exception. Nyní se to však stává nemožným, protože v době asynchronního volání se kód aplikace nespustí. Operátor pokusu... výjimka tedy nefunguje.

  • ErrorProcedureName;
  • Modul zpracování chyb.

Pokud se během asynchronního volání něco pokazí a dojde k výjimce, bude provedena procedura, na kterou tyto vlastnosti ukazují. Tyto dvě vlastnosti má smysl používat pouze u asynchronních metod práce s rozšířeními. Při volání nemodálních dialogů tyto vlastnosti nepotřebujete.

Vlastnost konfigurace

Stejně jako v případě odmítnutí modality musí celé aplikační řešení jako celek vědět, „co to je“. Buď je modální nebo nemodální. Buď je synchronní nebo asynchronní.

Dříve, abychom vyřešili problém s modalitou, jsme do konfigurace přidali speciální vlastnost: Mode of using modality. Nyní, abychom problém se synchronií vyřešili, přidali jsme vlastnost, která má podobný význam: Režim pro použití synchronních volání poboček a externích komponent.

Podstata jeho použití je následující:

  • Nepoužívat je nový asynchronní režim provozu. U nových konfigurací se jedná o standardní režim. Používání starých, synchronních metod je zakázáno. Neprocházejí syntaktickou kontrolou, nejsou v kontextu vodítkem. Pokus o provedení synchronní metody vyvolá výjimku.
  • Používejte s varováním - tento režim je určen pro vývojáře. Nebrání použití starších, synchronních metod. Ale pokaždé, když je na klientovi zavolána synchronní metoda, vytvoří varovnou zprávu. Tento režim doporučujeme používat v „recyklačních“ konfiguracích. Je vhodný pro vizuální vyhledávání synchronních hovorů a jejich sledování během procesu revize.
  • Use - režim, který zajišťuje kompatibilitu nové verze platformy se starými konfiguracemi, které používají synchronní metody pro práci s rozšířeními a externími komponentami.

Všechny metody a vlastnosti, o kterých jsme dosud mluvili, jsou implementovány ve verzi 8.3.5.1383. Můžete je použít ve svých aplikačních řešeních. A například vývojáři BSP přenesou do asynchronního provozu subsystémy, které využívají kryptografické nástroje, pracují se soubory a externími komponentami.

Přirozeně, stejně jako u modálních volání, pravděpodobně máte otázku. Musím své aplikační řešení předělat? A obecně, musím tyto asynchronní metody používat ve svém novém aplikačním řešení?

Kdy je to potřeba?

Odpověď na tuto otázku je v podstatě stejná, jako jsme uvedli dříve. Když mluvili o opuštění modality.

Za prvé, ne každá verze technologické platformy podporuje režim asynchronního volání na rozšíření a externí komponenty. Tento provozní režim existuje od verze 8.3.5.1383. Pokud tedy pracujete na nižších verzích platformy, nemusíte se zatím bát opustit synchronní metody.

Za druhé, ne všechna aplikační řešení musí nutně používat tento režim. Kritické aplikace jsou ty, se kterými se bude pracovat pomocí webového klienta v prohlížeči Google Chrome. Takové aplikace jsou z velké části aplikace fungující v modelu služeb. Pokud vaše aplikační řešení rozhodně nebude v tomto režimu použito, nemůžete prozatím opustit synchronní metody.

Navzdory prvnímu a druhému bodu však existují globální trendy, které mohou ovlivnit vaše plány. My, společnost 1C, vyvíjíme všechna standardní řešení na základě toho, že je lze použít jakýmkoliv z dostupných způsobů. Proto budeme implementovat nová aplikační řešení, stejně jako všechny v nich použité knihovny, v režimu bez použití synchronních volání.

To znamená, že je pro vás lepší začít ovládat tento režim provozu nyní. I když to vaše aplikace možná ještě nepoužívá, doporučujeme, pokud je to možné, začít s překladem hned. Doporučujeme vám však přistupovat k tomuto procesu kreativně. Ve stejném duchu jako při opuštění modality. To znamená, že není potřeba mechanicky nahrazovat synchronní metody asynchronními. Nejprve je užitečné zamyslet se nad tím, zda je možné změnit algoritmus nebo skript tak, abychom v tomto místě zcela opustili používání synchronních metod?

Refaktorování

Na jednu stranu, pokud je konfigurace velká a je v ní hodně synchronních volání, pak může být „ruční“ přepracování takové konfigurace časově velmi náročným úkolem.

Na druhou stranu, počínaje verzí 8.3.5.1068 má platforma nástroje, které umožňují převádět synchronní volání na jejich asynchronní protějšky.

Proto jsme vzali tyto již existující nástroje, rozšířili je a přeorientovali je z „odklonu od modality“ k „přechodu k asynchronii“. V jádru je přechod na asynchronní metody podobný akcím, které se provádějí při opuštění modality. Staré, „nemoderní“, synchronní (modální) hovory je třeba nahradit novými, „módními“ asynchronními hovory, které používají zpracování oznámení.

V této aktualizované podobě vám byly nástroje pro refaktorování k dispozici ve verzi 8.3.6.1977.

Protože se "důraz" těchto nástrojů posunul směrem k asynchronii, přejmenovali jsme některé příkazy. Místo výrazu „nemodální“ se nyní používá výraz „zastaralý synchronní“:

Navíc jsme do nastavení konfigurátoru přidali novou záložku Refaktoring. Ve výchozím nastavení jsou povoleny obě transformace. Pokud ji však potřebujete, můžete s její pomocí provádět pouze jeden z typů transformací během automatického refaktorování:

Článek se bude zabývat hlavními důvody pro opuštění modality v platformě 1C:Enterprise a hlavními metodami převodu částí kódu na nový asynchronní model.

Použitelnost

Článek pojednává o asynchronním modelu pro konstrukci obchodní logiky, přidané platformě „1C:Enterprise“ vydání 8.3. Uvedené informace jsou relevantní pro aktuální verze platforem.

Odmítnutí použití modálních oken v platformě 1C:Enterprise 8.3

Při vývoji konfigurace na platformě 1C:Enterprise 8 vzniká potřeba periodicky pozastavovat program, dokud se uživatel nerozhodne nebo neprovede nějakou akci.

Například při kliknutí na tlačítko vyplnit tabulkovou sekci by měl být uživatel dotázán, zda je třeba tabulkovou sekci vymazat, aby nedošlo ke ztrátě dříve zadaných dat.

Tohoto chování lze dosáhnout například následujícím kódem:

&OnClient
Postup Vyplňte Produkty(Tým )
Odpověď = Otázka („Část tabulky bude vymazána. Pokračovat?“, Režim dialoguOtázka.AnoNe);
Pokud odpověď = Návratový kód dialogu.Ano Pak
//algoritmus plnění
EndIf;
EndProcedure

V důsledku tohoto fragmentu kódu bude pozastaveno provádění programového kódu, na obrazovce se zobrazí dotaz, rozhraní aplikace kromě dialogu s dotazem bude nedostupné, systém čeká, až uživatel provede rozhodnutí a provádění kódu bude pokračovat až po zodpovězení otázky.

Otevírání modálních oken voláním metody OpenModal() také způsobuje pauzy ve provádění kódu a blokování rozhraní.

Při práci s konfigurací v režimu webového klienta přes prohlížeč se v tomto případě otevře nové okno - vyskakovací okno, které zablokuje nejen aktuální záložku, ale i celé rozhraní prohlížeče včetně dalších otevřených oken a záložek.

Vyskakovací okna na internetu se často používají ke škodlivému šíření nežádoucích reklam, a proto prohlížeče obsahují funkce blokování vyskakovacích oken.

V tomto případě, abyste mohli pracovat s konfiguracemi 1C:Enterprise 8 prostřednictvím prohlížeče, musíte zakázat blokování vyskakovacích oken.

Problémy nastávají také při práci na mobilních zařízeních. Například na iPadu nejsou podporována modální okna.

Chcete-li tyto problémy vyřešit, měli byste místo modálních oken používat blokující okna. Pro uživatele vizuálně vše vypadá stejně: okno blokuje rozhraní webového klienta.

Blokovací okno je však „vykresleno“ v horní části hlavního okna a blokována je pouze aktuální karta prohlížeče, na které je otevřena konfigurace, což vám umožňuje přepínat na jiné karty, protože modální okna prohlížeče se nepoužívají.

V prohlížeči se tak neotevírají vyskakovací okna a je zajištěna práce přes webového klienta na mobilních zařízeních.

Kořenový prvek konfigurace má vlastnost „Modality mode“, která určuje, zda lze v konfiguraci otevřít modální okna.

Pokud je vybrána možnost „Použít“, lze otevřít modální okna. Pokud je vybrána možnost „Nepoužívat“, modální okna nejsou povolena. Když se pokusíte zavolat metodu, která otevře modální okno, systém zobrazí chybovou zprávu:

S touto hodnotou vlastnosti „Modality use mode“ jsou povolena pouze blokující okna.

Pokud je vybrána možnost „Použít s varováními“, pak se při otevření modálních oken v okně zprávy zobrazí následující text:

Tato pracovní možnost může být použita jako přechodná při přepracování konfigurace, aby se upustilo od používání modálních oken.

Hlavní rozdíl mezi blokováním oken a modálními okny spočívá v tom, že otevření blokovacího okna nepozastaví provádění kódu.

Vývojáři proto budou muset přepsat programový kód, který používá modální okna, aby tuto funkci zohlednili.

Kód je potřeba rozdělit na dvě části:

  • otevření blokovacího okna;
  • zpracování výběru uživatele.

Fragment kódu uvedený na začátku článku je třeba přepsat takto:

&OnClient
Postup Vyplňte Produkty(Tým )
Upozornění = Nové PopisUpozornění(, ThisObject );

Režim dialoguOtázka.AnoNe);
EndProcedure
&OnClient
Postup (výsledek, Extra možnosti) Export
Pokud Výsledek = Návratový kód dialogu.Ano Pak
//algoritmus plnění
EndIf;
EndProcedure

Po provedení procedury ShowQuestion() se systém nezastaví, čeká na odpověď uživatele, provádění kódu pokračuje.

Uživatel si bude moci vybrat až po dokončení celého postupu. V tomto případě bude zavolána procedura exportu FillItemsQuestionComplete(). Jeho název jsme předali konstruktoru objektu DescriptionAlerts.

Procedura, která bude volána po provedení výběru, může být umístěna v modulu formuláře, příkazovém modulu nebo obecném neglobálním modulu.

V uvažovaném příkladu je volaná procedura umístěna v modulu spravovaného formuláře, takže jsme předali parametr ThisObject.

Zvažme volání procedury umístěné v obecném modulu. Chcete-li to provést, přidejte nový společný modul Zpracování oznámení, nastavte mu příznak „Klient (spravovaná aplikace)“ a nenastavujte příznak „Globální“. Do tohoto modulu umístíme proceduru Vyplňte dokončování dotazu na produkty ().

Potom bude obslužný program příkazu fill vypadat takto:

&OnClient
Postup Vyplňte Produkty(Tým )
Upozornění = Nové PopisUpozornění("Vyplňte Dokončení otázky k produktům",
Upozornění na zpracování);
Text otázky = „Tabulková část bude vymazána. Pokračovat?" ;
ShowQuestion (upozornění, text otázky, Režim dialoguOtázka.AnoNe);
EndProcedure

Po volání jakékoli metody, která otevře blokovací okno, musí procedura ukončit a kód, který se spustí jako další, by měl být umístěn do procedury, která bude volána po zavření okna.

Pro přenos kontextu (pomocná data, určité parametry, hodnoty proměnných) z procedury, která otevírá modální okno, do procedury volané při jejím zavření, je k dispozici třetí volitelný parametr konstruktoru objektu: DescriptionAlerts – Additional Parameters.

Tento objekt (jakéhokoli typu) bude předán proceduře popsané v popisu výstrahy jako poslední parametr.

Pomocí příkladu výše popsané části kódu to lze provést takto:

&OnClient
Postup Vyplňte Produkty(Tým )
Parametr1 = 0 ;
Parametr2 = 0 ;
Seznam parametrů= Nová struktura (“Parametr1, Parametr2″, Parametr1, Parametr2);
Upozornění = Nové PopisUpozornění("Vyplňte Dokončení otázky k produktům", TentoObjekt ,
Seznam parametrů);
ShowQuestion (Výstraha, "Část stolu bude vymazána. Pokračovat?",
Režim dialoguOtázka.AnoNe);
EndProcedure
&OnClient
Postup Vyplňte ProductsQuestionCompletion(Výsledek , Extra možnosti) Export
Pokud Výsledek = Návratový kód dialogu.Ano Pak
//analyzovat další parametry.Parametr1
//analyzovat další parametry.Parametr2
EndIf;
EndProcedure

Pokud potřebujete předat pouze jednu hodnotu, nemůžete použít strukturu, ale přiřadit tuto hodnotu parametru Additional Parameters konstruktoru objektu DescriptionAlerts.

Podívejme se na pár příkladů práce s blokováním oken.

Úkol 1: Otevřete další formulář

Z formuláře dokumentu kliknutím na tlačítko „Otevřít parametry“ je třeba otevřít formulář, na kterém jsou dvě zaškrtávací políčka Parametr1 a Parametr2, které musí uživatel nastavit. Po zavření formuláře zobrazte hodnoty parametrů v řádku zprávy.

Vytvoříme obecný formulář „ParametersForm“, do kterého umístíme podrobnosti Parametr1 a Parametr2 a také příkaz CloseForm:

Obsluha příkazu vypadá takto:

Obslužný program příkazů vypadá takto: &OnClient
Postup CloseForm (příkaz)
Seznam parametrů= Nová struktura ( "Parametr1, Parametr2", Parametr1, Parametr2);
Zavřít ( Seznam parametrů); EndProcedure

U formuláře nastavte vlastnost WindowOpenMode na „Blokovat celé rozhraní“:

Na formulář dokumentu umístíme příkaz OpenParameters, jehož handler je popsán takto:

&OnClient
Postup OpenOptions(Tým )
Upozornění = Nové PopisUpozornění(„Otevřít možnosti dokončit“, ThisObject);
OpenForm ( "GeneralForm.FormParameters", , , , , , Oznámení);
EndProcedure
&OnClient
Postup OpenOptionsComplete(Výsledek , Extra možnosti) Export
Pokud TypeValue (Result) = Type (“Structure”) Then
Pro každou KeyValue From Result Loop
Zpráva = Nové Zpráva uživateli;
Message.Text = “Klíč: “” ” + KeyValue.Key + “””, hodnota = ”
+ KeyValue.Value;
Zpráva. Zpráva();
EndCycle ;
EndIf;
EndProcedure

V uživatelském režimu spuštěním konfigurace pod webovým klientem získáme následující výsledky:

Pro zvětšení klikněte na obrázek.

Režim otevírání okna lze také zadat v posledním parametru procedury OpenForm.

&OnClient
Postup OpenOptions(Tým )
Upozornění = Nové PopisUpozornění(„Otevřít možnosti dokončit“, ThisObject);
OpenForm ( "GeneralForm.FormParameters", , , , , , Oznámení
FormWindowOpenMode.LockEntireInterface
);
EndProcedure

Úkol 2. Otázka při zavírání formuláře

Při zavírání okna zpracování se zeptejte uživatele, zda opravdu chce okno zavřít.

Tento problém lze vyřešit pomocí následujícího kódu umístěného v modulu formuláře pro zpracování:

&OnClient
Perem Je třeba zavřít formulář;
&OnClient
Postup před uzavřením (selhání, Standardní zpracování)
Pokud ne Je třeba zavřít formulář= Pravda Pak
Selhání = Pravda ;
Upozornění = Nové PopisUpozornění(„Před uzavřenímDokončení“, ThisObject);
ShowQuestion (Výstraha: "Opravdu chcete zavřít okno?",
Režim dialoguOtázka.AnoNe
);
EndIf;
EndProcedure
&OnClient
Postup Před dokončením uzávěrky(Výsledek , Extra možnosti) Export
Pokud Výsledek = Návratový kód dialogu.Ano Pak
Je třeba zavřít formulář= Pravda ;
zavřít();
v opačném případě
Je třeba zavřít formulář= Nedefinováno ;
EndIf;
EndProcedure

V proceduře formuláře BeforeClosing je uživateli položena otázka, příznak odmítnutí je nastaven na hodnotu True a uzavření formuláře je zrušeno.

Po kladné odpovědi na otázku se proměnná Need toCloseForm nastaví na True a formulář se opět uzavře.

Úkol 3: Zadání číselné hodnoty

Po kliknutí na tlačítko ve formuláři pro zpracování otevřete standardní dialog pro zadání čísla.

Chcete-li to provést, musíte místo metody EnterNumber() použít metodu ShowNumberInput(), která otevře blokovací okno namísto modálního.

&OnClient
Postup zadávání čísel (příkaz)
Upozornění = Nové PopisUpozornění("EnterNumberComplete", ThisObject);
ShowEnterNumbers(Výstraha, 0, „Zadejte množství“, 15, 3);
EndProcedure
&OnClient
Postup EnteringNumbersCompleting(Výsledek , Extra možnosti) Export

Zpráva = Nové Zpráva uživateli;
Message.Text = „Zadali jste množství“ + Výsledek;
Zpráva. Zpráva();
EndIf;
EndProcedure

Po zavření okna pro zadání čísla bude vyvolána procedura, jejímž prvním parametrem bude zadané číslo nebo Nedefinovaná hodnota, pokud uživatel odmítl zadání.

Úkol 4. Výběr barvy

Po kliknutí na tlačítko ve formuláři zpracování pomocí standardního dialogu pro výběr barvy uživatel zadá požadovanou barvu. Nastavte tuto barvu pro pozadí kliknutého tlačítka.

Přidejte příkaz SelectColor do formuláře s následující obslužnou rutinou:

&OnClient
Výběr barvy procedury (příkaz)
Dialog pro výběr barvy= Nové Dialog pro výběr barvy;
Upozornění = Nové PopisUpozornění("Výběr barvy dokončen", ThisObject);
Dialog pro výběr barvy. Zobrazit(Upozornění);
EndProcedure
&OnClient
Postup ChoiceColorsCompletion(Výsledek , Extra možnosti) Export
Pokud NE Výsledek = Nedefinováno Pak
Elements.Color Selection.Background Color= Výsledek ;
EndIf;
EndProcedure

U objektů Dialog pro výběr barvy (stejně jako dialogové okno Úpravy standardního období, Konstruktor formátovací čáry, Dialog běžného plánu úlohy, Dialog pro výběr písma) metoda Show() otevře blokovací okno.

Po zavření okna bude vyvolána procedura, jejímž prvním parametrem bude předána zvolená hodnota (barva, písmo atd.) nebo hodnota Nedefinováno, pokud uživatel volbu odmítl.

Je třeba poznamenat, že objekt FileSelectionDialog nemá metodu Show() na rozdíl od dialogů pro výběr barvy nebo písma, protože implementace těchto dialogů je výrazně odlišná.

Chcete-li použít dialogové okno pro výběr souboru ve webovém klientovi, musíte nejprve povolit příponu souboru.

Dialogy implementované prostřednictvím přípony souboru nevytvářejí stejné provozní problémy jako okna modálních prohlížečů, takže otevírání blokujících oken pro objekt FileSelectionDialog nebylo implementováno.

Na závěr poznamenáváme, že počínaje vydáním 8.3.10 byla ve webovém klientovi ukončena podpora pro modální okna. V tomto případě, pokud je v konfiguraci volána modální metoda, je vygenerována výjimka. Ve webovém klientovi byla také ukončena podpora režimu rozhraní V samostatných oknech. Navíc v tenkém i webovém klientu již není možné otevřít formulář v samostatném okně (při práci v režimu rozhraní Záložky). Takové drastické kroky umožnily opustit režim rozhraní, který již nepodporují všechny moderní prohlížeče.

Jaký praktický závěr lze z těchto informací vyvodit? A závěr je vcelku jednoduchý – pokud jsou ve vaší konfiguraci z nějakého důvodu stále modální volání, pak se na těchto místech webového klienta zobrazí okno s chybovou hláškou. Chtěl bych varovat před pokusem „vygooglovat“ nějaké rychlé řešení tohoto problému, protože... Většina rad vychází z tohoto receptu: v konfigurátoru na konfigurační úrovni nastavte vlastnost „Modality use mode“ na „Use“. Přirozeně to v tuto chvíli nebude fungovat jen proto, že samotné moderní prohlížeče již nepodporují modální volání.

A máte pouze dva způsoby, jak vyřešit výše popsaný problém:

  1. Aktualizujte platformu na verzi 8.3.10+ (8.3.11), nastavte konfigurační vlastnost „Režim kompatibility“ na „Nepoužívat“ a přepište fragmenty kódu, které používají modální metody, na asynchronní model obchodní logiky
  2. Doporučte svým klientům, aby používali starší prohlížeče, které stále podporovaly modální volání (Mozilla Firefox verze 37 a nižší, Chrome verze nižší než 37 atd.).

Mimochodem, počínaje verzí 8.3.11 již nejsou podporovány webové prohlížeče Microsoft Internet Explorer verze 8 a 9.

Webové prohlížeče jsme řešili ve světle modality, nyní je čas vyjasnit situaci s ostatními klienty.

Počínaje verzí 8.3.5 je vlastnost Modality Usage Mode u tenkých a tlustých klientů respektována pouze v případě, že je zadána možnost příkazového řádku /EnableCheckModal. Tento parametr se automaticky vloží do příkazového řádku pouze při spuštění aplikace z konfigurátoru. Pokud tento parametr není zadán, nejsou generovány žádné výjimky a odpovídající varování se nezobrazují. Tito. v praxi při použití tlustého a tenkého klienta není při použití modálního režimu pozorována žádná zásadní změna v provozu - modální volání budou fungovat stejně jako dříve, aniž by produkovala jakákoli varování, jako u webového klienta.

Abychom tečkovali všechna „i“, poznamenáváme, že počínaje edicí 8.3.9 je konfigurační vlastnost „Režim použití synchronních volání rozšíření platformy a externích komponent“ v tlustém klientovi ignorována, zatímco odpovídající synchronní metody fungují bez generování výjimky a zobrazování varování. Uvedená ignorovaná vlastnost byla přidána ve verzi 8.3.5 pro podporu asynchronní práce s externími komponentami, kryptografie a rozšíření pro práci se soubory ve webovém prohlížeči Google Chrome. Je jasné, že to nemá nic společného s tlustým klientem, a proto „tiché“ ignorování této vlastnosti jednoduše eliminovalo zbytečné kontroly použití synchronních metod při použití konfigurace.

Mimochodem! Vzhledem k tomu, že platforma sebevědomě směřuje k webu, zavedli vývojáři ve verzi 8.3.8 určitá omezení do programového kódu, který je spojen s logikou pro uzavření formuláře nebo aplikace, prováděné v tlustých a tenkých klientech. Nezapomeňte si přečíst náš článek, který podrobně popisuje tuto nuanci. Kromě toho je v kurzu „Profesionální vývoj rozhraní a formulářů v 1C: Enterprise 8.3“ kapitola věnovaná opuštění modality a na toto téma můžete nasbírat spoustu užitečných a relevantních informací.

Kolegové, existují dvě věci, které můžete číst donekonečna: zdroj VKontakte a seznam změn v příštím vydání platformy, takže shrňme konečné výsledky;)

V procesu zvažování příkladů, které vám umožňují přejít od prvků synchronního modelu k asynchronnímu, jste si pravděpodobně již všimli, že v obecném případě existuje více programového kódu. Čím více kódu je, tím více se zvyšuje náročnost jeho další údržby a ladění.

Množství kódu se navíc ještě zvýší, pokud během vývojového procesu použijeme více dialogů. Proto je třeba v procesu vývoje aplikačních řešení zaměřených na práci ve webovém klientovi pamatovat na pracovní paradigma, které se v současnosti používá v moderních webových aplikacích. Pokud tedy vaše konfigurace obsahuje mnoho interaktivních dialogů s uživatelem a varování, pak má smysl přehodnotit tuto funkci ve prospěch některých jiných přístupů k organizaci interakce s uživatelem.

Místo závěru

Náš cyklus „První kroky ve vývoji 1C“ skončil. Pokud jste si ji přečetli celou, pak jste si s největší pravděpodobností již všimli, jak se platforma v poslední době vyvíjí mílovými kroky. Materiál v této sérii byl napsán relativně nedávno, ale byli jsme nuceni jej vážně aktualizovat, protože... I za tak krátkou dobu se objevila spousta nových důležitých funkcí a změn. Takové velké změny mohou být pro programátora 1C poněkud matoucí, pokud po celou tu dobu nevyrostl a nevyvíjel se s platformou profesionálně.

Na specializovaných internetových zdrojích si můžete často přečíst požadavky začínajících programátorů a jejich zralejších kolegů na doporučení materiálů, které by jim pomohly pochopit rozsáhlé a někdy zdánlivě nekonečné možnosti platformy 1C. Již tradičně doporučujeme věnovat pozornost našim kurzům programování

Proč dochází k chybě „Použití synchronních metod na klientovi je zakázáno“?

Pokud na takovou chybu narazíte při vyplňování lekcí, je velmi snadné ji opravit.

Vraťte se do konfigurátoru a vyberte položku nabídky "Konfigurace" -> "Otevřít konfiguraci":

V okně, které se otevře, klikněte pravým tlačítkem myši na položku „Konfigurace“ a z nabídky, která se otevře, vyberte „Vlastnosti“:

Otevře se okno s konfiguračními vlastnostmi (vpravo):

Přejděte úplně dolů a najděte tam položku „Modality mode“:

Nastavte jeho hodnotu na "Použití":

Pozornost! Vezměte prosím na vědomí, že pokud používáte platformu 1C odlišnou od té, kterou jsme stáhli v první lekci (pozdější verzi), budete mít také pole „Režim pro používání synchronních hovorů...“. Musí být také nastaven na „Použít“.

Nakonec vyberte položku nabídky „Konfigurace“ -> „Uložit konfiguraci“:

Připraveno! Nyní se již chyba nebude vyskytovat.

Vysvětlení níže - pro ty, které zajímá, co jsme udělali.

V naší konfiguraci jsme povolili režim modality. Ve výchozím nastavení je tento režim zakázán a neumožňuje nám používat příkazy jako EnterNumber, EnterString, EnterDate, OpenValue.

Faktem je, že tyto příkazy jsou modální. Jejich vyvoláním se před uživatelem objeví okno (například pro zadávání informací), které zablokuje možnost práce s programem až do zavření okna.

A protože přítomnost takových oken je při práci s 1C prostřednictvím webového prohlížeče extrémně nežádoucí, při vývoji nových konfigurací je režim modality ve výchozím nastavení vypnutý.