Под капотом управляемых форм 1с. Под капотом управляемых форм. Рабочая область и вложенные формы

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

Введение

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

Немного истории

Исторически сложилось, что клиентское приложение 1С всегда было реализовано в виде так называемого «толстого» клиента – программы, которая сама все делает в плане обработки данных. Это создавало заметную нагрузку на сеть, а кроме того, требовало наличия мощных клиентских машин.

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

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

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

В основном, все оставалось по-старому, и клиентское приложение так и оставалось «толстым» клиентом, гоняющим сотни мегабайт по сети.

Версия 8.2 кардинально сломала устоявшийся подход к работе приложения и заставила по-новому взглянуть на архитектуру приложения. Об этом новом подходе и пойдет речь в данной статье.

Волшебный зверь Клиент-сервер

С выходом версии 8.0 все учебные курсы, книжки, статьи на ИТС и прочее, и прочее, все в один голос твердили нам – «обработка данных должна идти на сервере», «все нужно выполнять на сервере». Волшебное заклинание «на сервере» плотно забило мозг, так сильно, что на него уже никто внимания не обращал, как на информационный шум.

Опыт показывает, что рядовой программист практически никогда не знал, как нужно перенести код на сервер и что это вообще значит – «на сервер». Удивительно часто встречался код, который переносился «на сервер», но был написан с явным непониманием того, что это в итоге принесет.

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

Однако многие уже опытные разработчики запросто писали такой код:

  • Выбирается локальный файл
  • Его путь передается на сервер
  • Там по этому пути файл пытается открыться и падает с ошибкой «Файл не найден» (еще бы, он же остался на клиенте).
Переход на сервер

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

Суть всех флагов модуля сводится к простым правилам:

  1. Флаг показывает, где будет скомпилирован код модуля (на клиенте, на сервере, во внешнем соединении)
  2. Если модуль скомпилирован в нескольких местах, то он будет виден только в соответствии с флагами. Клиентский – на клиенте, серверный на сервере. Переноса исполнения с машины на машину не будет.
  3. Перенос исполнения кода возможен только если в текущем контексте исполнения нет вызываемого модуля, но он есть в другом месте (если – модуль есть только на сервере, а на клиенте его нет, то будет сделан вызов сервера)
Флаг «Вызов сервера»

В версии 8.2 добавился флаг «вызов сервера», который помогает разрулить условия перехода на другую машину. Если модулю назначить этот флаг, то модуль будет виден с клиента, если нет – то попытка вызова с клиента приведет к ошибке. Код модуля виден не будет, как будто его нет совсем.

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

  1. Установлен флажок «Сервер»
  2. Установлен флажок «Вызов сервера»
  3. Сняты все «клиентские» флажки
Особенности перехода на сервер

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

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

Это объясняет, почему не все объекты можно передавать на сервер. Это все потому, что не все они поддерживают сериализацию (превращение в строку и обратно). На сервер нельзя передать, например, «ДокументОбъект», т.к. у него в модуле объекта могут быть глобальные переменные, а в них записаны какие-нибудь сложные несериализуемые значения, вроде COM-объектов… Короче, ограничения по обмену с сервером понятны и обоснованны. Нужно следить за тем, что мы передаем на сервер и что возвращаем назад.

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

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

Отсутствие контекста (состояния) на сервере

Существует такая модель серверных приложений, когда сервер только отвечает на запросы, но ничего не сохраняет у себя в промежутке между двумя запросами. Эта модель называется моделью «без состояния» (англ. state-less).

Все HTTP-серверы современного интернета работают именно так. Клиенты посылают запросы, сервер выдает ответ и забывает все, что получал от клиента. Разумеется, есть вариации, но общая модель именно такая: сервер отрабатывает запрос и очищает все данные.

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

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

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

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

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

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

Тонкий клиент

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

Такое облегчение не далось бесплатно. Очень многие привычные операции стали выполняться сложнее. Упомянутая выше сериализация никуда, разумеется, не делась, а данные, которые нельзя было передавать на сервер, так и нельзя туда передавать.

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

Чтение данных из ИБ в форму и запись из формы в ИБ выполняется практически явно, этот момент можно отловить в событиях формы.

Тонкий клиент стал поистине «клиентом». Он больше не обрабатывает данные, он их показывает и позволяет редактировать. Всю обработку мы теперь явно переносим на сервер.

Устройство управляемой формы

Давайте рассмотрим, из каких частей состоит управляемая форма.

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

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

Данные формы

Есть старая уже хохма про ПроцессорВыводаРезультатаКомпоновкиДанныхВТабличныйДокументИмениНуралиеваБорисаГеоргиевича.

Управляемая форма добавляет очередного претендента на звание длинного и непонятного идентификатора: ДанныеФормыСтруктураСКоллекцией и еще ряд новых классов с именами вида «ДанныеФормы….что-то там». Давайте попробуем выяснить, что это за новые объекты.

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

Обратите внимание, что классы данных формы любопытно называются «ДанныеФормыСтруктура» или «ДанныеФормыКоллекция». Это вообще, как мне кажется, неспроста. Эти объекты – это просто немного модифицированная стандартная Структура (или ТаблицаЗначений, соответственно).

Здесь стоит немного вспомнить обычные формы. Ведь как мы привыкли – В форме справочника достаточно присвоить переменной «Наименование» какой-то текст и этот текст попадет в СправочникОбъект, а оттуда – в информационную базу.

У управляемой форме все почти так, за исключением того, что все совсем не так (IMG:) .Платформа предпринимает массу усилий, чтобы в повседневной работе программиста ему не приходилось с этим заморачиваться. Как правило, мы, как и раньше, присваиваем свойства реквизитам формы, а они попадают в СправочникОбъект, а оттуда – в ИБ.

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

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

Адресация данных формы

Данные формы доступны непосредственно в коде по тем именам, как они расположены в дереве реквизитов формы (в окне редактора)

Реквизиты верхнего уровня доступны сразу. Вложенные реквизиты доступны через точку. Раньше в обычной форме мы обращались к данным объекта напрямую. Мы писали «Наименование = «АААААА» и данные попадали в объект. Теперь надо писать «Объект.Наименование = «ААААА», потому, что реквизит «Наименование» вложен внутрь реквизита «Объект».

Обмен формы с сервером

Основным «двигателем» всех аспектов управляемой формы является то, что у нас state-less сервер. На нем не сохраняется ничего, никаких промежуточных данных. Всё состояние формы (текст в полях ввода, строки табличных частей и т.п.) хранится на клиенте. Вся совокупность данных формы называется контекстом формы.

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

Жизненный цикл формы объекта

Давайте рассмотрим, что происходит, когда мы открываем форму существующего элемента справочника.

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

Теперь, давайте рассмотрим процесс записи данных справочника:

  1. Пользователь нажимает кнопку «Записать»
  2. Выполняется обработчик формы «ПередЗаписью» (на клиенте)
  3. Происходит серверный вызов
  4. В памяти сервера создается новый СправочникОбъект, он наполняется данными на основании данных текущей формы (что-то вроде ЗаполнитьЗначенияСвойств, но в обратном направлении – пишется из формы в объект)
  5. Вызывается обработчик события формы «ПередЗаписьюНаСервере», куда передается свежесозданный СправочникОбъект. С этого момента, если мы хотим что-то записать в базу данных, то менять нужно именно СправочникОбъект. Изменения данных формы не отразятся в записываемом объекте.
  6. Вызывается обработчик «ПередЗаписью» самого СправочникОбъект (в модуле объекта)
  7. Вызывается обработчик «ПриЗаписи» самого СправочникОбъект (в модуле объекта)
  8. Вызывается обработчик события формы «ПриЗаписиНаСервере», транзакция записи еще не завершена и можно отменить запись
  9. Вызывается обработчик события формы «ПослеЗаписиНаСервере», транзакция записи уже завершена
  10. СправочникОбъект уничтожается
  11. Выполняется возврат на клиента, где вызывается обработчик события формы «ПослеЗаписи»
Обратите внимание, серверное состояние восстанавливается с нуля, каждый раз создается новый СправочникОбъект. В промежутках между вызовами сервера он не сохраняется.

Конвертация данных формы

Для упрощения жизни существуют простые способы преобразования универсальных объектов «ДанныеФормы….» в привычные прикладные объекты и наоборот.

Так, например, можно получить наполненный данными СправочникОбъект на основании данных формы, если вызвать метод «РеквизитФормыВЗначение(«Объект»). При этом произойдет то, что описано выше – будет создан новый СправочникОбъект и наполнен данными из указанного реквизита данных формы.

Обратное преобразование выполняется методом «ЗначениеВРеквизитФормы». Если мы произвели какие-то действия с данными СправочникОбъект, например, очистили табличную часть, то мы должны поместить наши изменения обратно в форму, иначе будет что?

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

Не все так плохо (IMG:)

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

Команды формы

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

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

Каждая команда может быть размещена в командной панели, подменю, или на самой форме. Создаются команды на закладке «Команды» в редакторе формы.

Параметры формы

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

Управление открытием формы

Отображение форм на экране в управляемом режиме также претерпело некоторые изменения. Прежде всего, формы получили имена, по которым к ним можно обращаться. Например, форма списка справочника «Контрагенты» будет называться «Справочник.Контрагенты1.ФормаСписка».

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

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

Для этого и нужны Параметры формы. Это структура, которую можно передать в метод «ОткрытьФорму». Переданные параметры можно проанализировать в серверном коде формы и предпринять какие-то действия на основании переданных параметров.

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

УсловияОтбора = Новый Структура;
УсловияОтбора.Вставить("ТипКонтрагента", "Поставщик");
УсловияОтбора.Вставить("Лояльность", "Надежный");
ОткрытьФорму("Справочник.Контрагенты.ФормаСписка", УсловияОтбора);

Существуют системные параметры, на которые реагирует сама платформа. Упомянутый параметр «Отбор» как раз является системным, если он передан форме списка, то платформа сама установит отбор на список.

Кроме того, параметры можно создавать произвольные, в редакторе формы. Более того, параметры можно передавать даже с теми именами, которые не объявлены в форме, они все равно будут видны в серверном коде формы.

Жизненный цикл параметров

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

Исключение составляют параметры, которые в редакторе формы объявлены с признаком «Ключевой параметр». Такой параметр будет существовать до тех пор, пока существует сама форма.

Процедура ПриСозданииНаСервере(Отказ)

Если Параметры.ЗапуститьЯдерныйРеакторПриОткрытии Тогда
УправлениеРеактором.Запустить();
КонецЕсли;

КонецПроцедуры

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

Модуль формы

Справедливости ради стоит отметить, что они доступны не только в модулях форм, но, как правило, используются только там. Директива компиляции это строчка вида &НаКлиенте перед объявлением процедуры.

Для модуля форм возможны следующие директивы:

  • &НаКлиенте
  • &НаСервере
  • &НаСервереБезКонтекста
  • &НаКлиентеНаСервереБезКонтекста
Директива указывает компилятору, где нужно скомпилировать указанную процедуру. С директивами «НаКлиенте» и «НаСервере» все понятно, а вот с добавкой «БезКонтекста» нужно разобраться подробнее.

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

контекст формы, т.е. ее данные. Когда мы вызываем сервер «с контекстом», то контекст должен быть передан на сервер, поскольку его там в данный момент просто не существует (сервер state-less).

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

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

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

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

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

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

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

Переменные уровня модуля формы

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

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

Временное хранилище – секретное оружие

При работе с управляемыми формами быстро становится ясно, что ограничения клиент-серверного взаимодействия очень сильно сужают возможности разработчика. Поэтому, платформа 1С предоставляет хитрый секретный ход под названием «ВременноеХранилище». Эта сущность позволяет сохранить на сервере некоторое состояние между двумя серверными вызовами. Я слышу возгласы: «А кто сказал, что состояние нельзя хранить!» Справедливое замечание, состояние хранить все-таки можно, но недолго.

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

Для работы со временным хранилищем используются методы ПоместитьВоВременноеХранилище и ПолучитьИзВременногоХранилища.

С методом «Получить» все просто, он по заданному адресу возвращает значение, которое лежит в хранилище.

С методом «Поместить» несколько сложнее. Дело в том, что помещать можно в 2 разных хранилища – простое и хранилище формы. Хранилище формы живет на сервере столько, сколько живет сама форма. Простое хранилище живет ровно 2 серверных вызова. В синтакс-помощнике об этом написано целых несколько умных строк. Я никогда не понимал, что они означают. Опытным путем было установлено, что срок жизни – 2 серверных вызова.

  • Первый – мы помещаем что-то в хранилище и возвращаем адрес на клиента.
  • Клиент делает второй вызов и по этому адресу может получить данные.
  • В третьем вызове по этому адресу уже ничего не будет. Платформа очистит хранилище
С хранилищем формы ситуация более интересная. Если вторым параметром метода «ПоместитьВоВременноеХранилище» передать идентификатор формы (ЭтаФорма.УникальныйИдентификатор), то данные в хранилище будут привязаны к сроку жизни формы и не будут удалятся ни в первых, ни во вторых, ни во всех прочих вызовах сервера.

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

Особенности временного хранилища

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

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

Как примерно работает временное хранилище:

  • Данные помещаются в ВХ
  • Управление возвращается на клиента
  • Клиент делает повторный серверный вызов
  • Менеджер кластера переключает вызов на другую машину из кластера (не ту, что помещала данные в хранилище)
  • И вот тут, если данные в хранилище были сериализуемые, то все отлично, мы получим их даже на другой машине кластера.
  • Если данные не были сериализуемые (СправочникОбъект, COM-объект, что-то еще), то они просто пропадут, ибо нефиг.
Если не вдаваться в дебри документации, то можно сказать примерно следующее: данные во временном хранилище существуют в пределах двух серверных вызовов, либо, если они помещены в хранилище формы, то в течение жизни формы.

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

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

Массив = Новый Массив; Массив.Добавить("Привет");

Адрес = ПоместитьВоВременноеХранилище(Массив);

Массив.Добавить("До свидания");

МассивИзХранилища = ПолучитьИзВременногоХранилища(Адрес);

Сообщить(Массив = МассивИзХранилища); // Истина

Сообщить(МассивИзХранилища.Количество()); // 2 элемента

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

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

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

Краткий итог

  • Взаимодействие с сервером теперь не спрятано от разработчика. Наоборот, оно каждую минуту напоминает о себе. И это хорошо.
  • Сервер 1С не сохраняет данные между обращениями клиента к серверу. Нужно проектировать взаимодействие с учетом этой особенности
  • Временное хранилище – мощное средство, которое нивелирует сложности state-less взаимодействия и позволяет строить сложные схемы серверных вызовов.
  • У формы есть контекст, который передается с клиента на сервер и обратно при каждом контекстном вызове сервера. Для несложных вызовов, где не требуется вся форма целиком, следует использовать внеконтекстные вызовы.
Заключение

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

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

Литература к прочтению

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

Постскриптум

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

[необходимо зарегистрироваться для просмотра ссылки]

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

Мне даже стало жалко, что 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 и Такси.

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

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

Мы все знаем, что у компании "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, отсюда и все вытекающие последствия. Код также должен быть разделен на клиентский и на серверный, указывается это с помощью соответствующих директив в конфигураторе.

Режиме работы интерфейсов в 1С. Как переключить конфигурацию с режим управляемого приложения. Создание обработки 1С на управляемых формах. Процедуры &НаКлиенте.

Управляемые формы в 1С 8 3 знакомимся и создаем первую форму

Мастер-класс "Разработка в управляемом приложении 1С 8.3"

#1С83 #1СУправляемоеПриложение #1СТакси #1СПрограммирование #1СРазработка #НизамутдиновИльяс

Запись онлайн мастер-класса Разработка в управляемом приложении.

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

Более подробно о разработке в управляемом приложении 1С 8.3. Вы можете прочитать в моей книге Основы разработки в 1С: Такси.

Прочтение этой книги даст вам полное понимание всех механизмов управляемого приложения 1С 8.3.

А увидеть все наглядно и потренироваться на домашних заданиях в разработке управляемого приложения можно вместе с моим тренингом Практикум по управляемому приложению 1С 8.3

Набор книг по разработке в 1С: Предприятии:

Промо-код на скидку в 10%: podpiska

Обучающие статьи и видео-ролики по разработке в 1С:

Книга Программировать в 1С за 11 шагов:

Видео-курс Конфигурирование в 1С для начинающих

Если Вы хотите поддержать мой проект, то можете перечислить любой донат на эти кошельки:

Яндекс.Деньги - 410012882996301
Web Money - R955262494655

Внешние печатные формы 1С 8.3 и 8.2 в управляемых формах

Ссылка на статью и пример создания внешней печатной формы в 1С:

Получайте бесплатные материалы на почту:

Читайте статьи по 1С на нашем сайте:

Пошаговая инструкция по созданию внешних печатный форм в 1С 8.3 (Бухгалтерия, Управление торговлей, ЗУП и т.д)

Создание формы в 1С и работа с обработчиками

Управляемый и обычный режим работы форм в 1С 8. Как создать новую форму и разместить на ней кнопки. Запуск программного кода 1С по кнопке.

Услуги 1С программиста в Москве:

Читайте статьи по 1С на нашем сайте:

1С Разработка управляемого приложения Часть 1

Курс по разработке управляемых приложений в среде 1С:Предприятие 8

Материалы:

