УФ Можно ли в модуле объекта вызвать функцию Вопрос? #744787

Можно ли в модуле объекта вызвать функцию Вопрос? Если нет, то может есть какой-то обходной путь?

МодульОбъекта выполняется на сервере. Кому ты там собрался задавать вопрос?

"Можно ли в модуле объекта вызвать функцию Вопрос?" - Йес. Если не отключен режим использования модальности. "Если нет, то может есть какой-то обходной путь" - Йес. Можно вызвать ПоказатьВопрос.

Ступил. Все в .

Пользователю. По старинке я бы прописал #Если Клиент Тогда    Вопрос(......) #КонецЕсли и все норм бы было. Как делается в УФ?

Не задавай вопросы в модулях объектов

А какому пользователю то? На сервере только бездушная машина.

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

Ну работа в 1с это ж не только все на сервере или все на клиенте, это постоянная смена клиента и сервера.

разделить процедуру на 2 части. Первая часть функция, выполнится. Ты на клиенте задашь вопрос и запустишь вторую часть процедуры.

Учитывая, что свою процедуру я вызываю из другой процедуры, которая в свою очередь на сервере. И все переносить на клиент - это овнокод какой-то получается.

На УФ надо сперва все спросить/узнать у пользователя, потом выполнять

В "МодульОбъекта" все выполняется на сервере и ни каких смен клинта и сервера нет.

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

+. Именно так

+1. В типовых неспроста общие модули наплодили, а ля "ПодборТоваровКлиент", "ПодборТоваровСервер" и их комбинации.

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

А где писать код Вопроса, чтоб он выполнился на клиенте? В форме?

Или в общем модуле процедуру с вопросом писать?

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

точнее "может выполняться на клиенте" ))

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

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

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

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

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

*а результат вопроса

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

А зачем столько всего? Когда нужно нажать стандартную кнопку печать и может быть потом еще кнопку да/нет(это мой вопрос). Зачем нагружать пользователя? Он же не печатает сразу кучу шаблонов. Печатается один договор, только зависит от условий какой именно.

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

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

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

, Это все так, вот только если на сервере - бездушная машина, как работает СообщитьПользователю в модуле объекта?

работает - не трогай (c)

Копит сообщения и выводит при возврате управления на клиента. см. ПолучитьСообщенияПользователю (GetUserMessages)

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

А так, в всё верно. Пока серверный алгоритм не закончит работу, на клиенте никаких сообщений не появится. Они потом все скопом упадут (после возврата управления на клиент вычитывается буфер сообщений). Штатно никакого асинхронного взаимодействия нет. О нем надо самому заботиться, если надо.

Перекинул свою процедурки в общий модуль, стал там делить на процедуры на клиенте и на сервере. Возникла проблема: в процедурах "на клиенте" не хотят вызываться процедуры "на сервере" ошибка выдается. Можно ли как то сделать, чтобы процедуры на сервере вызывались из процедур на клиенте?

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

галка вызов сервера у модуля стоит?

Стоит

Гонишь)

На серверные процедуры которые не вызываются на клиенте не ругается.

Вот текст ошибки "Процедура или функция с указанным именем не определена"

Нельзя: ... Доступность: Тонкий клиент, веб-клиент, толстый клиент, мобильное приложение(клиент). ...

+Пример кода: &НаКлиенте

Экспорт

Такую проверку можно реализовать на клиенте с помощью ПредопределенноеЗначение

Процедуры в одном модуле (но попробовал - не помогло) В справочнике итак предопределенные значения. Из-за того что Справочники. можно использовать только на сервере, пришлось заводить процедуру проверки на сервере. Или все-таки как-то можно ан клиенте это организовать?

Вбей в СП

Справочники (Catalogs) Использование: Только чтение. Описание: Тип: КоллекцияОбъектовМетаданных. Коллекция объектов метаданных, которые описывают все справочники, определенные в конфигурации. Элементами коллекции являются объекты типа ОбъектМетаданных: Справочник. Доступность: Сервер, толстый клиент, внешнее соединение, мобильное приложение(сервер).

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

Ага понял. С этим справился. Но есть процедура, которая все равно выполняется на сервере и вызывается из процедуры которая выполняется на клиенте. Что делать?

#Если Сервер Тогда сервернаяпроцедура #КонецЕсли

зачем ты все в одном модуле куяришь?

фу

А в скольки же это делать?

предлагаю сначала изучить в теории как нужно писать код в клиент-серверной архитектуре, потом посмотреть типовые конфигурации -УП2,УТ11,УНФ (там есть ответы на все вопросы)... тогда подобных вопросов не будет, в принципе

Зачем нужен вопрос, когда Сервер его не поймет? :)

Человек его поймет.

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

Тогда не используй клиент-серверную архитектуру, пока не поймёшь, как с ней работать.

А как ее обойти?

Толстый клиент, обычные формы, и нет проблем.

А как в управляемом приложении, переключится на выполнение кода под толстым клиентом и потом назад под управляемое приложение?

Вроде можно и упр формы + толстый клиент + условие(а может и не нужно оно точно не помню) Условие: #Если Клинет Тогда вопрос(...); #КонецЕсли

Надо запускать толстый клиент, переключаться нельзя.

какие месяцы, все проще чем ты думаешь. Вот например

Так не пойдет. У меня управляемое приложение.

Ну тогда тебе остаётся только .

+ Или уволиться.

Пробовал, просто пропускается код. Вообще не понятно зачем "#Если Клинет Тогда", если код тупо пропускается. В толстом клиенте все было понятно: В модуле выполняется процедура на сервере, но если вставляешь условие клиента, то для клиента выполнится код в теле условия. Тут не понятно какая логика. Читал, не помогло. Кто ж спасет Блр?)

Может я что то не понимаю, но в клиент-серверной архитектуре код "#Если Клиент Тогда..." вообще не имеет смысла

почему не имеет?

потому что распределение исполнения кода регулируется директивами и свойствами модулей

Они равнозначны.

а если модуль КлиентСервер?

А хотя бы одну книжку по УФ уже советовали прочитать?

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

пример из БСП:

директивы Клиент, Сервер и пр. вообще не только для того, что бы код без ошибок отрабатывал...

спасибо, в курсе

с таким успехом можно все модули сделать КлиентСервер и использовать мега конструкции, как в . Но смысл архитектуры теряется

Т.е. ты считаешь, что возможность создавать КлиентСерверный модуль это ошибка?

Нет, не считаю

В толстом клиенте был только один способ выполнить код именно на сервере - обратиться к процедуре общего модуля, который компилируется только на сервере и нигде больше. Во всех других случаях модуль компилировался на клиенте тоже и исполнялся тоже там. Ну, фоновые задания еще. Т.е. в типовом приложении 99,9% исполнялось на клиенте. Директивы компиляции работают абсолютно одинаково в обычном приложении и управляемом. Если модуль компилируется одновременно в нескольких ипостасях, то конструкции вида #Если позволяют модифицировать эти самые ипостаси. Всего лишь. На выбор ипостаси это не влияет НИКАК. Т.е. если у тебя стоит #Если Клиент, а исполняется серверная версия модуля (потому что вызов пришел с сервера), то этого куска там просто не будет.

От сервера к клиенту перейти нельзя? Если я допустим запустил процедуру выполняемую на сервере, то я уже не могу перейти в процедуру выполняемую на клиенте?

нет

Всем спасибо. Завтра продолжу изучение 1с УФ :)

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