Нов механизъм за поставяне на елементи във формата. Подравняване на елементи върху правилна форма Подравняване от край до край 1c

Въведение

Управлявани формуляри. Нова 1C разработка, предназначена да улесни работата на разработчика, като му даде повече време за писане на код чрез опростяване на дизайна на интерфейса. Всъщност често се оказва, че т.нар. "контролирани форми" са напълно неконтролируеми. UV не могат да правят такива банални неща като минимизиране/максимизиране на прозорец, да не говорим за позиционирането му на екрана и задаването на размера му в пиксели. Може би тези функции се смятаха за непотърсени и не бяха включени в новия интерфейс, но практиката показва, че понякога много липсват. За известно време проблемът беше частично решен от WSH, но исках нещо повече. Ето как е внедрен външен компонент, за да направи „управляваните формуляри“ малко по-управляеми.

Какво? Където? Кога?

Този VK е библиотека от функции за контролиране на състоянието и позицията на прозорците. Библиотеката също така съдържа няколко полезни системни функции.

Управление на състоянието на прозореца:

Разширяване ( HeaderWindow ) разширява прозореца на цял екран

Свиване (WindowTitle) - минимизира прозореца към лентата на задачите

Скриване (WindowTitle) - скрива прозореца (докато кодът на формуляра продължава да се изпълнява)

Покажи () - показва последната скрита функцияскрий() прозорец

CollapseWindow (WindowTitle) - в възстановява прозореца в първоначалното му състояние

ИСТИНСКА видимост (WindowTitle) - стр проверява дали прозорецът се вижда на екрана

TRUE Разширен (WindowTitle) - проверява дали прозорецът е увеличен на цял екран

TRUE Свито (WindowTitle) - проверява дали прозорецът е минимизиран до лентата на задачите

Задаване на прозрачност(Заглавие на прозореца, Коефициент) - задава прозрачността на прозореца. Степента на прозрачност се задава с помощта на коефициент (0-255).

Контрол на позицията на прозореца:

GetPosition(Заглавие на прозореца, х, Y) - Получава координатите на горния ляв ъгъл на прозореца спрямо екрана. Координатите се връщат чрез параметриX,Y.

Ход(Заглавие на прозореца, х, Y) - премества прозореца на определена позицияXY.В такъв случай XYса координатите на горния ляв ъгъл на прозореца.

Вземете размери- получава размерите на прозореца в пиксели. Стойностите се връщат чрез съответните параметри.

Задайте размери(Заглавие на прозореца, ширина, височина) - задава размера на прозореца в пиксели.

Системни функции:

GetCurrentPermission(Хорц, Верт) - получава текущата резолюция на екрана. Стойностите се връщат чрез съответните параметри.

GetPermissionList() - получава списък с разделителни способности на екрана, налични в системата. Данните се връщат във формата “RESOL.1, RESOL.2, RESOL.3...”. В демонстрационната обработка има пример за генериране на списък с разрешения във формуляр.

SetPermission(Избрана резолюция на екрана) - задава разделителната способност на екрана. Параметърът указва серийния номер на разрешението. Демонстрационната обработка показва пример за задаване на резолюция от предварително генериран списък.

Бонуси:

Сън (време за сън) сън().Времето за заспиване се посочва в милисекунди.

Сигнал (честота, продължителност) - изпълнение на класическата функциязвуков сигнал ().Позволява ви да зададете честотата и продължителността на звука.

Обща сума

Библиотеката е написана за нашите собствени нужди и вероятно ще бъде доразвита според нуждите. Ако някой има ярка идея да разшири функционалността му в рамките на предметната област, за която е замислен, тогава напишете вашите желания. Ако идеите се окажат полезни, те ще бъдат реализирани.

Комплектът за доставка включва: База със свързан VC под формата на общо оформление и демонстрационна обработка. VK в zip архив.

Редакторът на формуляри се използва за създаване и редактиране на формуляри на обекти на приложни решения. Обектните форми се използват от системата за визуално показване на обектни данни, докато потребителят работи.

Всяка форма представлява комбинация от три компонента:

  • диалог на формата - прозорец, който ще се показва на екрана;
  • модул за формуляри - програма на вграден език, отговорна за работа с контроли на формуляри и обработка на събития;
  • подробности за формуляра - набор от обекти, принадлежащи на формуляра, чиито данни той използва в своята работа.

Самият редактор на формуляри предоставя редактиране на диалоговия прозорец на формуляра, неговите детайли и извиква редактора на текст и модул, за да редактира модула на формуляра.

Прозорецът на редактора на формуляри съдържа три раздела, които позволяват редактиране на трите компонента на формуляра.

Редактиране на диалогов прозорец за формуляр

Редакторът на формуляри позволява на разработчика да се възползва напълно от широк набор от диалогови възможности. Нека изброим основните:

Панели, страници, отметки

Редакторът на диалоговия прозорец позволява на разработчика да постави специални контроли върху формуляра, които му помагат да придаде на формуляра свой собствен разпознаваем стил, да направи достъпа до данните прост и ясен и също така да побере голямо количество информация в ограничена област.

Редакторът ви позволява да поставите няколко панела във формуляр, всеки от които може да съдържа няколко страници. Например формуляр на документ може да съдържа панел с две страници: Продукти и Допълнителни:

