Управлявани форми 1s 8.3. Под капака на управляваните форми

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

Приложимост

Статията разглежда интерфейса „Такси“ на конфигурацията, разработена на платформата 1C 8.3.5.1098. Допълненията към текущите версии на платформата (8.3.11) са дадени в заключението. Следователно цялата предоставена информация е уместна.

Ново в управляваните форми в 1C:Enterprise 8.3

Разработчиците на платформата 1C:Enterprise 8.3 отново са работили усилено, за да улеснят потребителите да работят с управлявани формуляри.

Линеен вход

Преди това в полетата за въвеждане при въвеждане на начални символи от клавиатурата системата търсеше подходящи елементи.

Често обаче потребителите трябва да търсят не само по първите знаци на името, но и на произволно място в името.

В конфигуратора за референтни обекти с метаданни, за конфигуриране на въвеждане по ред, беше създаден отделен раздел „Поле за въвеждане“:

Той представя следните опции за генериране на списък за избор при въвеждане по ред:

• използване на пълнотекстово търсене;
• търсене по срещане на подниз или по начало на низ;
• извършвайте търсения директно или във фонов режим.

В свойството “Метод за търсене на низ при въвеждане по подниз” можете да изберете дали да търсите само по първите символи на низа или в произволна част от него.

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

И не само от първите букви на името, но и от появата на въведения ред:

Естествено, използването на търсене на която и да е част от низ може да доведе до влошаване на производителността на системата, особено при голямо количество данни.

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

Ако е зададена съответната настройка, може да се използва пълнотекстово търсене при въвеждане на данни в полето за въвеждане.

По време на пълнотекстово търсене ще бъдат намерени както цели думи, така и низове, в които въведените знаци са част от цели думи (използва се операторът * за пълнотекстово търсене).

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

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

Нека си спомним, че в платформа 8.3 стана възможно да се предефинира представянето на референтен тип данни, като се използват процедурите ViewGettingProcessing и ViewGettingFieldsProcessing в модула за управление на обекти.

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

Горните манипулатори не засягат представянето на стойностите в списъка за избор - списъкът отразява основното представяне на обекта.

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

За да увеличите, щракнете върху изображението.

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

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

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

Например, използване на манипулатори на събития AutoSelect и EndTextInput за конкретно поле за въвеждане или използване на манипулатор на събития SelectionDataProcessingSelectionProcessing в модула за управление на обекти.

За тази цел в тези процедури има параметър с име Structure type Parameters, чиито свойства съдържат метода за търсене на низ, режима за получаване на данни за избор и настройка на използването на данни за избор.

За да увеличите, щракнете върху изображението.

Падащ списък за полето за въвеждане

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

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

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

За да увеличите, щракнете върху изображението.

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

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

Също така в списъка на полето за въвеждане има команда „Създаване на нов обект“. Това ще отвори новия формуляр на елемента.

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

Типичен шаблон за използване на командата „Създаване на нов елемент“ изглежда така. Потребителят въвежда името на желания елемент в полето за въвеждане.

Ако системата не намери такъв елемент в базата данни, ще се покаже съобщение за това. След натискане на бутона в списъка на екрана ще се отвори нова форма на елемент с попълнено име.

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

Запазване на настройките на динамичния списък

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

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

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

За да увеличите, щракнете върху изображението.

Настройката на списъци в потребителски режим се извиква чрез съответния елемент от менюто:

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

За да увеличите, щракнете върху изображението.

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

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

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

С тази настройка формулярът ще има полета под формата на „бързи селекции“.

За да увеличите, щракнете върху изображението.

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

Динамичният режим на преглед на списъка (списък, дърво, йерархичен списък) се запазва заедно с настройките на елементите на формата.

За един списък потребителят може да запише няколко различни настройки.

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

За да увеличите, щракнете върху изображението.

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

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

За да увеличите, щракнете върху изображението.

В персонализиран режим този бутон ще изглежда така:

За да увеличите, щракнете върху изображението.

защото Материалът в статията е описан за платформа 8.3.5, след което ще го актуализираме.

• Преди версия 8.3.7 въвеждането на низ не беше достатъчно бързо, така че в тази версия структурата на данните на индекса за търсене в пълен текст беше променена, което доведе до повишена скорост при стартиране на системата на места, където се използва този механизъм. Обърнете внимание, че новият формат за търсене в пълен текст се използва, когато режимът на съвместимост е зададен на „Не използвай“. В режим на съвместимост с версия 8.3.6 поведението не се е променило. Също така имайте предвид, че в следващата версия на платформата 1C (8.3.8) механизмът за въвеждане по ред и при използване на реда за търсене в динамичен списък също беше подобрен и сега осигурява търсене на данни, които все още не са включени в пълнотекстово търсене. Това поведение не е наблюдавано преди.
• Падащият списък с полета за въвеждане на управляван формуляр също получи някои подобрения. Във версия 8.3.8 той започна автоматично да коригира ширината си спрямо ширината на данните, показани в него, плюс клавишите У домаИ Крайзапочна да се обработва директно в полето за въвеждане. Тези подобрения улесняват използването на падащото поле за въвеждане.
• Механизмът за запазване на настройките на динамичния списък също е подобрен и във версия 8.3.6 свойствата на разширението на таблицата на формуляра за динамичния списък Период и Показване вече се съхраняват в същите секции като другите настройки на динамичния списък, което значително опростява работата на програмиста с тях. Те вече са налични в манипулатора на управлявани формуляри WhenLoadingUserSettingsOnServer(), която не е съществувала преди.

Тук ще завършим нашето запознаване с управляваните форми в интерфейса на Такси, но в следващата статия ще се запознаем с новите функции, въведени от платформата 1C:Enterprise версия 8.3.

Всички знаем, че компанията 1C имаше много различни версии на платформата 1C; сега ще се интересуваме от една от най-новите версии към момента на писане на тази статия, това са версии 1C 8.2 и 1C 8.3. Ако ви се е налагало да работите и в двете версии, тогава най-вероятно забеляза разлики в интерфейсите на тези версии, за потребителите те се различават само по външен вид. По същество избор редовно или управлявано приложениеказва на системата кои форми да покаже, за да стартира, редовно или контролирано, както и кой клиент на приложението ще се използва по подразбиране, дебел или тънък. За по-подробна информация относно клиентите прочетете статията „Какви са дебелите и тънките клиенти в 1C, както и техните разлики“.

Редовно 1C приложение (обикновени форми, обикновен интерфейс, версия 1C 8.2)

В 1C 8.2 е възможно да се работи само с редовни форми, в режим на редовно приложение. Изображението по-долу показва базата данни в режим на работа „обикновено 1C приложение“ (обикновени формуляри).

Управлявано 1C приложение (управлявани формуляри, управляван интерфейс, версия 1C 8.3)

На платформата 1C 8.3 можем да работим както с обикновени форми (в режим на съвместимост), така и с управлявани. освен това управляваните форми имат два вида дисплей, това е стандартно и такси. Пример за конфигурация 1C 8.3 със стандартни управлявани форми е показан по-долу, а след него е показан интерфейсът „Такси“.

Каква е разликата между обикновено и управлявано 1C приложение?

Както вече разбрахме обикновено приложение и управлявано приложение са тези видове стартиране на програма 1C. Освен това, в зависимост от стойността на типа стартиране на 1C ( редовно или управлявано приложение), конкретен интерфейс ще бъде зареден по подразбиране ( редовни или управлявани форми), следователно има толкова много синоними за това понятие. Бихме искали да отбележим, че разликите в интерфейсите са доста значителни; управляваният интерфейс е напълно преработен. По принцип това са всички разлики, които обикновените потребители на програмата 1C виждат. Що се отнася до програмистите, управляваният интерфейс изисква писане на модифициран код, тъй като разработката вече се извършва в 1C 8.3, а не в 1C 8.2, оттук и всички произтичащи от това последствия. Кодът също трябва да бъде разделен на клиент и сървър; това се посочва с помощта на съответните директиви в конфигуратора.

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

Дори съжалявах, че 1C не изостави напълно конвенционалните форми поради факта, че се използват в десктоп режим. В края на краищата би било възможно да се направи възможно прецизното позициониране на пикселите в UV и обикновените форми ще изчезнат с времето. И така трябва да изразходвате енергията си за познаване на старата функционалност.

И така, разбира се, UV е много по-бърз от конвенционалните, защото... работят по тристепенна схема между клиент и сървър.

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

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

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

Модалности, събитийност и заключване на интерфейса

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

Представете си изненадата ми, когато в един от примерите учителят накара формата да се отвори с опцията „Блокиране на целия интерфейс“, т.е. по същество модален.

Бях сигурен, че тази модалност е била изоставена.

Разбирането не дойде веднага.

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

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

Тези. Платформата 1C се отърва от рудимента на замразяване на изпълнението на код и премина към изцяло базирано на събития управление на форми.

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

Мини-конструкторите се появиха в 1C - рефакторинг. Това улеснява писането на манипулатори на предупреждения за асинхронна работа, без да се налага да ги пишете ръчно.

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

Нови функции на интерфейса

Меню

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

По едно време, обратно в 8.1, направих система от менюта под формата на йерархична директория, прикрепена отляво, където видимостта на всеки елемент се определяше от правата за достъп на потребителя, за когото беше показано менюто.

Доколкото разбирам, 1C сметна за погрешно, че обектът на приложението Interface не се използва, и реши да пусне нова, усъвършенствана алтернатива за него.

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

Като цяло се появиха нови начини за организиране на менюта, според мен не са много сполучливи, но няма алтернатива и се използват в стандартните.

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

Той ми отговори, че системата 1C се развива в посока повишаване на комфорта и скоростта на работа на потребителя. Според мен такива грандиозни промени в системата на менюто не си заслужават.

Ред на преминаване

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

Работно пространство и вложени форми

Има само една работна зона. Следователно трябва да вкарате формулярите на почти всички потребители в него и да определите тяхната видимост по права. Всичко това трябва да доведе до хаос в големите конфигурации.

Би било много по-лесно да го създадете с помощта на програмен код или да използвате механизма на вложената форма.

Какво никога не е било внедрено в 8.2-8.3

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

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

Функционални опции и видимост на елементите

По едно време RLSса създадени, за да показват на потребителите само отделни записи в таблици.

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

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

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

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

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

Интерфейс 8.2 и Такси интерфейс

Интерфейсът 8.2 и интерфейсът за такси са съвместими, т.е. не се появиха нови обекти. Конфигурацията може да работи в 8.2 или Taxi, можете да позволите на потребителя да превключва между тези интерфейси.

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

Не е ясно защо беше необходимо да се поеме толкова объркващ път, ако в крайна сметка основната система от менюта в 8.1 беше дори по-икономична при използване на пространството на екрана?

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

Между другото, в 8.2 не можете да промените палитрата, това е като телефонна карта на платформата 1C. По същия начин системата за организиране на менюто под формата на 8.2 или Taxi привиква потребителите към определен стандарт. Практиката обаче показва, че потребителят научава отново новата система от менюта почти моментално. Много по-трудно е да промените уменията си за работа с документи и отчети.

Следователно целият този шум и противоречия около системата от менюта не ми е много ясен - това не е основното в платформата 1C, нека го оставим на съвестта на архитектите на платформата и мениджърите, които им показват посоката на развитие.

Неразвита идеология

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

Например подсистемите се използват както за разделяне на конфигурационни обекти на блокове, така и за организиране на функционални менюта (нова алтернатива на обикновеното меню на приложението). Въпреки че би било логично да се създаде отделен обект на приложение, наречен „Функционално меню“.

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

Съмнения относно ефективността

Някои 1C подходи къмизползваемостпораждат съмнения.

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

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

Възможност за запазване на настройките

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

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

Други въпроси

Какво представляват управляваните формуляри?

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

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

И сървърът е в директна и бърза връзка с базата данни.

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

Точно така работят управляваните форми. С подходящи умения постоянният достъп до сървъра не е труден.

Такава организация е по-ефективна от свързването към сървър чрез отдалечен достъп, освен това е възможна работа директно през браузър, т.е. на всяка платформа - Windows, Linux, Android , Mac OS .

Бележки за 1C в насипно състояние

Ето бележките, които написах за себе си, те съдържат ценни знания:

1. В прозореца за стартиране на 1C вече не се регистрират информационни бази, а входни точки. Тези. една база данни може да присъства няколко пъти, но е регистрирана за различни потребители и различни инструменти за работа - браузър, тънък/дебел клиент, вход на администратор.
2. Появи се ключ за администратора, който деактивира ролевия контрол. Можете да влезете в Enterprise по този начин само ако имате администраторски права за конфигурацията.
3. Общи подробности - не ги бъркайте с общи подробности в 1C7; в 82 те се използват за разделяне на достъпа в интерфейса.
4. Често използвах минималната височина на списъка във формата, за да се отърва от ненужната лента за превъртане на формата.
5. Не трябва да съхранявате картини в атрибути на директория, това води до спад в производителността на директорията, трябва да използвате информационния регистър.
6. В сървърните процедури, когато подавате параметри, трябва да използвате СТОЙНОСТ, така че параметърът да не се предава обратно на сървъра.
7. Нови функцииPageStartsWithИ PageEndsOn, вероятно други, от платформа 8.3.6.
8. В 1s 8.2 се появи привилегирован режим, т.е. Можете да деактивирате контрола на правата за достъп на ниво роля в секции на кода.
9. Елементите на формуляра на списъка, таблицата със стойности и дървото на стойностите се различават по това, че списъкът на сървъра и клиента има едно и също представяне и се създават специални обекти за таблицата и дървото и те трябва да бъдат преобразувани на сървъра .
10. Бях доволен, че учителят обича да назовава обектите в единствено число и да назовава модулите с долна черта, така че тези модули да са първи по ред в контекстната подсказка.

За живота и около 1C

Учителят каза:

1. Разработката трябва да се извършва от интерфейса.
   Моето мнение : Твърдението е съмнително, т.к Познанията и опитът в използването на архитектурата на платформата ви позволяват незабавно да започнете с обектите на приложението и да изградите интерфейса по-късно.
2. Мениджърът не въвежда данни, а само разглежда справки. И не управлява въвеждането на данни в 1C, а по телефона и чрез секретаря. Следователно мениджърът се нуждае само от браузър, а полетата за въвеждане са необходими само за филтриране на данни.
   Моето мнение : Да, това изглежда е вярно.
3. Критикува BSP (Стандартна подсистемна библиотека). В смисъл, че е невъзможно и много трудно да се изберат необходимите модули от него.
   Моето мнение : Защото Дори БСП не можеше да се раздели на модули, то УПП не може да се раздели на модули УТ, ЗУП, БП, Производство. И тук не е виновна платформата, а неправилната методология за писане на стандартните - не се спазва модулността. Един и същ Navisionотдавна е в състояние първо да продаде счетоводство на клиент, а след това да закупи търговия, производство и заплати, ако е необходимо, без да пренаписва кода и да преминава към нова програма.
4. Стандартните станаха много сложни и трудни за промяна. Отново не заради сложността на платформата, а заради неправилната организация на стандартните. В този случай се губи основният принцип - бърза и икономична поддръжка и модификация на стандартните конфигурации при необходимост.
5. Беше демонстриран вариант на подаване на поръчка, когато в работната зона отляво има артикул, а отдясно списък с поръчки. Можете да поставите количеството срещу артикула, след което го плъзнете в списъка с поръчки и се формира поръчка. Предимството е, че таблицата с поръчки не е блокирана за създаване на нова поръчка.
   Моето мнение : Предимството е пресилено - все пак потребителите са по-свикнали да виждат избрания продукт в табличната част, те могат да запазят тази поръчка като чернова или да копират поръчката от шаблона. Като цяло документите не са измислени напразно.
6. Обяснява разликата между секциите „Основни“, „Важни“, „Отидете на“, „Вижте също“.
   Моето мнение : Лично аз го разбрах бегло, което означава, че повечето никога няма да разберат тези нюанси, вградени в платформатаизползваемоств такси. Следователно интерфейсите ще изглеждат както преди, както потребителите, така и програмистите на 1C вече са свикнали.
7. В клетка на таблично поле във формуляр, чийто източник е потребителска заявка, не можете да въвеждате данни, както бихте направили в поле за въвеждане. Това се прави в интересизползваемосттака че потребителят да се фокусира върху въвеждането на данни в отделен прозорец.
   Моето мнение : Дадох пример с въвеждане в таблични части, където има такова поле, не ми е ясен смисълът на забраната.
8. Разводите възникват от сравняване на съпруга с други хора. По-малко сравнения - по-силен брак.
9. По-лесно е да научите чужди езици, когато изучавате няколко от тях наведнъж;
10. Невъзможно е да изучавате чужди езици, ако свържете чужда дума с дума на родния си език, трябва да я свържете с изображение. Веригата чужда дума - образ е по-къса от веригата чужда дума - родна дума - образ. В последния случай няма да е възможно да мислите на чужд език.

Заключение

Изказвам своята благодарност на учителя.

Посещението на този курс ме освободи от предразсъдъците относно управляваните форми; ясно разбрах нюансите на модалността, разликите между интерфейсите 8.2 и Taxi.

Сега контролираните форми не ме плашат, а напротив, привличат ме да ги познавам.

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

Не може да бъде по-тънък. Сега клиентското приложение не изпълнява заявки към базата данни (това е въпрос на сървъра). Клиентското приложение просто показва интерфейса и данните.

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

Взаимодействие клиент-сървър

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

Липса на контекст (състояние) на сървъра

Сървърът 1C работи на принципа „без състояние“. Това означава, че сървърът отговаря само на заявки и не съхранява нищо в интервала между две заявки (има временно съхранение за тези цели).

FormDataValue, FormDataCollection, FormData...

Свързахме се със сървъра, той направи всичко за нас, изтри данните и забрави, че сме дошли. Всички обекти с име "FormData" + "whatever" ще ни помогнат да запазим данните си между две извиквания на сървъра.

Временно съхранение

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

За да работите с временно хранилище, използвайте методите PlaceInTemporaryStorage() Синтаксис: PlaceInTemporaryStorage(<Данные>, <Адрес>) Описание: Записва сериализиращата се стойност във временно хранилище. Наличност: Тънък клиент, уеб клиент, сървър, дебел клиент, външна връзка, мобилно приложение (клиент), мобилно приложение (сървър). Извикването на метод прави повикване към сървъра.<Адрес>(по избор) Тип: UniqueIdentifier; Линия. Уникален идентификатор на формата, в чието временно хранилище да бъдат поставени данните и върнат нов адрес. Или адресът във временното хранилище, където трябва да бъдат поставени данните. Адресът трябва да е получен преди това чрез този метод. Ако бъде подаден уникален идентификатор на формуляр или адрес за съхранение, стойността ще бъде изтрита автоматично след затваряне на този формуляр. Ако бъде подаден UniqueIdentifier, който не е уникалният идентификатор на формуляра, стойността ще бъде изтрита след края на потребителската сесия. Ако параметърът не е указан, поставената стойност ще бъде премахната след следващата заявка на сървъра от общ модул, по време на контекстно и неконтекстно извикване на сървър от формуляр, по време на извикване на сървър от команден модул или когато формуляр е получени. Забележка: Временното хранилище, създадено в една сесия, не е достъпно от друга сесия. Изключение е възможността за прехвърляне на данни от фоново задание към сесията, която е инициирало фоновото задание, като се използва временно хранилище. За да направите това, трябва да поставите празна стойност във временно хранилище в родителската сесия, като подадете идентификатора на формуляра. След това предайте получения адрес на фоновото задание чрез параметрите на фоновото задание. Освен това, ако този адрес се използва в параметъра<Адрес>, тогава резултатът ще бъде копиран в сесията, от която е стартирано фоновото задание. Данните, поставени във временно хранилище във фоново задание, няма да бъдат достъпни от родителската сесия, докато фоновото задание не завърши. и GetFromTemporaryStorage() Синтаксис: GetFromTemporaryStorage(<Адрес>) Описание: Извлича стойност от временно хранилище. Наличност: Тънък клиент, уеб клиент, сървър, дебел клиент, външна връзка, мобилно приложение (клиент), мобилно приложение (сървър). Извикването на метод прави повикване към сървъра. Забележка: Резултатът от изпълнението не се кешира; сървърът се извиква при всяко извикване на метода.

Код на сървъра за повикване

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

Предназначение на модулните флагове

• Флагът показва къде ще бъде компилиран кодът на модула (на сървъра, на клиента, във външната връзка)
• Ако един модул е ​​компилиран на няколко места, тогава той ще бъде видим само според флаговете
• Прехвърлянето на изпълнение на код е възможно само ако няма извикан модул в текущия контекст на изпълнение, но той съществува на друго място (ако модулът е само на сървъра, но не и на клиента, тогава ще бъде направено повикване към сървъра)

Флаг "Извикване на сървъра".

Започвайки с платформата 1C:Enterprise 8.2, беше добавен флагът „извикване на сървъра“. Което само помага да се „уредят” условията за преминаване към друга машина. Ако присвоите този флаг на модул, тогава модулът ще бъде видим от клиента; ако не, тогава опитът да го извикате от клиента ще доведе до грешка. Кодът на модула няма да се вижда, сякаш изобщо не съществува.

По този начин в обикновен дебел клиент можете да прехвърлите код към сървъра само ако извикате общ модул от клиента, за който:

• Квадратчето за отметка на сървъра е отметнато
• Поставена е отметка в квадратчето „Call server“.
• Всички квадратчета за отметка „клиент“ са изчистени

В тази статия ще се запознаем с основните аспекти на работата с управлявана форма в 1C 8.3. Какво е формуляр и за какво служи? Формата е основният обект, чрез който потребителят взаимодейства с програмата. Тоест, използвайки формуляра, потребителят въвежда информация в програмата и информацията, необходима на потребителя, също се показва на формуляра.

Основната задача на разработчика от всякаква форма (управляван или редовен) е да предостави на потребителя удобен механизъм за взаимодействие с програмата.

Платформата 1C има способността да генерира всякаква форма на обект, но обикновено при разработването на приложни решения програмистите сами конфигурират формулярите.

Въпросите за работа с управлявани форми по-специално и с управлявано приложение като цяло са разгледани подробно в книгата „Основи на разработката в 1C: Такси. Управлявана разработка на приложения в 12 стъпки". Тази книга ще бъде истинска помощ за тези, които тепърва започват да се запознават с разработването на управлявани приложения.

Книгата „Основи на разработката в 1C: Такси“ е идеална за тези, които вече са започнали да програмират и изпитват определени трудности с тази тема, както и за тези, които програмират от дълго време, но никога не са работили с 1C управлявани форми.

1. Без сложни технически термини;
2. Повече от 600 страници практически материали;
3. Всеки пример е придружен от чертеж (екранна снимка);

Промо код за 15% отстъпка - 48PVXHeYu

Понякога изглежда, че изучаването на езика за програмиране в 1C е сложно и трудно. Всъщност програмирането в 1C е лесно. Моите книги ще ви помогнат бързо и лесно да овладеете програмирането в 1C: и „Основи на разработката в 1C: Такси“

Научете програмиране в 1C с помощта на моята книга „Програмиране в 1C в 11 стъпки“

1. Без сложни технически термини.
2. Над 700 страници практически материали.
3. Всяка задача е придружена с рисунка (екранна снимка).
4. Сборник задачи за домашна работа.
5. Книгата е написана на ясен и прост език - за начинаещ.
6. Книгата се изпраща по имейл в PDF формат. Може да се отвори на всяко устройство!

Ако този урок ви е помогнал да разрешите някакъв проблем, харесали сте го или сте го намерили за полезен, тогава можете да подкрепите моя проект, като дарите всяка сума:

Можете да платите ръчно:

Yandex.Money - 410012882996301
Web Money - R955262494655

Присъединете се към моите групи.