Я в УФ не настоящий сварщик.
Надо чтобы отчет на УФ работал в том числе с COM-соединением.
В обычных формах я бы просто инициализировал переменную модуля в теле модуля отчета.
Но в УФ, насколько я понял/вычитал, контекст модуля объекта не сохраняется и модуль создается при каждом серверном вызове (и каждый раз исполняется тело модуля).
Как в случае УФ красиво "удерживать" COM-соединение до закрытия формы отчета?

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

Спасибо.
Книга знаний: Хранение COM Объектов на Сервере ТонкогоКлиента
Оно?

Из статьи: "Первым и самым простым выходом может стать хранение переменных в реквизитах формы, на сервере". Это мне и нужно.
Имеется в виду хранение в реквизите формы адреса объекта во временном хранилище?
Или можно каким-то образом в реквизите формы сохранять серверный объект? Просто формулировка неоднозначная. Просветите плиз.

А реквизиты отчета (не формы) могут содержать серверные типы, и если да - то сохраняются ли они между серверными вызовами?

(3)
&НаСервере
Перем ComОбъект;

//Основная часть кода управляемой формы.

Исправил статью

Спасибо!!

Черт. Наверное так не взлетит.
Мне же нужно из модуля объекта до COM-объекта достучаться.
Из ПриКомпоновкеРезультата() в отчете.
Какой тогда самый красивый вариант остается?

(8) И в чем проблема то?

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

(9) В моих пробелах в знаниях. Разве из модуля объекта можно обращаться к переменным формы, пусть даже и серверным? Это фигня какая-то будет. Я ж могу с объектом и без формы работать.

(11) Храни адрес временного хранилища (строка) - в параметре сеанса

И будет щасте.

(11) Храни в реквизите объекта, а не формы.
Или пользуй РеквизитФормыВЗначение()

(14) Во! Вокруг этого и мыслю. А я могу в реквизит отчета прямо ссылку на соединение запхать? Оно выживет на сервере между серверными вызовами?

Гы! Когда тупо попробовал засунуть COM-соединение в реквизит отчета на сервере, 1С молча свернула коврик :) Ну, надежда и так была слабая.
Попробую аналогичную фигню с временным хранилищем...

(15) Ссылку - не сможешь

Сейчас через временное хранилище попробую.
А как лучше всего кэш констант (ссылочных типов) хранить для использования в модуле объекта? Прокатит засунуть их в структуру а её запихать в реквизит отчета?

Или аналогично через временное хранилище придется?

(18) Накуа?

Используй ОМ с повторным использованием возвращаемых значений + подпиской на Запись константов и учетных регистров и
методом ОбновитьПовторноИспользуемыеЗначения()

(21) Не. Мне нужен локальный кэш повторно используемых значений в конкретном отчете. Не глобальный.

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

Пусть живет. Жалко штоле.

(24) иногда бывает жалко.

Получается нехорошо... Привязки к времени жизни объекта нет... Проверять, подновлять нужно... На форму, что ли, таки завязаться?

Что-то я туплю... А на клиенте вообще доступны реквизиты отчета? Как к ним обратиться?

(27) Хто? Объект.Что-то?

(28) Пытаюсь в клиентской процедуре УФ отчета набрать "Объект" - контекстная подсказка не дает вариантов. Просто тупит?

Не, не тупит. На клиенте нету такого свойства ни у УФ, ни у расширения УФ отчета.

Недавно аналогичную задачу решал, решение в Книга знаний: Хранение COM Объектов на Сервере ТонкогоКлиента для поддержки соединения не срабатывает. Возможно потому, что использовал cntr = Новый COMObject("V82.COMConnector");  вместо апликейшен.
Сделал себе такую процедурку и вызываю её раз в 10 мин.
Процедура ОбновлениеСоединения() Экспорт
   connection = ПолучитьСоединение(); // COM соединение
   Обновили = connection.String("Обновили");
КонецПроцедуры

Вопрос по реквизитам отчета оформил отдельно: v8: Доступность реквизитов отчета в УФ?
По сабжу, в принципе, расклады ясны.
Всем спасибо!

Попытался поместить во временное хранилище с привязкой к форме, но не из формы (передав идентификатор открытой формы на сервер) и ввел 1С в тягостное недоумение :)
Придется не выёживаться и делать как все :)

Последний вопрос в этой ветке, крест на пузе!
Как красиво проверить, жив ли еще COM-объект во временном хранилище?

Нашел в статье в КЗ. Невнимательно читал...

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

Далее везде пишем (в начале процедур и обработчиков):
ComОбъект=Кеш.ПолучитьКомСоединение();

Получаем, что на время всего сеанса "на сервере" всегда будет 1 соединение

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

(34) Попытаться вызвать его метод через попытку...

(36) А код этого модуля показать можешь?

(38) Так это вроде стандартный прием. Я просто не хочу его весь сеанс держать...

//Работа с подсистемой Истории объектов
Функция ПолучитьСоединениеСБазойИстории() Экспорт
   
   ПутьКБазеИстория = Универсальные.ЛокальнаяКонстанта("СтрокаСоединенияСБазойИстории");
   Если ПустаяСтрока(ПутьКБазеИстория) или ПутьКБазеИстория = Неопределено Тогда
       Возврат Неопределено;
   КонецЕсли;
   
   Попытка
       V8 = Новый COMObject("V82.ComConnector");
       Объект=V8.Connect(ПутьКБазеИстория);
   Исключение
       Объект=Неопределено;
   КонецПопытки;    
   Возврат Объект;
   
КонецФункции

(39) тогда мой способ не подойдет :-)

(39) + хотя по моему разумению страшного не случится если соединение повисит еще минут 15 после закрытия формы, а потом закроется само.

(42) Погодь. По методу (40) оно ж должно до закрытия 1С висеть?

(42) у меня в случае неактивности (т.е. если долго никто не вызывает Кеш.ПолучитьКомСоединение()) com соединение закрывалось (смотрел список подключений в другой базе - вроде на 15 минуте)

(40) А Объект - это локальная переменная или где-то объявлена?

(44) Видать 1С стандартно так все COM-соединения отстреливает. По методу (2) такая же фигня. Тогда однозначно делаю через общий модуль, ибо проще и красивше.
(45) Локальная. Хранение между вызовами обеспечивает механизм повторного использования возвращаемых значений.

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

(47) Ээээ... А "как-то криво" - что конкретно имеется в виду? У меня на это дело работа правил РИБ завязана (я там разрешения объектов кэширую). Вроде тьфу-тьфу-тьфу...

(46) (47) понял, спасибо

(48) точно не скажу. Вроде при динамической балансировке нагрузки между серверами больно часто производилось переподключение к базе com. Для него это проблема была важной из-за того, что лицензий впритык было куплено.

(50) Вроде нестрашно... Дык если ПЕРЕподключение, то не должны же лишние лицензии расходоваться?

Я тут подумал...
Ведь если в (40) по какой-либо причине первая попытка подключения будет неудачной, то он же тупо больше и не будет пытаться подключиться?

Воткнул в случае неудачного подключения ОбновитьПовторноИспользуемыеЗначения();

(51) это для случаев когда клиент "перепрыгивает" между серверами кластера
(52,53) скорее всего... тогда еще проверку на "Неопределено" добавлять надо - и в случае неуспеха - ОбновитьПовторноИспользуемыеЗначения().

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

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

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

(56,57) я имел в виду что-то такое сделать(в процедурах формы):
ComОбъект=Кеш.ПолучитьКомСоединение();
Если ComОбъект=Неопределено Тогда
//  Сообщить как нибудь
ОбновитьПовторноИспользуемыеЗначения();
// предпринять что-то дальше - например сделать еще одну попытку              //ComОбъект=Кеш.ПолучитьКомСоединение();
....
КонецЕсли;

но вообще как-то плохо с этой ситуацией, весь кеш сбрасывать в некоторых ситуациях - слишком большая цена

Тоже делал через повт. исп. в ОМ, как в (40). Вроде работает.

(58) Так тебе нужно держать соединение или закрывать и заново открывать?

Кстати, V82.ComConnector это как бэ не само соединение. Так что я вообще немного не так делал.
Я возвращал сам объект V82.ComConnector, а дальше метод Connect сам смекал соединятся снова или использовать пул.
Собственно, вот такой вот код:

Функция ПолучитьКОМКоннектор82() Экспорт

   COMConnector = Новый COMОбъект("V82.COMConnector");
   COMConnector.PoolCapacity = 1;
   COMConnector.PoolTimeout = 0;
   COMConnector.MaxConnections = 0;
   
   Возврат COMConnector;
   
КонецФункции // ПолучитьКОМКоннектор82()

Зачем нужно устанавливать PoolCapacity и прочее уже точно не скажу) Вроде без них не взлетало...

(60) да у меня вроде и в первоначальном виде работает :-)
А в (58) вариант как можно сделать подключение "заново" (например с другим параметрами, к другому серверу и т.д.)... хотя если ножницами по кабелю - тут непонятно что делать

Мне нужно было, что бы соединение устанавливалось при начале работы и не разрывалось до момента пока базу не закроют. Иначе пришлось бы вставлять попытку нового соединения в кучу мест. А соединение не мгновенно устанавливается, меня при отладке это просто вымораживало, я представил, как будут бесится пользователи и просто не допускаю разрыва соединения. Раз в 10 мин. дергаю базу и соединение держится.

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