Разработчикът има възможност да зададе режим, в който страниците ще се превъртат в панела, или да използва отметки за превключване между страници. Редакторът ви позволява да дефинирате голям брой различни опции за местоположение и показване на отметки:

Например отметките могат да бъдат поставени хоризонтално отгоре:

Или можете да подредите отметките отляво вертикално:

Контроли

Редакторът ви позволява да поставите голям брой различни контроли върху формуляра. Можете да поставите контроли чрез плъзгане или използване на специален диалог за вмъкване на контроли, който ви позволява едновременно да зададете желаните свойства на избраната контрола:

В случай, че формулярът съдържа голям брой контроли, разработчикът може да използва режима за показване на контроли в списък, който ви позволява бързо да навигирате до желания контрол:

Редакторът предоставя възможност за указване на реда, в който потребителят ще заобиколи контролите на формуляра при въвеждане и редактиране на данни. Възможно е да зададете автоматичен ред на преминаване или ръчно да зададете реда на преминаване в специален списък с контроли или чрез щракване с мишката директно върху формата:

Решетка, подравняване

Редакторът на формуляри има големи възможности за контролиране на разположението на елементите във формуляра. По-специално, той поддържа мрежово оформление, където границите и размерите на контролите са подравнени спрямо решетката на оформлението, разположена във формуляра. Разработчикът има възможност да промени стъпката на решетката за маркиране и по този начин да постигне по-точно местоположение на контролите:

Редакторът също поддържа използването на линии за подравняване, които служат за улесняване на подравняването и относителната позиция на контролите на формуляра. Например в следващата илюстрация линиите за подравняване се използват за позициониране на контролите на страницата Още:

Разработчикът има възможност да постави необходимия брой хоризонтални или вертикални линии за подравняване на страницата, както и да използва невидими линии за подравняване. Редакторът автоматично създава невидими линии за подравняване, след като две или повече контроли са подравнени по някоя от границите. Например, ако две полета с еднакъв размер са били подравнени вляво, ще бъде създадена невидима линия за подравняване по протежение на подравнените вдясно граници на тези полета.

Подравняването на контролите може да се извърши и с помощта на специални маркери, показващи желаната посока на движение на контролите. Маркерите се появяват, когато две контроли са в непосредствена близост една до друга.

Сините манипулатори за подравняване показват желаната посока на движение на контролата, за да я подравните с една от границите на съседната контрола:

Червените манипулатори за подравняване показват желаната посока за преместване на контролата, когато се припокрива с друга контрола:

Трябва също да се каже, че редакторът поддържа операции за подравняване, преоразмеряване и подреждане за група контроли:

Подвързии

Редакторът на формуляри ви позволява да персонализирате поведението на контролите, разположени във формуляра, така че при промяна на размера на формуляра да се осигури естествено възприемане на информацията: една част от елементите остава на място, другата част се движи заедно с границите на формата, а третата част променя размера си в съответствие с промяната на размера на формата.

За да уточни това поведение на елементите на формуляра, разработчикът може да опише свързвания - зависимостта на позицията на границите на контролите от позицията на границите на формуляра. Границата на контрола може да бъде прикрепена към границата или центъра на формуляр или към границата или центъра на друга контрола.

Редакторът поддържа голямо разнообразие от различни типове свързвания и може да ги показва графично:

Разделители

Разделителите са специални контроли, които ви позволяват да преразпределите пространството на формуляр, без да променяте размера му. В режим 1C:Enterprise разделителят има възможност да бъде „хванат“ от мишката и преместен във формуляра в неговите граници, като се вземе предвид възможността за местоположението на други контроли и ориентацията на разделителя:

Когато преместите разделител, всички контроли, свързани с разделителя, ще се преоразмерят или преместят според зададените котви:

ActiveX

Редакторът ви позволява да поставите ActiveX контроли във формуляр, който разработчикът може да конфигурира и впоследствие да управлява с помощта на вградения език:

Редактиране на модул формуляр

За да редактирате модула на формуляра, конфигураторът извиква редактора на текст и модул. Този редактор предоставя на разработчика голямо разнообразие от опции за създаване и модифициране на текст на модула.

Редактиране на подробности за формуляра

Редактирането на детайлите на формуляра се извършва в списъка, което ви позволява да създавате нови детайли, да променяте съществуващи детайли и да изтривате ненужни детайли:

Ако дадена форма има основен атрибут, който определя поведението на формата, който се различава от стандартния, той се маркира с удебелен шрифт. Разработчикът може да постави курсора върху желания атрибут и с помощта на командата от менюто веднага да отиде в диалоговия прозорец на формуляра, до контролния елемент, който съответства на избрания атрибут.

Допълнителна информация

Можете да се запознаете с използването на редактора на формуляри в реално време. За да направите това, можете да изтеглите демонстрационния видеоклип „Пример за разработване на мини система за търговия“, който показва процеса на разработване на мини система за търговия с помощта на този редактор за създаване на формуляри на документи „Приходна фактура“, „Разходна фактура“ и отчет форми "Анализ на продажбите" и "Анализ на продажбите по периоди."

Внедрено във версия 8.3.7.1759.

За да стане ясно за какво говорим в тази статия, е необходимо да направим малко пояснение.

