В этой статье я расскажу, как настроить интерфейс программы «Такси» для комфортной работы, чтобы все нужные кнопочки и самые необходимые отчеты всегда были под рукой.

1) Начнем с самого распространенного вопроса моих любимых клиентов, связанного с отсутствием меню «Операции». Многие бухгалтера использовали его для поиска отчетов, обработок, документов, которые иногда очень сложно было обнаружить в других разделах программы.

Как такового меню «Операции» в бухгалтерии 3.0 нет. Его аналог называется «Все функции» и по умолчанию отображение этого раздела в программе не установлено. Чтобы включить его надо войти в меню, которое открывается с помощью оранжевой кнопочки с треугольником в верхнем левом углу программы. В появившемся списке выбрать раздел «Сервис» и открыть раздел «Параметры».

В открывшемся окне устанавливаем флажок «Отображать команду «Все функции» и закрепляем результат нажатием кнопки «Применить».

Теперь в том же Главном меню (оранжевая кнопка с треугольником) мы видим раздел «Все функции»

В котором все то, что мы так привыкли видеть в Бухгалтерии 2.0 в разделе «Операции»:

2) Теперь рассмотрим возможности программы в плане настройки интерфейса ТАКСИ. Например, сейчас у меня программа выглядит вот так:

Т.е. разделы сверху. Открытых окна в закладках внизу. Давайте посмотрим как изменить расположение всех элементов рабочего окна программы. Опять открываем главное меню и находим там раздел «Настройка панелей».

Дальше все просто. Левой кнопкой мыши захватываем тот раздел, положение которого хотим изменить и перетаскиваем туда, где хотим видеть эту панель. Например, так: «Панель открытых» я подниму наверх, а «Панель разделов» перетащу в левую часть окна.

Нажимаем кнопку «Применить» или «Ок» и вуа-ля, вот как стала выглядеть наша программа:

Возможно, кому-то так работать будет удобнее.

3) Еще один совет по настройке программы. Как правило, у каждого бухгалтера есть какие-то разделы или отчеты, которыми он пользуется ежедневно. Ну, например, ОСВ или ОСВ по счету. И было бы очень удобно, если они будут всегда рядом, всегда под рукой. Этого можно добиться весьма простым приемом, поместив необходимые отчеты в раздел «Избранное». Найдем в разделе «Отчеты» оборотно-сальдовую ведомость. Наведя на нее указать мыши, мы видим рядом серую звездочку.

Кликнув по ней, мы отметим выбранный отчет как «Избранное»

Раздел «Избранное» с помощью уже известного нам редактора панелей поместим, например, внизу рабочего окна программы.

4) И еще один «секрет» по настройке интерфейса программы. В различных разделах программы есть документы, которыми некоторые не пользуются никогда. Ну, просто в силу специфики деятельности организации. Например, в разделе «Покупки» документы, связанные с ЕГАИС.

Эти документы нам не нужны и можно убрать их с рабочего стола. Для этого в редактируемом разделе в правом верхнем углу нажимаем на шестеренку и в появившемся меню выбираем пункт «Настройка навигации»

В появившемся окне мы видим две колонки. Слева-команды которые можно добавить на наш рабочий стол. А справа, те команды которые есть на нашем рабочем столе. Находим с правой колонке раздел ЕГАИС и нажимаем на кнопку «Удалить»

Соответственно, документы которые находятся в правой колонке можно добавить на рабочий стол по кнопке «Добавить»

5) Ну и напоследок, для тех, кто никак не хочет привыкать к интерфейсу «Такси». Можно изменить интерфейс на тот, который был в первых версиях бухгалтерии 3.0.

В разделе «Администрирование» находим пункт «Интерфейс»

Здесь разработчики предложили нам на выбор изменить интерфейс программы на такой как в предыдущих версиях 8.3 и аналогичный Бухгалтерии 7.7. Выбрав интересующий нас внешний вид программы, ее придется перезапустить.

Вот так выглядеть будет программа с предыдущим интерфейсом.

Для интереса посмотрим, что же такое интерфейс, аналогичный Бухгалтерии 7.7.

Ну не знаю, не знаю. Я пожалуй вернусь к привычному для меня «Такси».

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