Часть 1.
Основные сведения по архитектуре
Типы клиентов
Клиент-серверное взаимодействие
Переход на платформу 8.2
Сценарии применения управляемого интерфейса
Основные компоненты управляемого интерфейса
Командный интерфейс
Управляемые формы
Автоматически создаваемые управляемые формы
Создание командного интерфейса
Простые примеры управляемых форм
Создание управляемой формы
Реквизиты управляемой формы
Расположение элементов управляемой формы
Команды управляемой формы

Создаем простую печатную форму в 1С 8.3

Создание макета печатной формы 1С. Вывод параметров печатной формы. Указание формата в коде и в ячейках

Наша статья про внешние печатные формы для типовых конфигураций:

Услуги 1С программиста в Москве:

Читайте статьи по 1С на нашем сайте:

РАСШИРЕНИЕ 1С. УРОК 6. ДОБАВЛЕНИЕ КОМАНД НА ФОРМУ

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

Желаю вам приятного просмотра!

Благодарен каждому за репост этого видео.

#расширения1с #уроки1с #видео1с

Мои контакты:

1С: программное изменение форм и элементов

Учимся программно создавать и изменять формы и ее элементы. И главное узнаем, зачем это вообще нужно:)

Краткий экскурс в суть проблемы + подробное изложение вопроса.

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

П.С. Прогадал со звуком. Чуял, что где-то косяк))

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

Как я создал обработку 1С в управляемом приложении. Более подробная статья на эту тему:

ПРОГРАММИРОВАНИЕ УПРАВЛЯЕМЫХ ФОРМ В 1С. КАК ЭТОМУ НАУЧИТЬСЯ?

Всем привет.

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

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

Желаю вам денег и приятного просмотра!

Книга Практическое пособие разработчика (Радченко) -

Книга Разработка управляемого интерфейса -

Видеокурс Быстрый старт в профессию -

Видеокурс Профессиональная разработка интерфейсов и форм -

Вы можете поддержать развитие канала, отправив денежку на этот кошелек:

Мои контакты:
ВКонтакте: vk.com/ilyaleontyev
Фэйсбук: facebook.com/illeontev

С удовольствием добавлю вас в друзья при условии, что вы не будете меня грузить своими рабочими вопросами:)

Управляемые формы. Как передать параметры форме при открытии.

Урок 4. Создание форм в 1С.

Курс: Конфигурирование 1С

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

Курс создается при поддержке форума 1С forum-1c.ru

Принимаем пожертвования на развитие сервиса на кошелек Яндекс денег: 41001124584205

Доработка печатной формы типовой конфигурации 1С

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

Услуги 1С программиста в Москве:

Читайте статьи по 1С на нашем сайте:

Курсы 1С Программист Бесплатный урок № 05 Создание форм

Бесплатный урок № 5 Программист 1С
Зайди на и получи 60 бесплатных уроков по программированию в 1С и стань успешным Программистом 1с. Изучи 1с с нуля, устройся на работу и начни зарабатывать от 30 000 рублей в месяц.
Мы учим не только программированию в 1с, но и многим другим вещам, которые нужны программистам 1С. Например: Как строить отношения с клиентами?
На сегодняшний день программист 1С востребованная и высокооплачиваемая профессия. Количество организаций, которые используют 1С, постоянно растёт, соответственно и растёт спрос на программистов 1С.

В этом видео рассказывается как создавать формы объектов конфигураторе 1С, рассматриваются стандартные команда формы, рассматривается как добавить свою команду на форму.

1С программирование для новичков. Урок 1-9. Форма документа.

Девятый урок по программированию на 1С. Добавляем форму документа и проверку количества на ней.

1с 8.3 Управляемые Формы: 13. Подсистемы, командный интерфейс

1с 8.3 Управляемые Формы: 13. Подсистемы, командный интерфейс

1с 8.3 Управляемые Формы. Запросы. Урок 01

1с 8.3 Управляемые Формы. Запросы. Урок 01
8:03 Создаём новый запрос, Про МенеджерВТ
10:59 Результат и Выборка запроса
22:21 Как запустить обычную Консоль Запросов в упр. формах
29:41 Выбрать
33:18 ИЗ, КАК, *
41:27 Упорядочить
44:31 ГДЕ, &Параметры
51:14 РазностьДат

Файлы базы для запросов

Редактирование макетов печатных форм в пользовательском режиме

Необходимость изменить макет какой-либо печатной формы в 1С возникает достаточно часто.

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

Сайт проекта: ИльяЛеонтьев.РФ
Профиль VK:
Профиль FB:
Instagram: ilyaleontyev

Добавляйтесь! Будем дружить.

 

Возможно, будет полезно почитать: