Обновить форму динамического списка со стороны сервера
Есть форма списка документа, динамический список с произвольным запросом, к основной таблице левым соединением присоединяю колонку "состояние" из другой таблицы. При изменении статуса оплаты хотелось бы сразу обновить форму списка, но так как изменяется не основная таблица то динамическое обновление не срабатывает, второе документ изменяющий статус оплаты он создается программно, из другой программы 1с, методы по обновлению формы, которые я нашел работают на клиенте, а мне нужно со стороны сервера как-то сделать
Прикрепленные файлы:
По теме из базы знаний
- Конфигурация "Весовая ред. 3.0" для Платформы 1С 8.3
- Загрузка номенклатуры c картинками (несколько потоков одновременно) и сопутствующими данными в базу и любые документы из yml, xls, xlsx, xlsm, ods, ots, csv для УТ 10.3, УТ 11 (все), БП 3, КА 2, ERP 2, УНФ 1.6/3.0, Розница 2/3.0
- Конфигурация Flowcon: Набор инструментов для управления задачами, проектами и бизнесом в 1С
- Самые используемые методы БСП 3.1.9
- Картинки в динамическом списке
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Утро доброе. Как вариант - под пользователем в настройке формы у дин. списка включить автообновление и поставить нужный период, 30 сек, например. Не совсем вызов клиента с сервера, но насколько мне известно, с сервера вызвать клиент нельзя. Всякие обработчики ожидания делают, которые по таймеру с клиента проверяют нужное.
И сеанс какого клиента должен дернуть сервер? Если всего работает 50 пользюков, 10 сидят в этом динамическом списке, а еще двое сидят и вбивают оплаты из другой программы. Это разные сеансы. И у каждого сеанса свои отдельные клиентские и серверные контексты. Дернуть из одного сеанса сеансы других пользюков - невозможно.
Только автообновление динамического списка.
Только автообновление динамического списка.
(8) Если ответ был на мой комментарий, то смысл в том, чтобы не дергать сервер каждый раз для получения возможно большого объема данных при обновлении данного списка. Что и происходит по идее при автообновлении по заданному периоду (хотя может в платформе какая-то оптимизация для этого имеется).
Другое дело, если бы можно было получить флаг необходимости обновления по событию и только тогда уже обновлять. Что собственно и происходит в толстом клиенте, если изменяется основная таблица динамического списка.
Конечно, такое реализовать можно и самостоятельно через обработчик ожидания, но нужно организовать где-то глобальное хранение флага (на сервере) изменения данных и потом дергать точно так же сервер (пусть и без контекста формы), чтобы получить значение этого флага. А потом уже, при необходимости, обновлять сам список. Как об этом кратко упоминалось в (2) и (3).
Поэтому я не стал расписывать это изначально, а просто зачеркнул свой предложенный вариант.
Другое дело, если бы можно было получить флаг необходимости обновления по событию и только тогда уже обновлять. Что собственно и происходит в толстом клиенте, если изменяется основная таблица динамического списка.
Конечно, такое реализовать можно и самостоятельно через обработчик ожидания, но нужно организовать где-то глобальное хранение флага (на сервере) изменения данных и потом дергать точно так же сервер (пусть и без контекста формы), чтобы получить значение этого флага. А потом уже, при необходимости, обновлять сам список. Как об этом кратко упоминалось в (2) и (3).
Поэтому я не стал расписывать это изначально, а просто зачеркнул свой предложенный вариант.
(10) Нет, это было автору.
При запуске устанавливается параметр сеанса, равный константе.
При записи критических данных - константа изменяется.
При чтении критических данных - сравнивается параметр и константа, в случае несовпадения сбрасывается кэш и параметр сеанса опять привязывается к константе. Далее производим чтение через модуль с повторным использованием (кэшируемый).
но нужно организовать где-то глобальное хранение флага (на сервере) изменения данных и потом дергать точно так же сервер (пусть и без контекста формы), чтобы получить значение этого флага.
Ага, я обычно это делаю сравнением константы и параметра сеанса, в которых лежит ГУИД.
При запуске устанавливается параметр сеанса, равный константе.
При записи критических данных - константа изменяется.
При чтении критических данных - сравнивается параметр и константа, в случае несовпадения сбрасывается кэш и параметр сеанса опять привязывается к константе. Далее производим чтение через модуль с повторным использованием (кэшируемый).
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот