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

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

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

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

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

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

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

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

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

Публикувам втора глава от книгата си "Основи на развитието в 1С: Такси"

Глава 2. Редовно и управлявано 1C приложение

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

Какво всъщност е "интерфейс"? Всъщност това е обща граница между две взаимодействащи системи (много често една система е човек). Да вземем за пример кола. Има ли интерфейс? Разбира се. Но каква е общата граница между колата и човека? Първо, това е работно място, т.е. директно седалката на водача и органите за управление (волан, педал на газта, педал на спирачката и др.). Второ, това са принципите на човешкото взаимодействие с автомобила, които са някакъв набор от правила. Например, за да ускорите колата, трябва да натиснете педала на газта, за да забавите - педала на спирачката, за да завиете надясно, трябва да завъртите волана надясно и т.н. Благодарение на тези две единици човек може да управлява кола. Премахнете едно нещо и шофирането става невъзможно.

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

Например, трябва самостоятелно да поддържаме складови записи: да извършваме пристигането на стоки в склада, да отписваме тези стоки и да наблюдаваме баланса. Каква ще бъде общата граница между приложението, независимо как и къде е написано, и потребителя? Първо, това са органи за въвеждане на информация - иначе как ще прехвърлите в програмата, че 5 броя от някакъв продукт са пристигнали в склада. В нашия случай това е компютърна клавиатура и компютърна мишка. Второ, това е система за взаимодействие между компютър и човек. Например, това може да бъде интерфейс на командния ред: ще използвате клавиатурата, за да въвеждате различни текстови редове (команди) и да ги използвате за извършване на необходимите действия (записване на пристигане на стоки, потребление на стоки и т.н.). Такъв интерфейс изглежда по следния начин: вижте фиг. 1.2.1.

Ориз. 1.2.1 Пример за команден ред

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

Този тип интерфейс отдавна е архаичен и е заменен от графичен потребителски интерфейс (англ. графичен потребителски интерфейс GUI). В този интерфейс взаимодействието между потребителя и приложението се осъществява чрез различни графични елементи, начертани на дисплея (бутони, икони, превключватели и т.н.). В графичния интерфейс операторът има произволен достъп чрез контролите до всякакви графични елементи. В нашия случай, когато автоматизираме складовото счетоводство, взаимодействието може да изглежда така: операторът натиска бутона „Входящ“, отваря се формата за избор на продукт, където операторът избира желания продукт от списъка и въвежда неговото количество. Ако трябва да направите разход, операторът натиска бутона "Разход", отваря се и формата за избор, където операторът също избира желания продукт и въвежда неговото количество. Когато е необходимо да се провери салда, операторът натиска бутона „Остава“ и програмата показва останалите стоки в склада. По този начин, използвайки този графичен интерфейс, можете доста успешно да следите стоките на склад.

Нека приключим с теоретичната част и да преминем директно към темата на тази глава. А именно към видовете интерфейси на приложението на програмата 1C, които всички са графични потребителски интерфейси. Програмата "1C: Enterprise 8" има два глобални типа интерфейси за графични приложения. Това са режим на редовно приложение и режим на приложение за управлявани формуляри (или управлявано приложение).

Издание на платформи 8.0 и 8.1. работи само в нормален режим, по-високите версии на платформата (8.2, 8.3 и т.н.) могат да работят както в нормален режим на приложение, така и в режим на управлявано приложение.

Нормален режим на приложение

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

Нормалният режим на приложение използва интерфейса и формите, които са били използвани в платформите 8.0 и 8.1. Преди този режим не се наричаше нищо, но сега се нарича "нормален режим на приложение", а формите, които се използват в този режим, се наричат ​​"нормални форми".

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

След изтегляне на програмата потребителят вижда интерфейс с меню в горната му част (виж фиг. 1.2.2).

Фигура 1.2.2 Изглед на общ интерфейс на приложението

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

Фиг.1.2.3. Формуляр за списък с документи

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

Ориз. 1.2.4. Формуляр за документ

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

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

Фигура 1.2.5. Проектиране на общи формуляри

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

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

Режим на управлявано приложение

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

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

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

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

Когато разработва управлявано приложение, програмистът ще трябва да поеме по малко по-различен път. Преди да разработим бизнес логика, трябва да дефинираме подсистемите, които ще включват нашите обекти (в обикновено приложение те също съществуват, но са по-декларативни). Например документът "Входящи стоки" ще бъде включен в подсистема "Доставка", а документът "Разход на стоки" ще бъде включен в подсистема "Продажби". В същото време някои обекти могат да бъдат разположени в няколко подсистеми едновременно: директорията "Продукти" ще бъде включена в подсистемата "Продажби", в подсистемата "Доставка" и в подсистемата "Маркетинг". В този случай разработчикът не трябва да създава обект "Интерфейс", системата автоматично ще изгради желания тип интерфейс въз основа на настройките за правата на потребителя и функционалните опции.

Ако потребителят има роля, в която няма право да преглежда подсистема, например „Доставка“, тогава при стартиране на приложението 1C той просто няма да види този елемент от менюто. Освен това той няма да види документ в списъка с менюта, за който няма право поне да го прегледа.

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

Ориз. 1.2.7. Ограничен потребителски интерфейс

Друга разлика от обичайния интерфейс е, че потребителят може самостоятелно да определи външния вид на своя интерфейс, използвайки настройките за навигация, действия, секции и т.н. Например от интерфейса на Фигура 1.2.7 можем да премахнем складовите артикули от функции на текущата секция (горно меню) и "Продукт". Получавате този вид:

Ориз. 1.2.8. Потребителски интерфейс с намалени функции на текущата секция

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

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

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

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

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

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

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

Yandex.Money — 410012882996301
Уеб пари - R955262494655

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

Всички знаем, че компанията 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 те заеха много място отляво и отгоре, в резултат на това остана малко място за работното пространство за потребителя в долния десен ъгъл. В интерфейса на Taxi менюто автоматично се скрива, оставайки под формата на малко меню вляво, в резултат на което почти целият екран е разпределен за работното пространство.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

Когато потребителят влезе в 1C в Enterprise режим, за да започне работа, той първо вижда интерфейса на програмата.

В програмирането под word интерфейсможе да означава няколко различни значения. Сега имаме предвид "потребителски интерфейс".

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

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

Платформата 1C реализира два различни механизма на потребителски интерфейс, които се използват в различни . Дебелият 1C клиент има свой собствен интерфейс, тънкият (и уеб клиентът) има свой собствен.

Нека поговорим днес за потребителския интерфейс 1C.

Интерфейс 1C

1C интерфейсът на дебел клиент изглежда така.

Включва:

• Главно меню
• Панели.

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

В конфигуратора интерфейсът 1C се намира в клон Общи / Интерфейси.

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

В свойствата на интерфейса 1C има квадратче за отметка "Превключване". Ако интерфейсът 1C не може да се превключва (отметката е премахната), всички потребители го виждат, дори ако им е назначен различен 1C интерфейс. В този случай потребителят вижда и двата интерфейса обединени в един.

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

Ако добавите още панели, те ще се показват като панели (с бутони).

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

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

При добавяне на горния елемент от менюто, в свойствата можете да изберете едно от типичните менюта - Файл, Операции, Сервиз, Windows, Помощ.

След като добавите бутон или елемент от менюто, трябва да изберете действието, което да извършите. Действието може да бъде от два вида.

Ако искате щракването да отвори 1C обект - директория, документ или отчет - трябва да щракнете върху бутона с три точки и да изберете желания обект, както и желаната форма (възможно действие на обекта).

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

Управляван команден интерфейс 1C

В новата версия на 1C 8.2 се появиха нови типове клиенти -.

Интерфейсът на тънкия клиент на 1C изглежда така.

Интерфейсът на уеб клиента на 1C изглежда така.

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

Вече се състои не само от менюта и панели, но и от:
1) Списък на счетоводните раздели
2) Навигация през избрания раздел
3) Команди за изпълнение в текущата секция
4) Формуляри за извършване на текущата операция.

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

Факт е, че сега интерфейсът на 1C е еднакъв за всички потребители и в същото време динамичен, работещ в зависимост от набора от потребителски права и командите, които той може да изпълни.
Можете също да кажете, че се формира на базата, така че се нарича още команден интерфейс 1C.

Подсистеми 1C

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

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

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