Подсистема в 1C 8.3- дървовиден обект с метаданни, който е отговорен за изграждането на командния интерфейс за конфигурация.
По-долу в статията ще говорим за подсистеми, започващи от версия 8.2.
Факт е, че във версия 8.1 (както и за обикновено приложение 8.2) също имаше подсистеми, но те служеха за съвсем различни цели, повече за разработчика, отколкото за потребителя. Подсистемите в 8.1 обикновено разделят различни функционалности. Също така, подсистемите помогнаха при комбиниране на различни конфигурации на 1C - беше възможно да се посочи коя система да се прехвърли.
1C подсистеми и интерфейс за програмиста
Във версии 8.3 и 8.2 подсистемите са основният инструмент за изграждане на команден потребителски интерфейс. Обектите на метаданни "Подсистеми" имат йерархична структура, за да конфигурирате "подменюто" в интерфейса, трябва да добавите подчинена подсистема:
Свойства и настройки
Помислете за настройките и свойствата на подсистемите в конфигуратора:
Вземете 267 1C видео уроци безплатно:
Включете в командния интерфейс- ако сте забравили да зададете този флаг, подсистемата няма да се покажев интерфейса.
Бутонът отваря панела за настройки на интерфейса, където можете да конфигурирате интерфейси в зависимост от ролята на текущия потребител:
картина- картината, присвоена на подсистемата, се показва в корпоративен режим. Можете да изберете стандартна картина или можете да добавите своя собствена, като предварително сте я създали като конфигурационен обект снимка:
В раздела Функционални опциие посочен списъкът с функционални опции, в които се използва тази подсистема.
Раздел Съставдефинира набор от обекти с метаданни, участващи в дадена подсистема.
В раздела Другоможете да опишете помощта на подсистемата и да посочите настройката Включете в помощното съдържание- дали да включите тази помощна тема в общата помощна информация за конфигурацията.
Ако в управлявания интерфейс не се показва отчет или обработка
Този проблем много често възниква сред начинаещите разработчици - като отчет или обработка е добавен към подсистемата, но не се вижда.
Първата причина за това може да е, че обектът няма дефинирана управлявана форма.
Втората причина е, че квадратчето за отметка "Използвайте стандартни команди" е отметнато в раздела Команди на обекта. Това се дължи на факта, че за отваряне на обработката може да бъде описана както вашата собствена процедура, така и стандартната:
Статията продължава цикъла "Първи стъпки в развитието на 1С".
В конфигурацията на платформата 1C: Enterprise при показване на информация най-често се използват таблици, които показват различни списъци с информация. Работата с такива списъци може да се извършва както под формата на списък, така и под формата на елемент (обработка).
В тази статия ще разгледаме тези опции за персонализиране на списъка, както и други аспекти на персонализирането на формуляри от страна на потребителя.
Приложимост
Статията разглежда управлявания интерфейс във версията "Версия 8.2" на конфигурацията, разработена на платформата 1C 8.3.4.482.
Ако работите с конфигурации, които поддържат този интерфейс, тогава информацията е подходяща за вас за текущите версии на платформата.
Ако работите в новия интерфейс "Такси", имената на някои конфигурационни команди, както и общата последователност от действия, може да се различават леко.
В допълнение, текущата версия на платформата е добавила нови възможности за търсене в списъците.
Персонализиране на формуляра и възможност за работа със списъци
За елементи от управлявани форми е възможно да се промени видимостта и някои други свойства. За тези цели в контролиран вид в менюто Всички действияслужи като параграф Променете формата.
След натискане на тази команда ще се появи прозорецът "Настройки на формуляра".
В прозореца, който се показва, като използвате квадратчетата за отметка, можете да промените видимостта на някои детайли. В този случай формата автоматично се мащабира.
Можете да промените реда на детайлите. Добавете нова група и поставете някои атрибути (елементи) в нея, като дефинирате опцията за тяхното групиране (хоризонтално, вертикално).
Реквизитите, включени в групата, ще бъдат поставени съответно. Освен това за елементите можете да персонализирате свойства като ширина, височина, данни за заглавката.
Можете да дефинирате атрибут, който ще се активира при отваряне на формуляра.
Важно свойство е възможността за добавяне на нови полета към формуляра. Това става възможно чрез референтни типове реквизити.
Например, да имате атрибут тип референтен тип във формуляра Контрагент, може да добавя Лицето за контакт, ако тази променлива присъства в директорията "Изпълнители".
Допълнителните полета могат да бъдат премахнати, ако е необходимо. Създадените в конфигуратора полета не могат да бъдат изтрити. Всички настройки, направени от потребителя, се запазват.
За да се върнете към настройките по подразбиране в прозореца "Настройки на формата" в менюто Всички действиятрябва да изберете елемент Задайте настройки по подразбиране.
В допълнение към персонализирането на формуляри в управлявания интерфейс е възможно да се персонализират списъци (елементи на директории, документи).
Под формата на списък в менюто Всички действиясъдържа специална команда Персонализирайте списъка.
Отваря се прозорецът "Персонализиране на списъка". В този прозорец можете да избирате, сортирате, дефинирате условен дизайн и групиране.
Фигурата показва формуляр за редактиране на селекцията.
Изборът може да се извърши на няколко полета. В този случай по подразбиране изборът ще работи според условието И. Можете също да използвате условията ИЛИ и НЕ.
За да използвате условието ИЛИ (НЕ), трябва да добавите съответната група (ИЛИ група, НЕ група) с помощта на командата Условия за група.
Фигурата показва формуляр за дефиниране на полета за сортиране.
Възможна е настройка на групиране. На фигурата е избрано полето за групиране Контрагент.
Следващата фигура показва как ще се извърши групирането.
Можете да оцветите списъка по произволен начин или да приложите други елементи на условен дизайн (маркиране с шрифтове, определено форматиране) според определено условие, както и да изберете списъка с полета, които да се форматират.
Фигурата показва резултата от условния фон на полето Сума.
Когато сумата е > 100 хил.
Трябва да се отбележи, че е възможно да се преглеждат директории в йерархичен режим.
Чрез елемента може да се конфигурира йерархичен преглед на директории Режим на прегледв менюто Всички действия... Можете да изберете една от опциите: Йерархичен списък, Списък, дърво.
Възможно е също така да настроите свое собствено групиране на елементи от директорията по някои подробности.
Например, можете да групирате артикул по доставчик. Пример е подобен на този, в който разгледахме групирането на документи „Продажба на стоки и услуги“ по контрагенти.
Удобна функция е многократен избор в списъците с последващо изпълнение на групови действия (задържане, отмяна, премахване на маркировката за изтриване).
Изборът на обекти в списъка се извършва чрез задържане на клавиша Shiftили Ctrl.
Търсенето на определена стойност в списък има свои собствени характеристики. Търсенето работи в режим на избор. Остават само онези низове, които отговарят на условието за търсене.
За да търсите по стойност в текущата колона, просто позиционирайте курсора върху желаната колона и щракнете върху бутона намирамв командния панел. Ще се появи прозорец, в който също трябва да кликнете върху бутона намирам.
Можете да използвате квадратчето за отметка, за да направите търсенето си по-конкретно. Търсене в намерено.
Когато търсите по низ от данни от референтен тип (например мерни единици), трябва да изберете подходящата опция за търсене ... (по ред).
Това завършва със списъците и начините за персонализирането им. В следващата статия ще продължим да се запознаваме с интерфейса и ще разгледаме удобен инструмент за информиране на потребителя, за който не сме говорили преди. Какво представлява този инструмент? :)
Предполагам, че няма нужда да ви казвам какво представлява ACS, линкер за настройки и изобщо целият набор от обекти, предназначени за работа с ACS. Основните области на използване, освен сложните действия в кода, са динамичните списъци и отчети, като и в двата случая много значителна функционалност остава зад кулисите. Често дори не се замисляме за логиката на поведението и взаимоотношенията на всички участници в процеса, т.к обикновено решаваме доста прости проблеми или разчитаме на настройките по подразбиране на платформата. Но там, където има мълчание, има и вътрешна логика, един вид „лоша услуга“ 1C, преодоляването на плодовете на която за постигане на желания ефект понякога е трудно и неочевидно, и в същото време е достатъчно просто да използвайте инструментите правилно.
Желаещите могат да пропуснат части 1-4 и да преминат направо към примерите.
Ще се опитам да се спра малко по-подробно на работата на селекциите на ACS за случая на тяхното приложение в отчетите. Предполагам, че поведението в динамичните списъци, с няколко предупреждения, ще бъде подобно. И така, селекции в доклади, малко теория и след това конкретни примери.
Използват се SP 8.3.6 и по-нови, ITS раздели (клауза 10.3.7.5 и др.), Книгата „Професионално развитие в системата 1C-Enterprise 8“ (Казан, 2012 г., втори том). В книгата на Е. Хрусталева изобщо не се намери нищо разбираемо по тази тема.
Част 1
Както знаете, линкерът за настройки има колекциите „Настройки“, „Фиксирани настройки“ (наричани по-долу „FN“) и „Потребителски настройки“ (наричани по-долу „PN“). Докладът може да има няколко опции, докато връзките между опцията N, PN и FN са много особени. Също така, нека не забравяме за източника на наличните настройки и неговия "прародител", който обикновено е самата верига, която също има свои собствени настройки по подразбиране.
* Настройки - настройки, създадени в режим Конфигуратор и променени в режим редактиране на опцията за отчет;
* Потребителски настройки - настройки, които потребителят променя в режим 1C: Enterprise, чисто интерфейс;
* FixedSettings - тези настройки, които се задават от вградения език, вкл. се задават имплицитно от системата. Това свойство съдържа стойностите за избор, които се предават на формуляра с помощта на неговите параметри (структурата "Избор").
Настройките и FN са сходни по дизайн и имат колекция "Избор" от типа "Избор на състав на данни", достъпна за промяна на състава по всяко време от съществуването на отчета. В същото време настройките са достъпни за промяна на интерфейса чрез редактиране на вариант, докато FNs изобщо не са налични. PN от своя страна е "бъркотия", където както самата "Селекция", така и отделни обекти от типа "Елемент за избор от състава на данните" (т.нар. вложен обект) могат да бъдат равни елементи. Въпреки наличието на подходящи методи, е невъзможно програмно да се промени съставът на колекцията от PN елементи, ако това е PN на самия отчет и не е направен „от нулата“ от дизайнера - 1C ще съобщи, че „Колекцията на потребителските настройки не може да промени състава си, тъй като е свързан с данните за настройките на оформлението. " ITS казва: „Имотът не е достъпен за писане с помощта на вградения език.“, Но, както ще видим по-късно, е възможно да се повлияе на PN. "Кашата" от обекти има вътрешни връзки - проверява се за последователност на условията при генериране на отчет и при промяна на композицията. На ITS четем: „Елементи, които сами по себе си са маркирани като персонализирани, няма да бъдат добавени. Например, персонализиран филтър няма да включва филтърен елемент, който е маркиран като персонализиран. Елементи, съдържащи персонализирани елементи, няма да бъдат добавени. Например, група условия няма да бъде добавена, ако групата съдържа елементи, маркирани като персонализирани. За вложени елементи свойството DisplayMode не се анализира. Те се добавят или не се добавят заедно с родителските елементи." Така "старшинството" на обектите действа зад кулисите. В този случай може да се получи ефект, когато интерфейсът ви позволява да посочите противоречиви селекции за вариант и неговия ST, както и в рамките на ST.
Изглежда, че "старшият" е опцията. Но щракването върху „Още“ / „Промяна на вариант“ и потвърждението на промените в отворения формуляр извиква манипулатора на събитието на формуляра , докато изборът се появява в панела "Общи" на формуляра, извикан от "Настройки ...", и се появява във формуляра за отчет, но НЕ се показва в раздела "Избор"; освен това, или се появява веднага както в основния формуляр на отчета, така и във формуляра чрез "Настройки ..." (ако има флаг "Включване в потребителски настройки"), или нито там, нито там. Но във всеки случай НЯМА да бъде в раздела "Избор" на формуляра "Настройки ...". Разликата между раздела "Общи" на формуляра "Настройки ..." и основния формуляр за отчет се определя от полето "Режим на редактиране" (нормално - само в "Настройки", бързо - също и в самия формуляр за отчет), но мисля, че всички знаят това. Между другото, стойностите "Избор" и "Бързо" не са синхронизирани по никакъв начин и може да си противоречат, но стойностите "Бързо" във формуляра за отчет и във формуляра за настройки са строго синхронизирани. Така че, когато редактирате вариант, той самият се променя (но неговият идентификатор и име не се променят), но PN остават НЕ модифицирани (т.е. дори да говорим за тях, т.е. за флага за включване на един или друг елемент в PN ).
Щракването върху "Изберете опция..." и потвърждаването на промените във формуляра, който се отваря, извиква събития в следния ред:
WhenLoadingOptionOnServer
При актуализиране на персонализирани настройки на сървъра
В същото време нито опцията, нито PN се променят по никакъв начин. Следователно е ясно, че опцията и настройките, ако са свързани, изобщо не са пряко свързани.
Щракването върху „Настройки...“ и потвърждаването на промените в отворения формуляр само задейства събитието При актуализиране на персонализирани настройки на сървъра(в този случай PN се променя, но изгледите и ключът (ако не са били) не се получават; ако "Бързо" е активирано за елементите на "Избор" на PN обекта, тогава в допълнение към "Избор", елементите му се появяват като полета, тоест .се държи подобно на вложените елементи. Тези настройки се записват при затваряне и се възстановяват следващия път, когато влезете във формуляра. Не докосва и не променя опцията по никакъв начин.
Щракването върху „Още“ / „Задаване на настройки по подразбиране“ във формата за настройки (както и елемента „Стандартни настройки“ в опцията за редактиране) само задейства събитието При актуализиране на персонализирани настройки на сървъра... В този случай опцията се променя, но PN се променя. Ако опцията е била променена преди това, тя остава променена (нито флагът за промяна се нулира, нито действително направените настройки се нулират).
Щракването върху „Свойства на елемента за персонализирани настройки“ в дървото на структурата във формата за редактиране на вариант добавя обекта „Избор“ и той се оказва празен и не се синхронизира по никакъв начин със съществуващата селекция на вариант и съществуващата вложена селекция елементи.
Оттук и препоръката: ако трябва да зададете някои селекции в режим "Конфигуратор", за да не се занимавате с кода и да не са във версията, а да са в интерфейса на отчета - трябва да манипулирате не селекцията елементи на опцията, променяйки техните свойства, но самата селекция, бутоните "Свойства на елемента ..." и "Потребителски настройки".
Добавянето на нещо, което се е появило в настройките към PN, изисква действия в кода или интерфейса, но изтриването и изчистването на настройките засяга PN незабавно и без никакви актуализации, например:
Report.SettingsComposer.Settings.Selection.Elements.Clear ();
Преди да затвори формуляра за отчет, системата пита само дали е имало промени във варианта. Ако има промени в PN, те ще бъдат запазени автоматично без въпроси, а също така автоматично ще се опитат да се прилагат в следващата сесия на работа с отчета.
бележки:
С редица грешки, това е прилагането на настройките, първо се показва съобщение за проблема и след това свързването все още възниква, събитието се извиква и съставяне на отчет. В същото време FN, ако бяха, все още се игнорират и само настройките играят роля.
Когато се добави селекция във формуляра „Промяна на вариант“, това се прави незабавно с поставен флаг „Включване в PN“, но, повтарям, от гледна точка на вградения език, PN остават непроменени.
Настройката на дисперсията на варианта и настройката на променливостта на PN не са пряко свързани, те са две различни посоки на промени.
PN има, наред с други неща, "Допълнителни настройки". Не успях по никакъв начин да разбера с какво и в кой момент се пълнят. Въпреки че отчетът съдържа настройки, „маркирани в избора и условния дизайн“ като персонализирани (според съвместното предприятие), допълнителните настройки във всички случаи се оказаха празни. Няма нищо за това в ITS.
Въпреки изявлението в съвместното предприятие, PNs са перфектно сериализирани в xml.
Ако и двата независими елемента на селекцията и самата селекция са включени за използване, тогава отчетът се сглобява правилно, но когато се покаже, дублира информацията за установената селекция в окончателното оформление.
Формулярът за редактиране по подразбиране за варианта на отчета съдържа много интересни неща, но никъде не работи с FN и PN, а с основните настройки работи повече за четене (освен че изчиства избора, реда, условното проектиране).
Част 2
Работата с Attitudes и FN чрез тяхната колекция е почти винаги допустима, но е важно да запомните, че същността на "третото ниво" се променя. Първото ниво винаги съдържа настройките по подразбиране на самия ACS; те също се появяват имплицитно в източника на наличните настройки; на второ ниво - настройките на използваната опция. Но тук логиката ви позволява или да "изтриете" основните инструкции, или да ги игнорирате. Но работата с PN вече не предоставя свободи и фините манипулации трябва да се извършват с помощта на специални методи, а понякога и временни спомагателни междинни обекти, например:
Comp = New DataCompositionSettingsComposer; // можете също да стартирате // comp.Initialize (SomeComposerSettings.GetSourceAvailableSettings ()); comp.LoadSettings (SomeComposerSettings.Settings); ОпределениSettingsComposer.DownloadUserSettings (comp.UserSettings);
Линкерът за настройки има метод (), който зарежда стойностите на персонализираните предпочитания, предадени като параметър на метода. Метод Вземете настройки() ви позволява да получите копие на текущите настройки (като се вземат предвид потребителските настройки). Метод Настройки за изтегляне() зарежда прехвърлените настройки в линкера за настройки (потребителските настройки също се презареждат въз основа на прехвърлените данни, като се има предвид наличието на ключове, вижте примера по-долу).
Прилагането на персонализирани настройки към основните настройки се извършва в метода Вземете настройки() настройки на линкера. В този случай се извършват следните действия:
* За типове DataCompositionOptionElement съдържанието на елементите се копира в съответните елементи за персонализирани настройки.
* За типове DataCompositionFeed елементите, които са в основните настройки и маркирани като Недостъпни, остават непроменени. Елементите от PN се прехвърлят към основните. Те се добавят в края на колекцията Selection.
* За типове DataCompositionElementGroup свойството Use се задава в съответния елемент на основните настройки (въз основа на знака за използване на елемента PN).
част 3
При формиране на крайната настройка, за да цитирам ITS, различни опции за настройка се комбинират, както следва:
* Ако някой тип настройки е изцяло маркиран като персонализиран, тогава получените настройки включват PN. В същото време, ако някои елементи от настройките са маркирани като недостъпни, тогава тези настройки ще бъдат поставени в получените настройки от свойството SettingsComposer.Settings.
* Ако някакъв вид настройки е маркиран като персонализиран не изцяло, а елемент по елемент, тогава елементите, маркирани като персонализирани, ще бъдат включени в получените настройки от Properties Composer.Custom Settings, а елементите, маркирани като недостъпни, ще бъдат взети в получените настройки от Properties Composer. Настройки....
* Фиксираните настройки се добавят към получените настройки „както са“. В този случай ситуацията е неприемлива, когато в FN и PN има настройки с едно и също име, например избор със същата лява стойност в условието. Имайте предвид, че дори пълното съвпадение на всички свойства на тези условия е забранено. Честно казано, малко нелогично.
Имайте предвид, че ако някой фрагмент от настройките попада в обхвата на функционалната опция и трябва да бъде ограничен, системата работи "безшумно" - премахва този фрагмент отвсякъде, не отчита нищо и по време на манипулации на програмата относно такъв фрагмент, тя работи "на празен ход" - грешки не произвежда, но няма и ефект от кода. Възможно е обаче различните версии да се държат различно.
част 4.
Разширението на формуляра за отчет ни предоставя параметрите "FN" и "PN", но никъде не се препоръчва да ги попълваме директно, като ги прехвърляме във формуляра. Както показаха експериментите, без допълнителни танци с тамбура, попълването на тези параметри се игнорира - то се презаписва, когато линкерът се инициализира по време на процеса на отваряне и когато се получават предварително запазени PN. Препоръчително е да се работи с PN ключове, според които те могат да бъдат получени от хранилището за настройки и след това да се отварят и използват, като това става автоматично отстрани на формуляра за отчет, а не от формата за повикване.
Параметърът "SourceAvailableSettings" се преобразува автоматично в информация за линкер, когато формулярът е създаден на сървъра и не може да бъде отменен. По-скоро може, но това ще даде ефект само след пълно предефиниране на цялата верига от свързани обекти. При което GetSourceAvailableSettings() ще върне Undefined до края на обработката на всички събития при отваряне на формуляра.
Обърнете внимание, че параметрите на формата, които всъщност не са ключови, "разтягат" действието си върху няколко събития, ако е зададен флагът за образуване при отваряне. Така че, в случай ProcessingCheckFillsOnServer, извикан при отваряне и формиране, параметърът "Избор" ще бъде наличен, но с него, но извикан просто чрез натискане на потребителя върху бутона "Генериране", той вече няма да бъде. Това се дължи на факта, че всички тези събития се обработват за едно "посещение" на сървъра, ако образуването при отваряне е активирано и само в самия им край контролът се прехвърля на клиента и се извиква Отваряне... В този случай естествено се губят неключови параметри.
Общият ред на изпълнение на събитията при отваряне на формуляр с флага за генериране на отчет при отваряне (малко повече от описаното в "Професионално развитие"):
OnCreateAtServer
Преди LoadingOptionOnServer
WhenLoadingOptionOnServer
Преди да изтеглите персонализирани настройки на сървъра
При качване на персонализирани настройки на сървъра
При актуализиране на персонализирани настройки на сървъра
ProcessingCheckFillsOnServer
Отваряне
В същото време нито опцията, нито PN се променят, освен ако не са положени специални усилия.
част 5.
Сега нека се спрем по-подробно на задачата за отваряне на формуляр за отчет с неговото изграждане и предварително определен избор. Кратка информация за това има в ИТС и в методическите препоръки, но там е осветен само самият принцип и тънкостите не се разкриват. Така че, за контекстно извикване на отчета, е необходимо да се предаде на неговата форма параметъра "GenerateOnOpening", равен на True; и параметър "Избор", съдържащ структурата. Структурните ключове са имената на ACS полета или параметри на ACS, а стойностите са техните стойности. Цитирайки SP, ако има ACS параметър с име, съответстващо на името на структурния ключ, тогава стойността ще бъде зададена на него. Ако няма параметър, но има поле, тогава към това поле ще бъде добавен избор. В същото време, ако има параметър и поле със същото име, системата просто тихо ще го игнорира и няма да инсталира нищо.
В "Професионално развитие" има пример за промяна (т.е. прихващане и преконфигуриране) на PN "в движение" в събитие Преди да изтеглите персонализирани настройки на сървъра, където се предава аргументът, съдържащ текущия PN. Всъщност това не винаги е така - например може да има случаи, когато грешка при запазване на PN в предишната сесия или несъответствия между Настройки, FN и PN ще доведат до факта, че аргументът "Настройки" ще бъде празен. И което е най-интересното, няма да е възможно да го конфигурирате напълно в това събитие, може да се направи само „в края“ на последователността от събития, а именно в събитието ProcessingCheckFillsOnServer.
Нека видим какво имаме, преди да заредим PN на сървъра.
За прост случай, когато нищо не е предварително дефинирано в ACS и не са включени елементи в PN, ситуацията е следната: Настройки - празно; FN - съдържа правилната селекция; PN съдържат празна селекция. Оформянето работи правилно, но от гледна точка на потребителя интерфейсът противоречи на смелостта и е обезкуражаващ - изборът работи, но не се вижда. По същия начин, ако активирате Избор в PN в структурните настройки на варианта, отчетът също се изгражда, като се вземе предвид селекцията, но потребителят също не вижда никакви селекции.
Нека зададем предварителен избор в настройките на ACS в конфигуратора (равни на празни стойности) и да ги активираме в PN. На теория FN трябва да попълни настройките, а тези - PN, но всъщност имаме: в Настройки - Избор с желания елемент, но празна дясна стойност, FN - съдържа правилната селекция, а PN - все още не съдържа каквото и да е. Освен това в този случай отчетът няма да бъде изграден, т.к дясната стойност за избор е празна, въпреки стойността, подадена в параметъра Selection.
Опитът за работа с PN елементи също не дава резултат. За елемента PN можете да промените само флага „Използване“ и участието в „Бързо“. Стойността за избор на интерфейса ще бъде празна, системата няма да генерира никакви грешки. По същия начин, опитът за работа с PN Selection също ще работи, в дебъгера правилната стойност ще се види като правилно попълнена, но няма да видите нищо в интерфейса. Нека ви напомня, че е невъзможно да се промени съставът на PN. Следователно са необходими допълнителни настройки. Например:
& Процедура на сървъра SetPresetSections (UserSettings) Ако не е Parameters.Property ("Избор") Тогава върнете EndIf; Ако Parameters.Selection.Number () = 0, тогава връщане EndIf; rTypeEO = Тип ("DataCompositionSelectionElement"); За всеки ключ От параметри Цикъл на избор rField = Ново поле за състав на данни (ключ.Ключ); // Ако (TypeZnch (kiz.Value) = Type ("Array") или TypeZnch (kiz.Value) = Тип ("Списък със стойности")) и kiz.Value.Quantity ()> 1 Тогава pComparisonType = ComparisonTypeDataCompositionInList; В противен случай pComparisonType = DataCompositionComparisonType.Equal; EndIf; // pHnecessaryChoice = Недефиниран; // вижте дали има Избор в персонализираните настройки rn се изисква EO = Undefined; // проверява дали има отделен елемент DataCompositionFeed в персонализираните настройки За всеки elnastr От цикъла CustomSettings.Elements IfTypeZnch (elnastr) = Type ("DataCompositionSelection") и pHnecessarySelection = Undefined Тогава // може да бъде само един pHnecessarySelection = Elnastr; // това може да се направи извън цикъла, но е необходимо да се повторят персонализираните настройки в името на елементите ... В противен случай, ако TypeZnch (elnastr) = rTypeEO Тогава // това е елемент за избор, може да има много от тях, но ни интересуват да не са инициализирани или със задължителното поле. EndIf; EndIf; Край на цикъла; // Ако pH е подходящо<>Undefined Тогава // става приоритет rn За всеки elotb От pHuzhnyObot.Elementy Cycle Ако elotb.LevoeValue = pField Тогава pHuzhnyEOizObra = elotb; Прекратяване на EndIf; Край на цикъла; Ако pHRequiredEOfromSelection = Undefined, тогава pHRequiredEOfromOffice = pHRequiredSelection.Elements.Add (rTypeEO); pHRealEOfromSelection.LeftValue = pField; EndIf; pHRealEOfromSelection.ComparisonType = pComparisonType; pHRealEOfromSelection.RightValue = kiz.Value; pHRequiredEOisObtaining.Usage = Вярно; // pHAlrightEO.Usage = False; Друго Ако се желае pH Избор = Недефинирано и pH се желае EO<>Undefined Тогава // поставяме елемента pHazhnyEO.LeftValue = pField; pHRealEO.ComparisonType = pComparisonType; pHazhnyEO.RightValue = kiz.Value; pHEO.Usage = Вярно; EndIf; pHazhny = Недефиниран; За всеки elotb От Report.SettingsComposer.Settings.Selection.Elements Loop // по приятелски начин трябва да има рекурсивно търсене! Ако TypeZnch (elotb) = pTypeEO и elotb.LevoValue = pField Тогава pHnecessary = elotb; Прекратяване на EndIf; Край на цикъла; Ако pHRequired = Undefined, тогава pHRequired = Report.Settings Composer.Settings.Selection.Elements.Add (rTypeEO); pHLeftValue = pField; EndIf; pHOfComparisonType = pComparisonType; pHazhny.RightValue = kiz.Value; pHazy.Usage = Вярно; // Край на цикъла; Report.SettingsComposer.FixedSettings.Selection.Elements.Clear (); // в противен случай казваме, че елементите се пресичат / противоречат на EndProcedure
Най-правилният начин да го наречете е:
& AtServer Процедура заFillingVerificationProcessingAtServer (Отказ, проверени атрибути) SetPresetSections (Report.SettingsComposer.UserSettings); Край на процедурата
Тогава контекстно повикване, например от референтен формуляр, ще изглежда така:
& OnClient Процедура OpenReport (команда) Ако ValueFilled (Object.Link) Тогава out = Нова структура ("ReferenceOnDirectory", Object.Link); // това е името на полето в ACS на отчета Form Parameters = New Structure ("Избор, генериране при отваряне", Ot, True); OpenForm ("Report.Report1.Form.ReportForm", Параметри на формуляра, EtaForm); EndIf; Край на процедурата
част 6.
При необходимост променете настройките на отчета, докато работите с него, вкл. както при стартиране, така и след отваряне, най-правилният начин е да промените "от самото начало", т.е. от настройките на ACS. Промяната на схемата на ACS се извършва само с обекта Report (или ExternalReport), а не с данните от формуляра и сама по себе си не променя нищо - в настройките и в PN същото остава както беше и FN може остават празни. Следователно, в зависимост от нашите задачи:
След екзекуцията
Report.SettingsComposer.LoadSettings (ACS.По подразбиране)
променя се само вариантът и нищо повече;
След завършване на техниката, дадена в клауза 2 (с помощта на "посредника" и метода Изтеглете персонализирани настройки()
работи само ако текущите PN са нулирани чрез интерфейса. Сами по себе си те няма да се променят, когато опцията се промени. Това променя селекцията, но не добавя нов елемент за избор.
След екзекуцията
ThisForm.CreateFormElementsCustomSettings (, DisplayModeDataCompositionSettings.All)
платформата просто пада тихо. Тестван на няколко различни издания. А обаждането с режима на показване на настройките само за бързите няма смисъл - не сме повлияли на състава им, така че така или иначе нищо няма да се промени.
И тъй като все още трябва да променим напълно не само вътрешните селекции, но и дисплея във формуляра за отчет и в свързаните форми, тогава трябва или да променим само Избора, или да продължим по следния начин:
& Промяна на процедурата на AtServerSKD () rObject = FormInValue ("Отчет"); off = pObject.DataCompositionSchema.SettingsVariants.Get (0) .Settings.Feed; eo = otb.Elementy.Add (Тип ("DataCompositionOptionElement")); eo.LeftValue = NewDataCompositionField ("ReferenceRef.Field1"); eo.ComparisonType = DataCompositionComparisonType.Equal; eo.RightValue = Вярно; eo.Use = Истина; ValueVRequisitForm (rObject, "Отчет"); Report.SettingsComposer.LoadSettings (rObject.DataCompositionSchema.Default Settings); Report.ConfigurationComposer.Restore (); // желателно, въпреки че това така или иначе не засяга FN. // всъщност това може да се нарече промяна в състава на PN За всеки имейл От Report.ComposerSettings.Notroyki.Obor.Elements Цикъл e.Display Mode = Display ModeDataCompositionSettingsSettingElement.BystryAccess; Ако има EmptyString (идентификатор на имейл на UserSettings), тогава // можете да използвате метода за PN елемента. // важно - идентификаторът може да бъде ВСЕКИ, а не UUID или GUID! EmailPresentationUserSettings = "Пробен период"; EndIf; Край на цикъла; comp = New DataCompositionSettingsComposer; Comp.LoadSettings (rObject.DataComposition Scheme.Default Settings); Report.Settings Composer.DownloadUserSettings (comp.UserSettings); За всеки имейл От Report.Settings Composer.UserSettings.Elements Цикъл eDisplay Mode = Display ModeDataCompositionDataCompositionSettings.QuickAccess; // изтегляне на EndCycle към формуляра за отчет; // и сега ще има ефект: ThisForm.CreateUserSettingsFormElements (,DataCompositionSettingsDisplayMode.QuickAccess); Край на процедурата
Всъщност можете да изучавате тази механика за дълго време. Тази публикация израства от изследване на начини за решаване на един конкретен проблем и поради това е много едностранчива; но подозирам, че по принцип е възможно да се напише отделна книга за вътрешната логика на настройките, особено персонализираните, не по-фини от тези на Кристалев. За съжаление нямам време и енергия за това. Всеки, който има нужда от конкретни разработки, вече е добър.
Нещо е изяснено експериментално и следователно противоречиво. Тези, които знаят повече, са поканени да критикуват и коментират.