Мы все знаем, что у компании "1С" было много разных версий платформы 1С, нас сейчас будут интересовать одни из последних версий на момент написания этой статьи, это версии 1С 8.2 и 1С 8.3. Если Вам приходилось работать в обеих этих версиях то Вы, скорее всего, заметили различия в интерфейсах данных версий , для пользователей они отличаются только внешне. По сути, выбор обычного или управляемого приложения говорит системе, какие формы для отображения нужно запускать, обычные или управляемые , а также какой клиент приложения будет использоваться по умолчанию, толстый или тонкий. Более подробную информацию по клиентам читайте в статье «Что такое толстый и тонкий клиент в 1С, а также их различия».

Обычное приложение 1С (обычные формы, обычный интерфейс, версия 1С 8.2)

В 1С 8.2 возможна работа только с обычными формами, в режиме обычного приложения . На изображении ниже показана база в режиме работы "обычное приложение 1С" (обычные формы).

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

На платформе 1С 8.3 мы можем работать как с обычными формами (в режиме совместимости) так и с управляемыми. Причем у управляемых форм есть два вида отображения, это стандартный и такси . Пример конфигурации 1С 8.3 со стандартными управляемыми формами показан ниже, а после него показан интерфейс "Такси".

Чем отличаются обычное и управляемое приложение 1С?

Как мы уже выяснили обычное приложение и управляемое приложение это такие виды запуска программы 1С . Причем в зависимости от значения вида запуска 1С (обычное или управляемое приложение ), по умолчанию будет загружаться определенный интерфейс (обычные или управляемые формы ), отсюда и столько синонимов этому понятию. Хотим отметить, что различия в интерфейсах довольно существенные, управляемый интерфейс был переработан полностью. В принципе это и есть все отличия, которые видят рядовые пользователи программы 1С. Что касается программистов, то управляемый интерфейс требует написания видоизмененного кода, ведь разработка уже ведется в 1С 8.3, а не в 1С 8.2, отсюда и все вытекающие последствия. Код также должен быть разделен на клиентский и на серверный, указывается это с помощью соответствующих директив в конфигураторе.

И Data Transfer Object к структуризации кода, управляемой формы в среде 1С 8.2.

Введение

Начнем с небольшого описания понятия «управляемая форма» и связанных концепций платформы 1С. Знатоки платформы могут пропустить этот раздел.

В 2008 году стала доступна новая версия платформы 1С: Предприятие 8.2 (далее Управляемое приложение), которая полностью меняет весь слой работы с интерфейсом. Сюда относится и командный интерфейс, и формы, и оконная система. При этом не только меняется модель разработки пользовательского интерфейса в конфигурации, но и предлагается новая архитектура разделения функциональности между клиентским приложением и сервером.
Управляемое приложение поддерживает следующие типы клиентов:

• Толстый клиент (обычный и управляемый режим запуска)
• Тонкий клиент
• Веб-клиент

В управляемом приложении используются формы, построенные на новой технологии. Они называются Управляемые формы . Для облегчения перехода прежние формы (т.н. Обычные формы) также поддерживаются, но их функциональность не развивается и они доступны только в режиме запуска толстого клиента.
Основные отличия управляемых форм для разработчика:

• Декларативное, а не «по пикселям» описание структуры. Конкретное размещение элементов выполняется системой автоматически при отображении формы.
• Вся функциональность формы описывается в виде реквизитов и команд . Реквизиты – это данные, с которыми работает форма, а команды – выполняемые действия.
• Форма выполняется и на сервере и на клиенте.
• В контексте клиента, недоступны практически все прикладные типы, и соответственно невозможно изменить данные в информационной базе.
• Для каждого метода или переменной формы обязательно должна быть указана директива компиляции , определяющая, место выполнения (клиент или сервер) и доступ к контексту формы.

Перечислим директивы компиляции методов формы:

• &НаКлиенте
• &НаСервере
• &НаСервереБезКонтекста
• &НаКлиентеНаСервереБезКонтекста

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

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

Обозначим проблему

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