Характеристика на управляваните формуляри е, че разработчикът не оформя директно външния вид на формуляра. Разработчикът създава само описание на формуляра, като използва някои логически правила. Въз основа на тези правила платформата самостоятелно генерира визуално представяне на формата. Освен това това визуално представяне зависи от размера на прозореца, в който се показва формата. Същият формуляр, показан в тесен прозорец или в прозорец, разширен на цял екран, ще има различен визуален облик.

И така, тази част от платформата, която формира визуалното представяне на формата, се нарича механизъм за поставяне на елементи във формата.

Защо беше необходим нов механизъм?

Първо, предишният механизъм, за съжаление, имаше недостатъци. Най-значимото от тях беше, че много промени в свойствата на елементите на формуляра, извършени на клиента, изискваха извикване на сървъра. И всеки достъп до сървъра води до забавяне.

Второ, ние оценихме опита от използването на управлявани формуляри и открихме редица критични нужди, които трябваше да бъдат адресирани.

И трето, искахме да вградим в новия механизъм възможности за бъдещо развитие.

Основни промени

Работата на предишния механизъм може да бъде схематично представена по следния начин:

Разработчикът създава дърво от елементи на формуляр в конфигуратора и задава свойствата на елементите. В момента, в който приложното решение трябва да покаже формата на потребителя, се случва следното. Първо, на сървъра, платформата създава описание на визуална форма. След това това описание се предава на клиента. И на клиента визуализаторформира изображението, което потребителят ще види.

Основното действие, което беше извършено на сървъра при създаване на описание на визуалната форма, беше изчисляването на дължините на линиите. Това се отнася за всички видове заглавия, надписи и т.н. Познавайки дължините на линиите, вече можете да изчислите подреждането на елементите във формата.

Тъй като тази операция беше извършена на сървъра, имаше два отрицателни аспекта. Първо, за изчислението използвахме не шрифтовете, които ще се използват на клиента, а тези, инсталирани на сървъра. И те могат да се различават, особено когато става въпрос за различни платформи (Windows, Linux). Или дори необходимите шрифтове може изобщо да не са инсталирани на сървъра. Второ, за да изчислим дължините, използвахме системата за растеризиране на шрифтове, която е на сървъра. И може да не работи точно като механизма за изобразяване на текстови низове, който съществува на клиента в интернет браузър, например. В резултат на това формулярите могат да се появят или с „скъсени“ текстове, или, обратно, с прекалено широки надписи.

Друг проблем беше, че нямаше адаптация към размера на прозореца, в който формата щеше да се показва на клиента. Всъщност на сървъра описанието на формуляра е създадено въз основа на минималния възможен размер на прозореца и по-нататъшният успех на неговото показване зависи от това колко добре „може“ да се разтяга.

В новия механизъм разделихме генерирането на описание на визуална форма, което преди се извършваше изцяло на сървъра, на две части, сървър и клиент:

Сървърната част стана значително по-малка. Не извършва никакви изчисления. На сървъра се създава само “празно” описание, което не съдържа точните дължини на текстовите полета и в него не се допускат адаптивни елементи. Сървърът управлява видимостта на елементите, но само тази, която се определя от функционалните опции и тази, която е зададена от потребителя. Но тук е невъзможно да се направи друго, тъй като самите функционални опции са достъпни само на сървъра. А интерактивната промяна на настройките от потребителя във всеки случай ще доведе до извикване на сървъра.

Резултатът е един вид „полуготов продукт“ от визуално представяне на формата, който се прехвърля на клиента.

Необходимите промени в описанието на визуалната форма се правят на клиента. Изчисляват се дължините на линиите, изчисляват се елементите за отзивчивост, свързани с размера на клиентския дисплей, и се разработва видимостта. След това, както и преди, започва да работи визуализаторът, който създава крайната форма, която клиентът вижда.

Поради факта, че изчисляването на дължините на низовете се извършва от клиента, успяхме да се отървем от ненужните и небрежни „празнини“ между елементите. И разработването на видимост на клиента без достъп до сървъра направи възможно ускоряването на работата на формулярите. Тъй като включването/изключването на видимостта на елементите на формата е една от най-често срещаните операции.

Някои нови функции

Отзивчиви елементи на интерфейса

Новият механизъм за поставяне на елементи във формуляра не само подобрява възможностите, които бяха налични преди, но и добавя нови възможности. Например, той адаптира външния вид на формуляра към размера на дисплея на клиента. Има няколко начина да направите това.

Първо се извършва автоматично обвиване на редове, регулиране на височината на заглавията и декорациите. Можете да видите как работи това на фигурата:

Ако във формуляра има дълги редове, които могат да бъдат разделени на отделни думи, тогава тези редове се обвиват, ако е необходимо. Съответно височината на формата се увеличава, тъй като долната й част се „движи“ надолу. В резултат на това формата ще изглежда нормално дори на тесни екрани. Освен това този механизъм работи динамично, което означава, че можете да компресирате формуляра в реално време и дългите редове ще се увият заедно с него.

Автоматичното обвиване работи за заглавия на елементи, заглавия на групи, текстови декорации и текст в бутони, които изглеждат като Хипервръзка.

Вторият елемент на адаптивността е промяната на ориентацията на групите. Групите и формата като цяло имат нова опция за ориентация - “ По възможност хоризонтално" При тази опция, ако клиентският дисплей позволява елементите да бъдат позиционирани хоризонтално, те се позиционират хоризонтално. Ако не, тогава те са разположени вертикално.

Третият елемент на адаптивност е автоматичното определяне на броя на колоните на превключвател или превключвател. Преди това, освен ако нямаше специални инструкции, броят на колоните беше зададен на максимум и се показваше в един ред. Сега, в същата ситуация, ширината на формуляра се анализира и броят на колоните се задава така, че превключвателят/превключвателят да изглежда добре на екрана.

Хоризонтално и вертикално подравняване

Преди това тази възможност отсъстваше и за прилагане на нестандартно подравняване беше необходимо да се измислят различни „трикове“. Сега формата и групата могат да бъдат уточнени как нейните елементи да бъдат подравнени вертикално и хоризонтално. Например в изображението по-долу група бутони показва три възможни опции за подравняване: Наляво, ЦентърИ вярно:

На тази снимка бутоните са поставени в правилна група, която се простира хоризонтално. Поставянето на бутоните в група се контролира от свойството група Хоризонтална позицияПодчинени.

Контрол на външното подравняване

Например, имате формуляр, който съдържа полета Подразделение, групи АдресИ Телефон. Предишният механизъм подравняваше полетата на тези групи, както е показано на лявата фигура. Полетата във формуляра бяха подравнени едно спрямо друго и полетата във всяка група бяха подравнени едно спрямо друго.

Сега имате възможност да зададете подравняване от край до край за групите, в резултат на което например всички полета на формуляра ще бъдат еднакво подравнени. Тази опция е показана на дясната снимка.

Освен това можете да управлявате подравняването от край до край за всяка група поотделно. Следователно можете например да деактивирате подравняването от край до край за група Телефон, и тогава формулярът ще изглежда като този, показан на дясната снимка.

Подравняване на елементи и заглавия

Друга нова функция, която се появи, е възможността за контрол на относителната позиция на елементи и заглавия. Както във всички форми, така и в отделни групи. Например, можете да „разтегнете“ заглавия и елементи към различни ръбове на формуляра или обратно, да ги „издърпате“ един към друг, подравнявайки заглавията отдясно и елементите отляво.

Ограничаване на максималната ширина на елементите

Преди, ако кажете на елемент да се разтегне, елементът ще се разтегне доколкото може. Например цял екран. За някои елементи това беше добре (като HTML поле), но за други елементи може да не е толкова добро. Например за числови полета. Защото цифровите данни или бутоните, които контролират полето, се озоваха някъде далеч вдясно.

Сега елементите имат булеви свойства, с които можете да зададете автоматичен режим на разтягане по ширина или височина. В този режим платформата самостоятелно определя до какви граници може да се разтегне полето. Ако автоматичният режим е деактивиран, тогава платформата ще се държи по същия начин както преди. Ако посочите конкретна ширина/височина на полето, това ще се използва. И ако зададете стойност 0, тогава елементът ще се разтегне доколкото е възможно.

Контролиране на разстоянието между елементите

Също така е възможно да се контролира хоризонталното и вертикалното разстояние между елементите. Например на следващата фигура лявата група има увеличено вертикално разстояние, докато дясната група има намалено вертикално разстояние.

Деактивирайте разтягането на формата

Внедрихме още един, нов режим на работа на формата, който забранява вертикалното разтягане на нейните елементи. Този режим ще бъде полезен за формуляри, съдържащи малък брой елементи.

Деактивирайте превъртането на страниците

За формуляри, съдържащи голям брой елементи, ние също леко променихме поведението. Сега вертикалното превъртане не се появява на страниците. Вертикалното превъртане вече може да бъде на самия формуляр или вътре в елементи на формуляра, като например таблица, документ с електронна таблица и т.н. И страницата на формуляра винаги ще бъде в пълна височина. Това трябва да улесни потребителското изживяване, тъй като големият брой скролери във формуляра често могат да бъдат объркващи и объркващи.

Резюме

В тази обзорна статия сме изброили само основните функции, предоставени от новия механизъм за поставяне на елементи във формата. Но не по-малко важно според нас е, че този механизъм съдържа значителен резерв за бъдещо развитие.

На обикновените форми разположението на елементите се рисува изцяло ръчно. За да улесни този процес, платформата предлага няколко механизма:

- подравняване на елемента- осигурява автоматично центриране или „притискане“ на контролите един към друг, или подравняване на размерите на контролите:

- нето- чрез Опции можете да конфигурирате показването на решетката за прецизно ръчно подравняване на елементите:

Правилният отговор е вторият. Това е панел за подравняване и унифициране на размерите на елементите.

Въпрос 10.79 от изпита 1C: Platform Professional.

  1. Нищо няма да се промени
  2. Елементът "Надпис1" ще бъде изместен хоризонтално и дясната му граница ще бъде подравнена с дясната граница на елемента "Надпис2"
  3. Елементът "Inscription2" ще бъде изместен хоризонтално и дясната му граница ще бъде подравнена с дясната граница на елемента "Inscription1"
  4. И двата елемента ще се преместят до линията за подравняване на десния ръб на формуляра

Правилният отговор е вторият. Етикетите ще бъдат подравнени вдясно.

