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

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

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

ваще то делать это надо ПриЗаписи

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

2-Uho > Смотри (3): тоже редьки не слаще.

[quote=VZ;35436854]нафиг это счастье в виде простынь сведений при массовой перезаписи документов. [/quote] для этого существуют процедуры на клиенте

+5 т.е. в форме

5-Uho > Существуют, но как из запитать? Надо, чтоб это дело вызывалось перед завершением ввода, т.е., в момент "Провести и закрыть". А тут-то форма закрывается. Некому будет принимать протокол.
Не, можно, конешно, жамкать кнопу "записать", форма отсается открытой, но юзеры делают губки обиженным бантиком...

ну тогда может ПриЗакрытии подойдет?

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

еще можно подпиской на событие

8-Uho > Не пойдет: при каждом просмотре включать? При просто просмотреть? А как с теми, кто только помотреть и может?
9-Uho > А пальцем показать?
10-Uho > Неа. Подписка делается на объект: ПриЗаписи, ПриПоведении... Формы там нетути.

вот так, например

[code]

&НаСервере
Процедура ПриЗаписиНаСервере(Отказ, ТекущийОбъект, ПараметрыЗаписи)

//записываем дополнительные данные
//....

//формируем сообщения пользователю

ТекстСообщенияПользователю = "Сам дурак!";


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

&НаКлиенте
Процедура ПриЗакрытии()

Если ЗначениеЗаполнено(ТекстСообщенияПользователю) Тогда
Сообщение = Новый СообщениеПользователю;
Сообщение.Текст = ТекстСообщенияПользователю;
Сообщение.Сообщить();
КонецЕсли;

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

[/code]

ТекстСообщенияПользователю - реквизит формы

При закрытии выведет в область сообщений формы? Или главного окна?

главного.

12-Uho > Хмм...
[em]&НаСервере
ТекстСообщенияПользователю = "Сам дурак!";
ТекстСообщенияПользователю - реквизит формы[/em]

Процедура на сервере будет писать в форму [b]на клиенте[/b]?

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

15-VZ > форма доступна и на клиенте, и на сервере, ее реквизиты тоже

16-Управление торговлей 11 > Не конкретность ищу. Неясна схема: как поймать на клиенте событие, что документ записался? Форма об этом сообщает серверной процедуре, из которой ничего клиенту не возвращается. И вызвать клиентскую процедуру нельзя.
Вот если я нажимаю не "Провести и закрыть", а "Записать" (кнопа с картинкой дискеты), то форма остается открытой, и панель сообщений на месте. Но это не нужное усложнение для работы. А без этого форма закрывается, закрывая автоматически панель сообщений. Даже этого не предотвратить.
Ищу метод активизировать клиента. Фоновый процесс на клиенте замутить, который что-то будет опрашивать? Если в БД не лезет, то и тормозить не будет.
А вот как - не ведаю.
Сервер о клиенте ведает, иначе как бы те же сообщения выкладывал, или всплывающие окна заставлял формироваться. Вот токо даже клиентскую обормотку из сервера не вызвать :(

18-VZ > чем (12) не устраивает?

(18) я слушаю [img]http://ex.by/uploads/posts/2013-06/thumbs/1372017393_demotivatory-35.jpg[/img]

19-Uho > В саму форму лезть неохота. Хлопотно больно эти УФ разглядывать.
Хотя, конечно, можно строку неопределенной длины пихнуть (длина=0), и видно ее в ПослеЗаписиНаСервере...
Прикину :)
Хочется компактности...

в ПослеЗаписиНаСервере сообщение выведется в форму (которая закроется при ПровестиИЗакрыть), а в ПриЗакрытии - выведется в главное окно.

ЗЫ. а еще можно попробовать идентификатор главного окна получить и вывести сообщения туда насильно.

VZ приручает восьмерку [img]http://www.bugaga.ru/uploads/posts/2012-05/1336459859_18.jpg[/img]

подманивает ее морковкой

24-Helen1986 > Зависть к ближнему способствует худобе ;)

22-Uho >С идентификатором, кстати, не прокатит, если включен режим вкладок - все равно при "провести и закрыть" сообщения закроются.

26-Sneer > Ну, именно к моей задаче это не относится: сообщения не из тех, что препятствуют проведению - я не зря запсочил самоделщину в ПослеЗаписи. Потому нужна была лишь информация о правленом доп.реквизите (конкретно: вес единицы измерения в кГ). И вовсе не вся номенклатура под это дело попадает: с "весовой" ЕИ, разумеется, нет, бессмыслица. И только то, что производится. Исключая услуги ;)
Доп.рекизит не учетный, это больше отчетный для собственных нужд. Ну, и ТТН легче формировать: там среди реквизитов "вес" есть.
А сообщения довольно куцые по длине, в них наименованиям товара тесно. Пойдет лучше одно пошире, но со всеми нужными строками, чем узкое из отдельных фрагментов.

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

28-Управление торговлей 11 > Ну, хотя бы для того, чтобы вопросы снимать "А почему...?" - "А потому, что перед этим ввела в приходе столько-то штук на столько-то тонн. И это запомнилось как характеристика. Нет, я не знаю, как это поправить: почему одно и тоже в пятницу легче, а в понедельник тяжелее. Разбирайтесь сами."
Контроль косвенный ;)
Кстати, сами хотели сей механизм. А я предупреждал: "Бойтесь желаний..." :)

28-Управление торговлей 11 >еще раз предложу логи, форму с отбором и бизнес-процесс "Задание"

0-VZ > ИМХО "красиво", без модификации формы объекта, инициирующего транзакцию сделать не получится. Доработки:
1. Добавить на клиенте кэш для хранения времени начала транзакций. Либо экспортной переменной модуля приложения, либо используя кэш типового решения.
2. При создании "сопуствующих объектов" записывать информацию о них в историю работы пользователя.
3. В модуле управляемого приложения сделать экспортную процедуру - анализатор истории. Например так:

[code]Перем ВремяЗапускаТранзакции Экспорт;

&НаКлиенте
Процедура Подключаемый_ПроверкаИстории() Экспорт

Если Не ВремяЗапускаТранзакции = Неопределено Тогда

ИсторияРаботы = ИсторияРаботыПользователя.Получить();
СчетчикЭлементов = 0;
Для Каждого ЭлементИстории Из ИсторияРаботы Цикл
Если ЭлементИстории.Дата >= ВремяЗапускаТранзакции Тогда
СчетчикЭлементов = СчетчикЭлементов + 1;
КонецЕсли;
КонецЦикла;

Если СчетчикЭлементов > 1 Тогда
ПоказатьОповещениеПользователя("При записи объекта были записаны дополнительные элементы НСИ",, "подробности можно увидеть в истории работы пользователя");
КонецЕсли;
КонецЕсли;

КонецПроцедуры // Подключаемый_ПроверкаИстории()

&НаКлиенте
Процедура ПодключитьОбработчикИстории() Экспорт

ВремяЗапускаТранзакции = ТекущаяДата();
ПодключитьОбработчикОжидания("Подключаемый_ПроверкаИстории", 0.1, Истина);

КонецПроцедуры // ПодключитьОбработчикИстории()
[/code]
4. Перед записью в форме добавить строку:
[code] ПодключитьОбработчикИстории();
[/code]

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

31-Reaper > Излишне сложно. Сойдет и параметр формы в качестве переменной, видимой всеми процедурами. И к чему нам история? Нам истории никчему: вводя количество, по введенному/сохраненному ранее значению формируется вес на указанное количество. Если введенного/запомненного нет, то юзер, взглянув в бумажку, пишет общий вес самостоятельно.
После записи (и возможно, проведения, вся табличная часть отправляется на обработку: если "весового коэффициента" не было до того, он формируется из известных значений. Если он другой, то и пишется другой (допустим лаг "ну, почти тоже самое значение"). Собственно, зачем здесь история? Есть история документа, есть история движений в учетных единицах, этого - достаточно. Сообщения же, так, больше для порядка, чтоб юзер совсем уж себя сиротой не чувствовал ;)
Да и знать будет, где что искать, если потребуется.
Захотят строгий учет - будет. Оне сами этого не ведают.
Да и общий отчет по этому делу "за период" уже, собственно, готов. А эти отчеты бережно сохраняются в твердой копии.

32-VZ >С точки зрения методики разработки УФ использование истории считается правильным решением. А я контекста ведь не знал, вот и озвучил "правильное".

33-Reaper > Да контекс-то так себе, ничего интересного :) Только пришлось занудливо прошарить все связки, чтоб понять реализацию в деталях. Описания же нет, как обычно.
К полному разочарованию, ничего из БСП вообще задействовать не удалось.

34-VZ > БСП это отдельная трагикомедия... В наших с ней взаимоотношениях я пока веду в счете, но расслабиться она не дает.