Рассмотрим структуру кода (модуль формы) в нескольких формах одной типовой конфигурации и попробуем найти закономерности.
Под структурой будем понимать секции кода (чаще всего это блоки комментариев) выделенные разработчиком для группировки методов и директивы компиляции этих методов.
Пример 1:
Секция обработчиков событий Метод – наклиенте Метод – насервере Метод - наклиенте Секция служебных процедур и функций Вспомогательные функции управления вводом
Пример 2:
Служебные процедуры и функции Документы оплаты Ценности Обработчики событий
Пример 3:
Служебные процедуры на сервере Служебные процедуры на клиенте Служебные процедуры на сервере без контекста Обработчики событий шапки Обработчики событий команд
Пример 4:
Процедуры общего назначения Обработчики событий формы Процедуры подсистемы «контактная информация»
По сути, структура кода отсутствует, или мягче говоря, она аналогична тому, что было в формах 8.1:

• Неинформативные слова «Общие, Служебные, Вспомогательные».
• Робкие попытки разделить клиентские и серверные методы.
• Часто методы группируются по интерфейсным элементам «Работа с табличной частью Товары, Контактной информацией».
• Произвольное расположение методов и групп кода. Например, Обработчики событий могут быть в одной форме вверху, в другой внизу, в третьей вообще не выделены и т.д.
• И не будем забывать, что это все в рамках одной конфигурации.
• Да бывают конфигурации, в которых слова «Общие, Служебные, Вспомогательные» всегда находятся на одних и тех же местах но…

Зачем нужна структура кода?

• Упрощение сопровождения.
• Упрощение обучения.
• Фиксация общих/важных/удачных принципов.
• …ваш вариант

Почему существующий стандарт разработки от фирмы 1С не помогает?

Посмотрим опубликованные на дисках ИТС и в различных «Пособиях разработчика…» принципы, рекомендуемые при написании управляемой формы.

• Минимизируйте число серверных вызовов.
• Максимум вычислений на сервере.
• Неконтекстные вызовы сервера быстрее контекстных.
• Программируйте с учетом клиент-серверного взаимодействия.
• и т.п.

Это лозунги, абсолютно верные, но как их реализовать? Как минимизировать число вызовов, что значит программировать в клиент-серверном режиме?

Шаблоны проектирования или мудрость поколений

Клиент-серверное взаимодействие используется в различных программных технологиях не один десяток лет. Ответ на обозначенные в предыдущем разделе вопросы давно известен и суммирован в двух базовых принципах.

• Remote Facade (далее Интерфейс удаленного доступа)
• Data Transfer Object (далее Объект переноса данных)

Слово Мартину Фаулеру , его описание данных принципов:

• … каждый объект, потенциально предназначенный для удаленного доступа, должен иметь интерфейс с низкой степенью детализации , что позволит максимально уменьшить количество вызовов, необходимых для выполнения определенной процедуры. … Вместо того, чтобы запрашивать счёт и все его пункты отдельно, надо считать и обновить все пункты счёта за одно обращение. Это влияет на всю структуру объекта.…Запомните: интерфейс удаленного доступа не содержит логики домена .
• …если бы я был заботливой мамой, то обязательно сказал бы своему ребенку: «Никогда не пиши объекты переноса данных!» В большинстве случаев объекты переноса данных представляют собой не более чем раздутый набор полей … Ценность этого омерзительного монстра состоит исключительно в возможности передавать по сети несколько элементов информации за один вызов - прием, который имеет большое значение для распределенных систем.

Примеры шаблонов в платформе 1С

Прикладной программный интерфейс доступный разработчику при разработке управляемой формы, содержит много примеров данных принципов.
Например метод ОткрытьФорму(), типичный «огрубленный» интерфейс.
ПараметрыОткрытия = Новый Структура("Параметр1, Параметр2, Параметр3", Значение1, Значение2, Значение3); Форма = ОткрытьФорму(ИмяФормы, ПараметрыОткрытия);
Сравните с принятым в v8.1 стилем.
Форма = ПолучитьФорму(ИмяФормы); Форма.Параметр1 = Значение1; Форма.Параметр2 = Значение2; Форма.Открыть();

В контексте управляемой формы множество «Объектов переноса данных». Можно выделить системные и определяемые разработчиком .
Системные моделируют на клиенте прикладной объект, в виде одного или несколько элементов данных формы. Создать их вне привязки к реквизитам формы нельзя.