Въпрос 10.82 от изпита 1C: Platform Professional. Какво се случва, когато щракнете върху бутона на командната лента, маркиран на снимката?

  1. Всички надписи ще бъдат еднакви по хоризонтала
  2. Нищо няма да се промени
  3. Етикетите ще се разместят. Вертикалната ос на симетрия на всеки контролен елемент ще съвпада с вертикалната ос на симетрия на формата, т.е. центриране на всяка контрола хоризонтално
  4. Етикетите ще се изместят хоризонтално. Контролите няма да се движат един спрямо друг в рамките на групата, т.е. центриране, така да се каже, на един елемент като цяло
  5. Етикетите ще се изместят вертикално. Контролите няма да се движат един спрямо друг в рамките на групата, т.е. центриране, така да се каже, на един елемент като цяло

Верният отговор е четвърти. Всички избрани контроли ще бъдат центрирани около тяхната обща централна линия.

Въпрос 10.83 от изпита 1C: Platform Professional. Какво се случва, когато щракнете върху бутона на командната лента, маркиран на снимката?

  1. Всички надписи ще бъдат еднакви по вертикала. Контролният елемент "Inscription1" ще бъде взет като проба.
  2. Нищо няма да се промени
  3. Всички надписи ще бъдат еднакви по вертикала. Контролният елемент "Inscription3" ще бъде взет като проба.
  4. Всеки етикет ще бъде центриран вертикално
  5. Ще има равномерно разпределение на надписите във вертикална посока. Контролите "Inscription1" и "Inscription3" ще останат на мястото си, а елементът "Inscription2" ще бъде преместен в желаната посока. При преместване на елемент прилепването към решетката на оформлението не се взема предвид
  6. Ще има равномерно разпределение на надписите във вертикална посока. Контролите "Inscription1" и "Inscription3" ще останат на мястото си, а елементът "Inscription2" ще бъде преместен в желаната посока. Когато преместите елемент, той ще се прикрепи към мрежата за маркиране, ако е зададен режимът за неговото използване

Правилният отговор е първият. Височината на елементите ще бъде стандартизирана

Въпрос 10.86 от изпита 1C: Platform Professional. Какво се случва, ако щракнете върху бутона на командната лента, отменен на снимката?

  1. Всички надписи ще бъдат еднакви по размер вертикално и хоризонтално. Контролният елемент "Inscription1" ще бъде взет като проба.
  2. Всички надписи ще бъдат еднакви по размер вертикално и хоризонтално. Контролният елемент "Inscription3" ще бъде взет като проба.
  3. Нищо няма да се промени
  4. Етикетите ще бъдат автоматично подравнени
  5. Всички етикети ще имат прозрачен фон.

Верният отговор е номер четири, самият бутон се казва „Подравнявай автоматично“

Въпрос 10.90 от изпита 1C: Platform Professional. Деактивирайте режима на подравняване с помощта на линии за подравняване в предварително създадена форма:

  1. Забранено е
  2. Мога. За да направите това, в палитрата със свойства на формуляра трябва да деактивирате свойството „Използване на линии за подравняване“.
  3. Мога. За да направите това, като изберете елемента от главното меню "Инструменти-Опции", в раздела "Формуляр", трябва да деактивирате свойството "Използване на линии за подравняване"
  4. Мога. За да направите това, в палитрата със свойства на формуляра трябва да деактивирате свойството "Използване на линии за подравняване" или, като изберете елемента от главното меню "Инструменти-Опции", в раздела "Формуляр", деактивирайте свойството "Използване на линии за подравняване".

Правилният отговор е вторият. Линиите за подравняване (маркирани със стрелка) са деактивирани от съответното свойство на формуляра:

Въпрос 10.92 от изпита 1C: Platform Professional. При подравняване на елементи на формуляр може да се покаже решетка на оформление:

  1. Непрекъснати линии
  2. Шахматни точки
  3. Точки, разположени в пресечната точка на линиите за маркиране
  4. Отговор 1 и 2 са верни
  5. Отговор 2 и 3 са верни
  6. Отговори 1, 2 и 3 са верни

Верният отговор е номер пет. Местоположението на точките се контролира от опцията Шахматна дъска в системните параметри (вижте екранната снимка в публикацията).

Въпрос 10.95 от изпита 1C: Platform Professional.

  1. Специален маркер за подравняване, който показва отместването на контролите. Избраният контролен елемент се предлага да се премести наляво
  2. Специален маркер за подравняване, който показва отместването на контролите. Избраният контролен елемент се предлага да бъде преместен надолу
  3. Специален маркер за подравняване, показващ наслагването на контролите. Избраният контролен елемент се предлага да се премести наляво
  4. Специален маркер за подравняване, показващ наслагването на контролите. Избраният контролен елемент се предлага да бъде преместен надолу

Правилният отговор е първият. Долното поле е изместено надясно спрямо горното, така че се предлага да се премести наляво.

Въпрос 10.96 от изпита 1C: Platform Professional. Мога ли да използвам линии за подравняване, за да променя размера и да премествам контролите на формуляра?

  1. Забранено е
  2. Да, ако контролите са прикрепени към тези линии
  3. Възможно е, ако контролите са прикрепени към тези линии, но само ги преместете
  4. Възможно е, ако контролите са прикрепени към тези редове, но само преоразмеряване
  5. Можете, винаги

Правилният отговор е вторият. Елементите, прикрепени към една и съща линия, могат да се местят заедно.

Въпрос 10.97 от изпита 1C: Platform Professional. На фигурата червеният кръг отбелязва:

  1. Специален маркер за подравняване, който показва отместването на контролите. Избраният контролен елемент се предлага да се премести наляво и нагоре
  2. Специален маркер за подравняване, който показва отместването на контролите. Избраният контролен елемент може да се мести надясно и надолу
  3. Специален маркер за подравняване, показващ наслагването на контролите. Избраният контролен елемент се предлага да се премести наляво и нагоре
  4. Специален маркер за подравняване, показващ наслагването на контролите. Избраният контролен елемент може да се мести надясно и надолу

Верният отговор е четвърти. Където сочат стрелките, трябва да се преместите там.

Въпрос 10.98 от изпита 1C: Platform Professional. На фигурата червеният кръг отбелязва:


Въпрос 10.110 от изпита 1C: Platform Professional. Как мога да използвам бутона на командната лента, показан на фигурата, за да подравня и трите етикета вдясно?

  1. Първо изберете контролата „Inscription1“, като щракнете върху нея с левия бутон на мишката и едновременно с това натиснете клавиша. След това натиснете посочения бутон
  2. Просто щракнете върху посочения бутон
  3. С помощта на този бутон не можете да подравните етикетите, тъй като те принадлежат към различни панели
Верният отговор е трети. Подравняването работи в рамките на един панел.

Въпрос 10.115 от изпита 1C: Platform Professional. За да покажете решетка на оформление в съществуваща форма, е достатъчно:

  1. В палитрата със свойства на формуляра задайте свойството "Използване на мрежата".
  2. Като изберете елемента от главното меню "Инструменти-Опции", в раздела "Формуляр", задайте флага "Използване на мрежата".
  3. Като изберете елемента от главното меню "Инструменти-Опции", в раздела "Формуляр", задайте флага "Показване на решетка"
  4. Като изберете елемента от главното меню "Инструменти-Опции", в раздела "Формуляр", задайте флага "Показване на мрежа" и след това в палитрата със свойства на формуляра задайте свойството "Използване на мрежата".
  5. Като изберете елемента от главното меню "Инструменти-Опции", в раздела "Формуляр", задайте флаговете "Показване на мрежата" и "Използване на мрежата".

Верният отговор е четвърти; за формата можете също да посочите опцията за показване или не.

И обект за прехвърляне на данни към структуриране на код, контролирана форма в средата 1C 8.2.

Въведение

Нека започнем с кратко описание на концепцията за „управлявана форма“ и свързаните с нея концепции на платформата 1C. Ценителите на платформата може да пропуснат този раздел.

През 2008 г. стана достъпна нова версия на платформата 1C: Enterprise 8.2 (наричана по-долу управлявано приложение), което напълно променя целия слой на работа с интерфейса. Това включва командния интерфейс, формулярите и прозоречната система. В същото време се променя не само моделът за разработване на потребителския интерфейс в конфигурацията, но и се предлага нова архитектура за разделяне на функционалността между клиентското приложение и сървъра.
Управляваното приложение поддържа следните типове клиенти:

  • Дебел клиент (нормален и управляван режим на стартиране)
  • Тънък клиент
  • Уеб клиент
Управляваното приложение използва формуляри, изградени по нова технология. Те се наричат Управлявани формуляри. За да се улесни преходът, се поддържат и предишни формуляри (т.нар. Редовни формуляри), но тяхната функционалност не е развита и те са достъпни само в режим на стартиране на дебел клиент.
Основните разлики на управляваните формуляри за разработчика:
  • Декларативно, а не „пиксел по пиксел“ описание на структурата. Конкретното разполагане на елементи се извършва автоматично от системата при показване на формата.
  • Цялата функционалност на формата е описана като подробностиИ екипи. Детайлите са данните, с които работи формата, а командите са действията, които трябва да бъдат извършени.
  • Формата работи както на сървъра, така и на клиента.
  • В контекста на клиента почти всички типове приложения са недостъпни и съответно е невъзможно да се променят данните в информационната база.
  • За всеки метод или променлива на формата тя трябва да бъде посочена директива за компилация, дефиниране на местоположението на изпълнение (клиент или сървър) и достъп до контекста на формата.
Нека да изброим директивите за компилиране на методи на формуляр:
  • &На клиент
  • &На сървъра
  • &На сървъра без контекст
  • &На клиент на сървър без контекст
Нека илюстрираме горното. Екранната снимка показва пример на управлявана форма и нейния модул в режим на разработка. Намерете декларативното описание, реквизитите, директивите за компилация и т.н.

Всички по-нататъшни дискусии ще бъдат за дясната страна на илюстрацията, за това как да структурирате кода на модула и какви принципи ще ви позволят да реализирате ефективно взаимодействие клиент-сървър.

Нека дефинираме проблема

Изминаха няколко години, откакто новата версия на платформата 1C се използва активно и много решения (конфигурации) бяха пуснати както от 1C, така и от многобройните му партньори.
През това време разработчиците разработиха ли общо разбиране за принципите на взаимодействие клиент-сървър при създаване на формуляри и промени ли се подходът за внедряване на софтуерни модули в новите архитектурни реалности?

Нека да разгледаме структурата на кода (модула на формуляра) в няколко форми на една и съща стандартна конфигурация и да се опитаме да намерим модели.
Под структура имаме предвид секции от код (най-често това са блокове за коментари), разпределени от разработчика за групови методи и директиви за компилация за тези методи.
Пример 1:
Секция от манипулатори на събития Метод - на клиента Метод - на сървъра Метод - на клиента Секция на сервизни процедури и функции Функции за контрол на спомагателния вход
Пример 2:
Сервизни процедури и функции Платежни документи Стойности Обработчици на събития
Пример 3:
Сервизни процедури на сървъра Сервизни процедури на клиента Сервизни процедури на сървъра без контекст Обработчици на заглавни събития Обработчици на командни събития
Пример 4:
Процедури с общо предназначение Обработчици на събития на формуляри Процедури на подсистемата „информация за контакт“.
По същество структурата на кода липсва, или меко казано, тя е подобна на това, което беше във Forms 8.1:

  • Неинформативни думи „Общи, Сервизни, Помощни“.
  • Плахи опити за разделяне на клиентски и сървърни методи.
  • Методите често се групират по елементи на интерфейса „Работа с табличната част Продукти, Информация за контакт“.
  • Произволно подреждане на методи и кодови групи. Например манипулаторите на събития може да са в горната част на една форма, на дъното в друга, изобщо да не са маркирани в трета и т.н.
  • И нека не забравяме, че всичко това е в една конфигурация.
  • Да, има конфигурации, в които думите „Общи, Сервизни, Помощни“ са винаги на едни и същи места, но...
Защо ви е необходима структура на кода?
  • Опростяване на поддръжката.
  • Опростете ученето.
  • Записване на общи/важни/успешни принципи.
  • ... твоят вариант
Защо съществуващият стандарт за разработка от 1C не помага?
Нека да разгледаме принципите, публикувани на ITS дискове и в различни „Ръководства за разработчици...“, които се препоръчват при писане на управлявана форма.
  • Минимизирайте броя на обажданията към сървъра.
  • Максимално изчисление на сървъра.
  • Неконтекстуалните сървърни повиквания са по-бързи от контекстните.
  • Програма с мисъл за комуникацията клиент-сървър.
  • и така нататък.
Това са лозунги, които са абсолютно верни, но как да ги реализираме? Как да минимизирам броя на обажданията, какво означава да програмираме в режим клиент-сървър?

Дизайнерски модели или мъдрост на поколенията

Взаимодействието клиент-сървър се използва в различни софтуерни технологии от десетилетия. Отговорът на въпросите, изложени в предишния раздел, е известен отдавна и е обобщен в два основни принципа.
  • Дистанционна фасада(наричан по-нататък интерфейс за отдалечен достъп)
  • Обект за прехвърляне на данни(наричан по-нататък Обект на трансфер на данни)
Слово от Мартин Фаулър, неговото описание на тези принципи:
  • Всеки обект, потенциално предназначен за отдалечен достъп, трябва да има интерфейс с ниска детайлност, което ще минимизира броя на обажданията, необходими за извършване на конкретна процедура. ... Вместо да изисквате фактура и всички нейни елементи поотделно, трябва да прочетете и актуализирате всички елементи на фактурата в една заявка. Това засяга цялата структура на обекта... Запомнете: интерфейс за отдалечен достъп не съдържа домейн логика.
  • ...ако бях грижовна майка, определено щях да кажа на детето си: „Никога не пишете обекти за пренос на данни!“ В повечето случаи обектите за пренос на данни не са нищо повече от раздут набор от полета... Ценността на това отвратително чудовище се крие единствено във възможността предаване на множество части от информация по мрежата в едно повикване- техника, която е от голямо значение за разпределените системи.
Примери за шаблони в платформата 1C
Интерфейсът за програмиране на приложения, достъпен за разработчика при разработване на управлявана форма, съдържа много примери за тези принципи.
Например методът OpenForm(), типичен „груб“ интерфейс.
OpeningParameters = Нова структура ("Параметър1, Параметър2, Параметър3", Стойност1, Стойност2, Стойност3); Form = OpenForm(FormName, OpeningParameters);
Сравнете със стила, приет във v8.1.
Form = GetForm(FormName); Форма.Параметър1 = Стойност1; Форма.Параметър2 = Стойност2; Form.Open();

В контекста на управлявана форма има много „обекти за прехвърляне на данни“. Можете да изберете системенИ дефиниран от разработчика.
Системните моделират обект на приложение на клиента под формата на един или повече елементи от данни на формуляр. Невъзможно е да ги създадете извън връзката с детайлите на формуляра.

  • DataFormsStructure
  • DataFormsCollection
  • DataFormStructureWithCollection
  • DataShapesTree
Преобразуването на обекти за пренос на системни данни в типове приложения и обратно се извършва чрез следните методи:
  • ValueInFormData()
  • FormDataValue()
  • CopyFormData()
  • ValueInFormAttributes()
  • FormAttributesValue()
Често изричното преобразуване се използва при адаптиране на съществуващо решение. Методите може да очакват (използват функции) входни параметри, като например ValueTable вместо FormDataCollection, или методът е дефиниран в контекста на обект на приложение и е станал недостъпен за директно извикване от формуляра.
Пример 1C v8.1:
// на клиента в контекста на формуляра FillUserCache(DepartmentLink)
Пример 1C v8.2:
// на сървъра в контекста на формата ProcessingObject = Form AttributesValue("Object"); ProcessingObject.FillUserCache(DepartmentRef); ValueВFormAttributes(ProcessingObject, "Object");

Обектите за пренос на данни, чиято структура се определя от разработчика, са малко подмножество от типовете, налични както на клиента, така и на сървъра. Най-често като параметри и резултати от методите на „огрубения“ интерфейс се използват следните:

  • Примитивни типове (низ, число, булев)
  • Структура
  • Кореспонденция
  • Масив
  • Връзки към обекти на приложението (уникален идентификатор и текстово представяне)
Пример: методът приема списък с поръчки за промяна на статуса и връща описание на грешките на клиента.
Функция &OnServerWithoutContext ServerChangeOrderStatus(Orders, NewStatus) Грешки = Ново съвпадение(); // [поръчка][описание на грешка] За всяка поръчка от цикъл на поръчки StartTransaction(); Опитайте DocOb = Order.GetObject(); …. други действия, възможни не само с поръчката... Изключение CancelTransaction(); Errors.Insert(Поръчка,Описание на грешка()); EndAttempt; EndCycle; Грешка при връщане; EndFunction // ServerChangeOrderStatus()

Структуриране на кода

Основните цели, които модулът за управлявана форма трябва да отразява и подходи към решението.
  • Ясно разделяне на клиентски и сървърен код.Нека не забравяме, че в момента на изпълнение това са два взаимодействащи процеса, всеки от които има значително различна налична функционалност.
  • Ясна идентификация на интерфейса за отдалечен достъп, кои сървърни методи могат да бъдат извикани от клиента и кои не? Имената на методите за отдалечен интерфейс започват с префикса "Сървър". Това ви позволява незабавно да видите прехвърлянето на контрола към сървъра, докато четете кода, и опростява използването на контекстна помощ. Обърнете внимание, че официалната препоръка (ITS) предлага именуване на методи с постфикси, например ChangeOrderStatusOnServer(). Повтаряме обаче, че не всички сървърни методи могат да бъдат извикани от клиента и следователно логическата достъпност е по-важна, отколкото местоположението на компилация. Следователно с префикса „Сървър“ маркираме само достъпни за клиента методи; нека извикаме примерния метод ServerChangeOrderStatus().
  • Четивност.Въпрос на вкус, приемаме поръчката, когато модулът започне с процедурите за създаване на формуляр на сървъра и методите за отдалечен достъп.
  • Поддържаемост.Трябва да има ясно място за добавяне на нов код. Важен момент е, че автоматично създадените от конфигуратора шаблони на методите се добавят в края на модула. Тъй като манипулаторите на събития за елементи на формуляри най-често се създават автоматично, съответният блок се намира последен, за да не се влачи всеки манипулатор на друго място в модула.
По-долу е представена основната структура на модула, който изпълнява изброените цели.
  • Графична опция – ясно показва основния поток на изпълнение.
  • Текстовата опция е пример за дизайн на шаблон за бързо вмъкване на структура в нов модул на формуляр.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор=""Дата=""/> // <Описание> // // /////////////////////////////////////////////// // /////////////////////////// // ПРОМЕНЛИВИ НА МОДУЛА //////////////// // ///////////////////////////////////////////// //// ////////// // НА СЪРВЪРА //******** СЪБИТИЯ НА СЪРВЪРА ******* &На сървърната процедура при създаване на сървъра (Грешка, Стандартна обработка) / /Вмъкване на съдържанието на манипулатора Край на процедурата //******** ИНТЕРФЕЙС ЗА ОТДАЛЕЧЕН ДОСТЪП ******* //******* БИЗНЕС ЛОГИКА НА СЪРВЪРА ******* ///////// ///////////////////////////////////////// /////// ///////////////////// // ОБЩИ МЕТОДИ НА КЛИЕНТ И СЪРВЪР //////////////// /////// //////////////////////////////////////////// ///// //////// // НА КЛИЕНТА //******** БИЗНЕС ЛОГИКА НА КЛИЕНТА ******* //******* ЕКИП * ****** //******** КЛИЕНТСКИ СЪБИТИЯ ******* //////////////////////////// ///// ////////////////////////////////////////////// // / / ОСНОВНИ ПРОГРАМНИ ОПЕРАТОРИ

Свързани въпроси
В заключение ще очертаем няколко области, върху които е полезно да помислите, когато програмирате взаимодействието клиент-сървър.
  • Опции за внедряване на интерфейс за отдалечен достъп. Асинхронност, ниво на детайлност...
  • Кеширане. 1C направи неуспешно архитектурно решение, въвеждайки кеширане само на нивото на извикващи методи на общи модули и не предоставяйки възможности за контрол (време за релевантност, нулиране при поискване).
  • Неявни сървърни повиквания. Не забравяйте за технологичните характеристики; много „безобидни“ операции на клиента провокират платформата да се свърже със сървъра.