Плач Ярославны.

А это что и нафига?

https://its.1c.ru/db/metod8dev/content/2836/hdoc

(0 https://forum.infostart.ru/forum9/topic267364/

(3) И чо и чо?

(0) итоги поди считать надо с установленным отбором ?..

Хм... А чего ссылку на ИТС снесли-то? В общем, был в ОФ такой метод, которым можно было поймать событие изменение состояния динамического списка.

(6) ну там есть при изменении пользовательских настроек

(7) Емнип, для быстрых отборов он не срабатывает. И еще для чего-то. И на мобильном недоступен. Ыыыыы... Ну, голь на выдумки хитра. На узких кейсах часто можно что-то придумать. Но почему нормальное событие в руки не дают? Даже уже сдались с исполняемой схемой компоновки дин-списка. А событие - шиш.

Пьяные модеры готовятся к встрече НГ.

(9) да я вообще отдельный сервис запихнул и оповещения с сервера на всех клиентов шлю при изменении критичных данных, а рабочие места это ловят

хм. интересная замена "запилил" на "запихнул"

Может, миста запустила робомодера ED-209?

(10) Ну, это из пушки по воробьям.

(8) Думаю, потому, что нормальная надежная реализация выльется примерно как СВ по сложности. Ради узких кейсов оно того не стоит. К тому же СВ уже есть, пользуйтся.

(14) СВ сложная

(14) Это красненьким, что ли? Захукать на клиенте событие изменения состояния дин-списка ты называешь громким словом "реализация"? И предлагаешь его эмулировать через серверные пуши из звездолета СВ? Еще предложи их через сервера 1С получать, ага.

И вообще, причем тут серверные пуши? Чем они помогут?

(16) Ты про изменение отборов или изменение данных в базе? Я полагаю, твоя конечная цель последнее.

(18) И то и другое. И если можно - без хлеба.

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

(20) Ну раз не те объемы, считай свои итоги в обработчике ожидания.

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

(21) Я не настолько суров. Ограничился изменением периода - это у пользователей основной юзкейс. В обработчике ожидания проверяю поменялся ли период. Но ветка не про мои проблемы. Я их как-нить решу. А про почему зажали хук. И нужен ли он кому. А то все подозрительно молчат. Может, разработчики платформы правы и нафиг надо?

(23) Ну и плюс в мобильном приложении все проще - у меня там только один источник, откуда могут изменения данных списка прилететь. И оттуда я шлю оповещение.

Это ж однопользовательское приложение.

(25) Что, реально однопользовательское? Без синхронизации?

(22) У меня даже есть мысля попробовать реализовать эту идею https://www.youtube.com/watch?v=iEFcmfmdh2w
Если найдется свободное время.

(26) А что, синхронизация данных превращает его в многопользовательское? :)

(28) Да, система в целом многопользовательская.

(29) Не поспоришь. Дай мне освоиться с новой для меня терминологией. А когда я просто импорт/экспорт прикручиваю - я уже гордый писатель многопользовательских систем или еще нет?