• ДанныеФормыСтруктура
• ДанныеФормыКоллекция
• ДанныеФормыСтруктураСКоллекцией
• ДанныеФормыДерево

Преобразование системных объектов переноса данных в прикладные типы и обратно выполняется методами:

• ЗначениеВДанныеФормы()
• ДанныеФормыВЗначение()
• КопироватьДанныеФормы()
• ЗначениеВРеквизитФормы()
• РеквизитФормыВЗначение()

Часто явное преобразование используется при адаптации существующего решения. Методы могут ожидать (использовать особенности) входные параметры, например ТаблицаЗначений, а не ДанныеФормыКоллекция, или метод был определен в контексте прикладного объекта и стал недоступен для прямого вызова из формы.
Пример 1С v8.1:
// на клиенте в контексте формы ЗаполнитьКэшПользователей(ПодразделениеСсылка)
Пример 1С v8.2:
// на сервере в контексте формы ОбработкаОбъект = РеквизитФормыВЗначение("Объект"); ОбработкаОбъект.ЗаполнитьКэшПользователей(ПодразделениеСсылка); ЗначениеВРеквизитФормы(ОбработкаОбъект, "Объект");

Объекты переноса данных, структура которых определяется разработчиком это небольшое подмножество типов доступных и на клиенте и на сервере. Наиболее часто в качестве параметров и результатов методов «огрубленного» интерфейса используются:

• Примитивные типы (строка, число, булево)
• Структура
• Соответствие
• Массив
• Ссылки на прикладные объекты (уникальный идентификатор и текстовое представление)

Пример: метод принимает список заказов для изменения статуса и возвращает клиенту описание ошибок.
&НаСервереБезКонтекста Функция СерверИзменитьСтатусЗаказов(Заказы, НовыйСтатус) Ошибки = Новый Соответствие(); // [заказ][описание ошибки] Для Каждого Заказ Из Заказы Цикл НачатьТранзакцию(); Попытка ДокОб = Заказ.ПолучитьОбъект(); …. другие действия, возможно не только с заказом… Исключение ОтменитьТранзакцию(); Ошибки.Вставить(Заказ, ОписаниеОшибки()); КонецПопытки; КонецЦикла; Возврат Ошибки; КонецФункции // СерверИзменитьСтатусЗаказов()

Структурируем код

Главные цели, которые должен отражать модуль управляемой формы и подходы к решению.

• Четкое разделение клиентского и серверного кода. Не будем забывать, в момент выполнения это два взаимодействующих процесса, в каждом из которых существенно отличается доступный функционал.
• Четкое выделение интерфейса удаленного доступа, какие методы сервера можно вызывать с клиента, а какие нельзя? Названия методов удаленного интерфейса начинаются с префикса «Сервер». Это позволяет, читая код сразу видеть переход управления на сервер, и упрощает использование контекстной подсказки. Отметим, что официальная рекомендация (ИТС) предлагает именовать методы с постфиксами, например, так ИзменитьСтатусЗаказовНаСервере(). Однако повторим не все серверные методы можно вызывать с клиента, и поэтому более важна логическая доступность, а не место компиляции. Поэтому префиксом «Сервер» отмечаем только методы доступные для клиента, метод-пример назовем СерверИзменитьСтатусЗаказов().
• Удобочитаемость. Дело вкуса, принимаем порядок, когда модуль начинается с процедур создания формы на сервере и методов удаленного доступа.
• Сопровождаемость. Должно быть однозначно определено место для добавления нового кода. Важный момент, автоматически создаваемые конфигуратором заготовки методов добавляются в конец модуля. Т.к чаще всего автоматически создаются обработчики событий элементов формы, то соответствующий блок расположен последним, чтобы не перетаскивать каждый обработчик в другое место модуля.

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

• Графический вариант – наглядно показывает основной поток выполнения.
• Текстовый вариант - это пример оформления шаблона для быстрой вставки структуры в новый модуль формы.

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

Связанные вопросы

В заключение обозначим несколько направлений, о которых полезно подумать при программировании клиент-серверного взаимодействия.

