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

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

След като прочетете статията, ще научите:

• Каква роля играе подсистемата при оформянето на структурата на менюто?
• Как да създадете раздели на менюто от 1-во и 2-ро ниво?
• Как да персонализирате състава на командите, показвани в разделите на менюто?
• За какво е редакторът на командния интерфейс и как да работите с него?
• Как да конфигурирам командния интерфейс на главния раздел?

Приложимост

Статията разглежда интерфейса „Такси“ на конфигурацията, разработена на платформата 1C 8.3.4.496. Информацията е подходяща за текущи версии на платформата.

Подсистеми. Персонализиране на интерфейса с помощта на подсистеми

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

За да посочите дали даден обект принадлежи към подсистеми в Прозорец за редактиране на обектИма съответен раздел, в който флаговете показват към кои подсистеми принадлежи обектът.

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

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

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

За обект Роляможете да определите съответните права и да посочите, че това Ролямогат да бъдат изградени само от тези обекти, които са включени в избраните Подсистеми.

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

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

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

За съществуващи Подсистемиможете да дефинирате вложени (подчинени). данни Подсистемище формират групи Ленти за навигация.

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

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

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

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

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

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

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

Второ, можете да използвате Прозорец за редактиране на самата подсистема. На отметката Съединениеможете да посочите обектите, включени в това Подсистема.

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

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

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

Когато създава конфигурационен обект по подразбиране, Platform 8.3 не присвоява обекта на никоя подсистема.

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

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

Но грешката не е критична, така че можем да се съгласим с това.

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

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

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

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

За Подсистеми V Прозорец за редактиранеможете да премахнете флага Включете в командния интерфейс.

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

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

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

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

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

Елементите в редактора могат да се местят. В същото време от Ленти за навигация V Лента за действиеи движението в обратна посока е невъзможно. Можете да местите елементи или вътре Ленти за навигация, било вътре Екшън барове.

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

Видимостта по роля може да приема три стойности: или за дадена роля елементът ще бъде невидим (1); или ще бъде винаги видим, независимо кой флаг е зададен в колоната за видимост (2); или флагът за видимост по роля ще бъде наследен от общия флаг за видимост (3).

Ако на даден потребител са присвоени две роли и за една от тях е посочено квадратче за отметка, а за другото не, тогава стандартното правило на системата 1C:Enterprise 8 ще работи - потребителят има право да извърши действие, ако е разрешено в една на ролите.

Понякога е необходимо незабавно да промените командния интерфейс на няколко Подсистеми. В платформата 1C:Enterprise 8 има сервизен инструмент, който ви позволява да редактирате командния интерфейс на няколко Подсистеми.

Този инструмент се извиква от контекстно менюкоренов възел на клона Подсистеми.

В прозореца, който се отваря, можете бързо да навигирате Подсистемии редактиране на командни интерфейси. Освен това в този прозорец можете да редактирате композицията Подсистеми. Можете също да местите обекти към Ленти за навигацияИ Екшън барове.

Освен това можете дори да промените подчинението Подсистеми. За това има специален бутон Подсистема за преместване.

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

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

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

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

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

С това приключваме нашето запознаване с настройката на структурата на менюто на информационната база. В следващата статия ще продължим запознаването си с управлявания интерфейс и ще разгледаме какви възможности предоставя платформата 1C:Enterprise 8 за работа със списъци.

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

1) Нека започнем с най-често срещания въпрос от любимите ми клиенти, свързан с липсата на менюто „Операции“. Много счетоводители го използваха за търсене на отчети, обработка и документи, които понякога бяха много трудни за намиране в други раздели на програмата.

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

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

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

В което всичко, което сме свикнали да виждаме в Счетоводство 2.0 в раздела „Операции“:

2) Сега нека да разгледаме възможностите на програмата по отношение на настройката на интерфейса TAXI. Например сега програмата ми изглежда така:

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

Тогава всичко е просто. С левия бутон на мишката вземете секцията, чиято позиция искаме да променим, и я плъзнете до мястото, където искаме да видим този панел. Например, така: Ще преместя „Отворен панел“ в горната част и ще плъзна „Панела със секции“ в лявата част на прозореца.

Щракнете върху бутона „Приложи“ или „ОК“ и готово, ето как изглежда нашата програма:

Може би ще е по-удобно за някой да работи по този начин.

3) Друг съвет за настройка на програмата. По правило всеки счетоводител има няколко раздела или отчети, които използва ежедневно. Ами например СОЛ или СОЛ според сметката. И би било много удобно, ако винаги бяха наблизо, винаги под ръка. Това може да се постигне много прост трик, като поставите необходимите отчети в секцията „Любими“. Ще намерим баланса в секцията „Отчети“. Насочвайки мишката към него, виждаме сива звезда наблизо.

Щраквайки върху него, ще маркираме избрания отчет като „Любими“

Раздел "Любими".Използвайки панелния редактор, който вече познаваме, нека го поставим, например, в долната част на работния прозорец на програмата.

4) И още една „тайна“ за настройка на програмния интерфейс. В различни раздели на програмата има документи, които някои хора никога не използват. Ами просто поради спецификата на дейността на организацията. Например в раздела „Покупки“ има документи, свързани с EGAIS.

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

В прозореца, който се показва, виждаме две колони. Отляво има команди, които могат да се добавят към нашия работен плот. И вдясно тези команди, които са на нашия работен плот. Намерете секцията EGAIS в дясната колона и кликнете върху бутона „Изтриване“.

Съответно документите, които са в дясната колона, могат да бъдат добавени към работния плот с помощта на бутона „Добавяне“.

5) И накрая, за тези, които не искат да свикнат с интерфейса „Такси“. Можете да промените интерфейса на този, който беше в първите версии на Accounting 3.0.

В секцията „Администриране“ намираме елемента „Интерфейс“.

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

Ето как ще изглежда програмата с предишния интерфейс.

За забавление, нека да видим какво представлява интерфейсът, подобен на Accounting 7.7.

Е, не знам, не знам. Вероятно ще се върна към обичайното си „Такси“.

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

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

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

Заключение

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

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

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

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

Статията продължава поредицата от статии „Първи стъпки в разработката на 1C“.

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

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

Приложимост

Тази статия обсъжда интерфейса за управлявана конфигурация, разработен на платформата 1C 8.3.4.482. Трябва да се отбележи, че днес управляваният интерфейс, разработен на платформата 1C:Enterprise версия 8.2, се счита за остаряла и се препоръчва да се използва следващата му версия, която се нарича „Такси“. Но старата версия на управлявания интерфейс не е изчезнала и за да се избегне объркване с терминологията в бъдеще, платформата за издание 8.3 започна да класифицира интерфейсите в опции: опцията „Версия 8.2“ (стара) и опцията „Такси“ ( нов).

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

Управляван интерфейс

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

• достъп до главното меню и редица сервизни команди се показват в горната част команден панели се намират на същото място, където се показва заглавието на приложението;
• разположени малко по-ниско Раздел панел, който е с различни възможности за показване (картинки, надписи или картинки и надписи). Всеки раздел в конфигурацията има свой собствен обект Подсистемаи освен това задължителен елемент в раздел панел е Бюро;
• Вляво във всеки раздел може да има Навигационен панел с връзки за отваряне на определени прозорци (включително форми на списъци с различни документи и справочници). Командите на лентата за навигация могат да бъдат сортирани в групи;
• под Раздел панелразположен Лента за действие, който съдържа команди за създаване на обекти (елементи на директории, документи), както и стартиране на отчети, обработка, отваряне на някои сервизни прозорци (например за писане на константи);
• в основната част на приложението, която се нарича Работна зона, се показва прозорецът на текущо избрания елемент. Извиканият прозорец заема цялата тази област. При смяна на прозорци те се сменят една друга. Отварянето на отделни независими прозорци (които могат да се местят по желание) е възможно чрез задържане на клавиша Shift. Такива прозорци се отварят като друг елемент от лентата на задачите на операционната система.

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

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

За оптимизиране на предаваните данни всяка редакция на обект (елемент от директория) също се извършва в отделен диалогов прозорец.

Когато се създават нови обекти, се появява съответното известие ( Зона за предупреждение– в долния десен ъгъл на екрана).

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

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

Меню Всички функциисе показва, ако има отметка в специално квадратче Показване на командата за всички функции в прозореца с опции.

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

прозорец Опцииизвиква се от главното меню. За да направите това, трябва последователно да изберете елемента Обслужване, и след това Опции.

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

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

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

Превключете към Бюрои в контекстното меню на панела със секции изберете .

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

Настройки Работен плотсе съхраняват индивидуално за всеки потребител.

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

В прозореца с настройки Секционни панелиможете да промените реда на секциите, да активирате или деактивирате видимостта на тези секции (с помощта на бутоните за добавяне и премахване) и да контролирате режима на показване ( Снимка, Текстили Картина и текст).

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

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

Вече говорихме за съществуването Зони за предупреждение(при създаване на нови обекти) и Исторически панели(чиито размери са ограничени).

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

Историята също се записва между сесиите, но броят на съхранените записи е не повече от 200. Новите записи заменят старите.

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

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

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

Освен това е възможно да се предават препратки към конкретни елементи. Потребителят, който приеме връзката (например по пощата), може да я отвори.

Но все още имаме празно поле отляво. Можете да извеждате подсистемни команди към него:

За да направите това, трябва да конфигурирате командния интерфейс на подсистемата:

За да се виждат командите от лявата страна на интерфейса, трябва да поставите отметки в полетата в панела за действие:

Както можете да видите, в допълнение към командния панел „Създаване“, има и „Отчети“ и „Услуга“. Засега те не са достъпни за нас, защото не сме създавали отчети. Нека ги създадем и включим в подсистемата "Ценообразуване":

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

След това в командния панел ще се появят тези команди:

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

трето, докладът трябва да има оформление:

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