• Варианты реализации интерфейса удаленного доступа . Асинхронность, степень детализации...
• Кэширование. В 1С приняли неудачное архитектурное решение, введя кэширование только на уровне вызова методов общих модулей и не предоставив возможности управления (время актуальности, сброс по требованию).
• Неявные серверные вызовы . Не забывайте о технологических особенностях, многие «безобидные» операции на клиенте провоцируют платформу на обращение к серверу.

Здравствуйте.

Сегодня речь пойдет об интерфейсах и формах в «1С:Предприятие 8.2».
Предоставляя , заметил, как многие отличают командный интерфейс от обычного интерфейса только визуально, вот и решил внести ясности.

Обычный интерфейс

Обычный интерфейс пользователям и разработчикам 1С хорошо знаком, он существует со времени выхода платформы «1С:Предприятие 8.0». На данный момент (март 2012) обычное приложение используется в следующих типовых конфигурациях:

1. «1С:Управление производственным предприятием 8», редакция 1.3
2. «1С:Управление торговлей 8», редакция 10.3
3. «1С:Бухгалтерия 8», редакция 2.0
4. «1С:Зарплата и Управление персоналом 8», редакция 2.5

Основные особенности обычного интерфейса это:
1. Наличие главного меню.
2. Неизменность главного меню для всех пользователей независимо от их прав доступа и каких-либо настроек.
3. Для разных пользователей можно создавать разные интерфейсы.

Обычный интерфейс «Бухгалтерия предприятия, редакция 2.0»

Как запустить обычный интерфейс если по умолчанию запускается тонкий клиент? Смотри в:

Обычная форма

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

Обычные формы работают только в толстом клиенте.
Обычные формы не работают на каналах связи с низкой пропускной способностью.

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

Управляемый интерфейс (синоним командный интерфейс ) — состоит из команд и окон, является динамическим, т.е. доступность тех или иных команд зависит от прав пользователей, настроек, сделанных в конфигурации и других параметров.

С помощью команд в управляемом интерфейсе можно переключаться между разделами конфигурации, открывать различные списки, формировать отчеты.
Запуск конфигурации в управляемом режиме начинается с рабочего стола. На рабочем столе должна быть представлена информация, актуальная для пользователя – задачи пользователя, текущие сделки и т.д. Рабочий стол имеет возможности настройки, не прибегая к средствам конфигурирования

Управляемый интерфейс «Управление торговлей, редакция 11.0»

Главное преимущество управляемого интерфейса – возможность работы в веб-клиенте (веб-браузере). Нет необходимости ставить платформу 1С на компьютер. Для пользователей на операционной системе Linux, для доступа к информационной базе 1С используется веб-браузер Mozilla Firefox.

Управляемая форма

Управляемая форма — новый объект платформы 8.2 предназначенный для работы на тонких каналах связи.
Структура управляемой формы является более четкой, т.к. разработчик не может своевольно изменять положение элементов управления на ней. Разработчик только описываем элементы формы и можем изменять взаимное расположение элементов только согласно определенной структуре. может компилироваться как на клиенте, так и на сервере.

В платформе 8.2 основной интерфейс управляемый работает на управляемых формах, но платформа 8.2 пот поддерживает и обычный интерфейс с обычными формами.

В Управляемом интерфейсе «1С:Предприятия 8.2».

Пожалуйста оставляйте комментарий мне важно Ваше мнение.

P.S. Большая разница серебро мама люба

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

Мне даже стало жалко, что 1С полностью не отказалась от обычных форм из-за того, что они используются в режиме рабочего стола. Ведь можно было бы дать возможность в УФ точного пиксельного позиционирования, и обычные формы бы отмерли со временем. А так приходится распылять силы еще и на знание старого функционала.

А так, конечно, УФ намного быстрее обычных, т.к. работают по трехзвенной схеме между клиентом и сервером.

Кроме того, сам функционал УФ намного богаче и шире, чем у обычных - неудивительно, прошло много времени, и в них попали многие интерфейсные находки.

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

На практике их не так страшно использовать, как казалось изначально, я освоился быстро. В свое время я достаточно программировал общих модулей, которые работали только на сервере, и сталкивался с преобразованиями мутабельных значений для передачи их на сервер, поэтому управляемые формы были доступны моему пониманию.

Модальности, событийность и блокировки интерфейса

Я слышал, что в 8.3 появился отказ от модальных функций вроде Вопрос , Предупреждение , ОткрытьФормуМодально . Для меня было непонятно, зачем это было сделано.

Каково же было мое удивление, когда в одном из примеров преподаватель вызвал открытие формы с параметром «Заблокировать весь интерфейс», т.е. по сути модально.

Я-то был уверен, что от модальности отказались.

Понимание пришло не сразу.

В 1С не отказались от модальных окон. Есть новые функции, чтобы вывести предупреждение, задать вопрос, открыть модально диалог выбора файла.

Нюанс в том, что после вызова этих модальных окон управление не замораживается, как раньше, в ожидании, когда форма закроется, а продолжается. Форма вызывает оповещение, что она закрылась, и нужно обработать это оповещение.

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

Конечно же, это никоим образом не связано с тем, что браузеры испытывают сложности с показом модальных окон. Это заблуждение и предрассудок - забудьте его как дурной сон. Все логично. По сути теперь выполнение полностью событийное и асинхронное, от синхронного выполнения удалось избавиться.

В 1С появились мини-конструкторы - рефакторинг. Это упрощает написание обработчиков оповещения для асинхронного режима работы, чтобы не писать их вручную.

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

Новые возможности интерфейса

Меню

Если управляемые формы выглядят вполне логичным и правильным направлением развития, то направление развития системы меню для меня так и осталось непонятым.
Несомненно, меню, где показывается только один уровень, затем нужно заходить в следующий подуровень и так до выбора нужного пункта уже морально устарело, и ему на смену пришла карта меню, где развернуты сразу несколько пунктов меню. Это было сделано в типовых еще до выхода новых интерфейсов меню в 8.2.

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

Я так понял, что 1С посчитало неправильным, что прикладной объект Интерфейс не используют, и решила выпустить ему новую, продвинутую альтернативу.

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

В общем, новые способы организации меню пришли, на мой взгляд они не очень удачные, но альтернативы нет, и их применяют в типовых.

Я спросил преподавателя: «Мне понятно насчет управляемых форм, но зачем нужно было развивать интерфейсы, почему было нельзя немного доработать классическое меню»?

Он мне ответил, что система 1С развивается в направлении увеличения комфорта и скорости работы пользователя. На мой взгляд все же, такие грандиозные изменения в системе меню этого не стоят.

Порядок обхода

Кстати, для производительной работы пользователей важен порядок обхода - многие на автомате уже заучили определенный порядок обхода полей. Так вот, как раз от порядка обхода в 8.2 отказались. Он строго соответствует порядку размещения элементов. К счастью, есть возможность программного перехвата выхода из поля и передачи фокуса другому полю, иначе было бы совсем плохо с заявленной производительностью.

Рабочая область и вложенные формы

Рабочая область - всего одна. Поэтому приходится запихивать в неё формы практически всех пользователей и определять их видимость правами. Все это должно приводить в больших конфигурациях к хаосу.

Намного проще было бы создавать её программным кодом или использовать механизм вложенных форм.

Что так и не реализовано в 8.2-8.3

Я так и не дождался вложенных форм. Увы, их нет, хотя они использовались еще в древнем Access .

Перетаскивания через буфер обмена нет. Т.е. приходится тащить мышкой, нельзя указать - я тащу отсюда и помещаю здесь, не разрывая жесть мышью, увы. Хотя, возможно, здесь на помощь может прийти сторонний софт, т.к. перетаскивание - это системная вещь в Windows .

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

В своё время RLS были созданы для того, чтобы показывать пользователям только отдельные записи таблиц.

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

На мой скромный взгляд, видимостью полей все же проще управлять программным путем, чем декларативно, расставляя галочки и делая сложный механизм функциональных опций.

В свое время я доказал, что RLS на изменение уступает программному контролю записи на уровне модуля объекта/подписки. Точно так же подозреваю, что любая функциональная опция уступает обычному алгоритмическому описанию контроля видимости элементов - как в простоте использования, так и в универсальности подхода.

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

Приговор - функциональные опции и видимость через роли - малоэффективны, но их надо знать, т.к. они используются в типовых конфигурациях.

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

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

Главное отличие - расположение объектов главного меню. В 8.2 они занимали много места слева и сверху, в итоге под рабочую область для пользователя оставлялось мало места в правом нижнем углу. В интерфейсе Такси меню автоматически скрывается, оставаясь в виде небольшого меню слева, в итоге под рабочую область отводится практически весь экран.

Непонятно, зачем было идти таким запутанным путем, если в итоге базовая система меню в 8.1 еще более экономно расходовала рабочее пространство экрана?

Также в Такси изменились принципы отображения окон, в итоге код форм для 8.2 в некоторых местах неудобен. Но в этом направлении разницы я еще не осознал, хотя преподаватель и пытался рассказать основные принципы Такси. Попробую разобраться на практике, хотя и считаю все эти усовершенствования интерфейса избыточными и ненужными на практике пользователям бизнес-приложений.

Кстати, в 8.2 нельзя поменять палитру, это как бы визитная карточка платформы 1С. Точно также и система организации меню в виде 8.2 или Такси приучает пользователей к некоторому стандарту. Однако практика показывает, что на новую систему меню пользователь переучивается практически мгновенно. Вот поменять навыки работы с документами и отчетами намного сложнее.

Поэтому весь этот шум и споры вокруг системы меню мне не очень понятны - это не основной момент в платформе 1С, оставим его на совести архитекторов платформы и указывающих им направление развития руководителей.

Не проработанная идеология

Преподаватель правильно заметил, хотя это понятно и так, что разработчики платформы не создали новых сущностей там, где это нужно.

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

Также приходится организовывать пустые роли (интерфейсные роли), которые нужны только для того, чтобы указать, какие объекты будут отображаться в той или иной форме. Хотя логичным было бы развить в этом направлении прикладной объект «Интерфейс».

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

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

Например, много внимания на курсах было уделено, чтобы печатная форма документа показывалась в отдельной подчиненной форме документа и когда документ менялся, чтобы она очищалась. Смысла в этом не очень много, иногда нужно напечатать несколько экземпляров - например до правки и после. Запутаться в паре документов и нескольких печатных формах невозможно с практикой, поэтому распыление энергии в этом направлении мне показалось сомнительным.

Также, например, в платформе невозможно сделать поле ввода в ячейке динамического списка, если источником является не базовая таблица. Не потому что это технически сложно, а из соображений usability .

Возможности сохранения настроек

Настройки формы сохраняются напрямую в базу, а не в сеансе. При аварийном завершении они не теряются. Соответственно, появился новый механизм работы с этими настройками, где можно сохранять и свои данные. Альтернатива СохранитьЗначение /ВосстановитьЗначение .

Теперь все сохраненные настройки при необходимости можно программно перебрать, а значит, выгрузить другому пользователю, в файл и т.п.

Остальные вопросы

Что такое управляемые формы?

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

Под клиентом подразумевается слабая машина, им может быть даже обычный браузер.

А сервер находится в непосредственном и быстром соединении с базой данных.

Клиент не может работать с базой данных, он может выполнять мелкие математические операции и управлять элементами своих форм. Если требуется получить что-то из базы данных или отправить туда данные - клиент обращается к серверу.

Именно так работают управляемые формы. При должной сноровке постоянное обращение к серверу не является сложностью.

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

Заметки по 1С россыпью

Здесь приведу заметки, которые писал для себя, они содержат ценные знания:

1. В окне запуска 1С прописываются уже не информационные базы, а точки входа. Т.е. одна база может присутствовать несколько раз, но прописана для разных пользователей и разных инструментов работы - браузер, тонкий/толстый клиент, вход для администратора.
2. Для администратора появился ключ, который отключает контроль ролей. Войти в Предприятие таким способом можно, только если доступны административные права на конфигурацию.
3. Общие реквизиты - не путать их с общими реквизитами в 1С7, в 82 они используются для разделения доступа в интерфейсе.
4. Часто использовал минимальную высоту списка в форме, чтобы избавиться от лишней полосы прокрутки формы.
5. Не стоит хранить картинки в реквизите справочника, это приводит к падению производительности справочников, надо использовать регистр сведений.
6. В процедурах сервера при передаче параметров нужно использовать ЗНАЧ, чтобы параметр не передавался обратно на сервер.
7. Новые функции СтрНачинаетсяС и СтрЗаканчиваетсяНа , возможно и другие, с платформы 8.3.6.
8. В 1с 8.2 появился привилегированный режим, т.е. можно отключать контроль прав доступа на уровне ролей на участках кода.
9. Элементы формы список, таблица значений и дерево значений отличаются тем, что список на сервере и клиенте имеет одинаковое представление, а для таблицы и дерева создаются специальные объекты и их надо преобразовывать на сервере.
10. Порадовало, что преподаватель любит называть объекты в единственном числе и называть модули с подчеркивания, чтобы эти модули шли первым по порядку в контекстной подсказке.

О жизни и вокруг 1С

Преподаватель утверждал:

1. Разработку нужно вести с интерфейса.
   Мое мнение : Утверждение сомнительное, т.к. знание и опыт использование архитектуры платформы позволяет сразу идти от прикладных объектов, а интерфейс уже строить потом.
2. Руководитель не вводит данные, только смотрит отчеты. А управляет не вводом данных в 1С, а телефоном и через секретаря. Поэтому руководителю достаточно браузера, а поля ввода нужны только для фильтрации данных.
   Мое мнение : Да, это похоже на истину.
3. Критиковал БСП (Библиотека Стандартных Подсистем). В том плане, что из нее невозможно и очень сложно выделить необходимые модули.
   Мое мнение : Т.к. даже БСП не удалось разбить на модули, то и УПП не получается разбить на модули УТ, ЗУП, БП, Производство. И тут не платформа виновата, а неправильная методология написания типовых - не соблюдается модульность. Тот же Navision давно имеет возможность сначала продать клиенту бухгалтерию, а потом он может докупить торговлю, производство и зарплату при необходимости, без переписывания кода и перехода на новую программу.
4. Типовые стали очень сложными, их затруднительно изменять. Опять же не из-за сложности платформы, а из-за неправильной организации типовых. При этом теряется основной принцип - быстрое и экономное сопровождение и доработка типовых конфигураций при необходимости.
5. Был продемонстрирован вариант оформления заказа, когда слева в рабочей области находится номенклатура, справа - список заказов. Напротив номенклатуры можно ставить количество, затем перетаскивать ее в список заказов и формируется заказ. Преимущество - не блокируется таблица заказов для создания нового заказа.
   Мое мнение : Преимущество надуманное - все же пользователям привычнее видеть отобранный товар в табличной части, можно сохранить этот заказ как черновик или скопировать заказ из шаблона. В общем, документы придуманы не зря.
6. Объяснял разницу между разделами «Главное», «Важное», «Перейти», «Смотри также».
   Мое мнение : Лично я понял смутно, а значит, большинство так и не поймет эти заложенные в платформу нюансы usability в Такси. Поэтому интерфейсы будут выглядеть как раньше, как уже привыкли и пользователи, и программисты в 1С.
7. В ячейке табличного поля на форме, источником которого является произвольный запрос, нельзя вводить данные, как в поле ввода. Это сделано в интересах usability , чтобы пользователь фокусировался на вводе данных в отдельном окошке.
   Мое мнение : Я привел пример с вводом в табличные части, где такое поле имеется, смысл запрета мне не понятен.
8. Разводы возникают от сравнения супруга с другими людьми. Меньше сравнений - крепче брак.
9. Иностранные языки легче изучать, когда изучаешь их сразу несколько, снимается зашоренность и зацикленность на одном родном языке.
10. Иностранные языки невозможно изучать, если привязывать иностранное слово к слову на родном языке, нужно привязывать к образу. Цепочка иностранное слово - образ короче чем цепочка иностранное слово - родное слово - образ. В последнем случае мыслить на иностранном не получится.

Заключение

Выражаю благодарность преподавателю.

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

Теперь управляемые формы не пугают меня, а, наоборот, влекут познать их.

Надеюсь, и вы, читающие эту статью, по достоинству оцените управляемые формы.