Комментарии
Избранное
Подписка
Сортировка:
Древо
(1) Спасибо. Действительно с "#Иначе" будет смотреться лаконичнее. По поводу "#Если Ложь" сам применял раньше такой подход, но он опасный, т.к. следующие выражения эквиваленты для препроцессора:
#Если Ложь
#Если Истина
#Если Штаны
Уже давно я попросил компанию 1С считать такие выражения некорректными, чтобы снизить вероятность скрытых опечаток, но пока они не стали этого делать.
#Если Ложь
#Если Истина
#Если Штаны
Уже давно я попросил компанию 1С считать такие выражения некорректными, чтобы снизить вероятность скрытых опечаток, но пока они не стали этого делать.
(2)
Похоже они таки услышали. Причем буквально.
Такой код даже не компилируются:
Зато спокойно компилируется и отрабатывает вот такой код:
платформа еще 8.3.8
Уже давно я попросил компанию 1С считать такие выражения некорректными, чтобы снизить вероятность скрытых опечаток, но пока они не стали этого делать.
Похоже они таки услышали. Причем буквально.
Такой код даже не компилируются:
#Если ИСТИНА Тогда
Сообщить("Истина");
#КонецЕсли
#Если Ложь Тогда
Сообщить("Ложь");
#КонецЕсли
Зато спокойно компилируется и отрабатывает вот такой код:
#Если Не МишкаКосолапый Тогда
Сообщить("Фигня");
#КонецЕсли
платформа еще 8.3.8
(6) ок. Еще раз.
Ошибка при сохранении:
{ВнешняяОбработка.ВнешняяОбработка1.Форма.Форма.Форма(5,8)}: Ошибка в операторе препроцессора
#Если <<?>>ИСТИНА Тогда (Проверка: Сервер)
{ВнешняяОбработка.ВнешняяОбработка1.Форма.Форма.Форма(7,3)}: Пропущен оператор препроцессора Если (If)
#<<?>>КонецЕсли (Проверка: Сервер)
{ВнешняяОбработка.ВнешняяОбработка1.Форма.Форма.Форма(5,8)}: Ошибка в операторе препроцессора
#Если <<?>>ИСТИНА Тогда (Проверка: Тонкий клиент)
{ВнешняяОбработка.ВнешняяОбработка1.Форма.Форма.Форма(7,3)}: Пропущен оператор препроцессора Если (If)
#<<?>>КонецЕсли (Проверка: Тонкий клиент)
когда должен выдавать ошибки препроцессор?
Если выдает ошибки при сохранении.
Если выдает ошибки при сохранении.
Ошибка при сохранении:
{ВнешняяОбработка.ВнешняяОбработка1.Форма.Форма.Форма(5,8)}: Ошибка в операторе препроцессора
#Если <<?>>ИСТИНА Тогда (Проверка: Сервер)
{ВнешняяОбработка.ВнешняяОбработка1.Форма.Форма.Форма(7,3)}: Пропущен оператор препроцессора Если (If)
#<<?>>КонецЕсли (Проверка: Сервер)
{ВнешняяОбработка.ВнешняяОбработка1.Форма.Форма.Форма(5,8)}: Ошибка в операторе препроцессора
#Если <<?>>ИСТИНА Тогда (Проверка: Тонкий клиент)
{ВнешняяОбработка.ВнешняяОбработка1.Форма.Форма.Форма(7,3)}: Пропущен оператор препроцессора Если (If)
#<<?>>КонецЕсли (Проверка: Тонкий клиент)
(10) они тем самым сделали еще больше проблем.
Вот такой код будет корректен, но никогда не выполнится:
А если перед ним написать:
Фигня = Истина;
то конфигуратор даже не среагирует. А при попытке открыть, выбросит исключение. Ведь снова получается:
#Если Истина Тогда
Да и любые комбинации, которые дают логическое значение, так же не будут работать.
Вот такой код будет корректен, но никогда не выполнится:
#Если Фигня Тогда
Сообщить("Фигня");
#КонецЕсли
А если перед ним написать:
Фигня = Истина;
то конфигуратор даже не среагирует. А при попытке открыть, выбросит исключение. Ведь снова получается:
#Если Истина Тогда
Да и любые комбинации, которые дают логическое значение, так же не будут работать.
(10)Самыми популярными должны быть слова вида
или так
То есть опечатки или просто не правильные имена (когда подразумевалось правильное имя директивы)
А вообще в 1С лучше бы ввели оператор как с С++ #define, чтобы можно было самому определять свои директивы (и самому же их обрабатывать), как-то так:
#Define MyOption ой, простите, - по русски:
"#ОПРЕДЕЛЕНИЕ МояОпция" можно дополнить и окончанием "#ОПРЕДЕЛЕНИЕ МояОпция #КОНЕЦОПРЕДЕЛЕНИЯ"
Было бы круто! Можно было бы самостоятельно код ветвить ещё на стадии компиляции....
Хотя.... тут нужно более чётко логику прорабатывать
С одной стороны хочется чтобы эти опции можно было бы устанавливать в момент выполнения программного кода (но тогда это не как с C++ #define), чтобы можно было программно опцию выставлять - но это уже не директива препроцессора - и формально это решается либо константами, либо функциональными опциями, либо даже параметрами сеанса, с приправой кешированием через модули повторного использования.
Если же делать их именно классическими сишными, т.е. определяемыми в момент компилирования - тогда встаёт вопрос - где их размещать, чтобы алгоритмы ветвления корректно отработали. Но это, в рамках логики 1С, не проблема - ведь можно же найти сначала все дефайны во всех модулях (ну или хотя бы общих модулях)- сразу их все определить и затем уже ветвить компилить алгоритмы всех модулей конфигурации (и внешних обработок/отчётов кстати тоже, но уже при их открытии-создании).
Можно и просто отдельный новый модуль завести - типа как "Модуль сеанса" (или именно его и использовать) - где можно было бы размещать такие определения директив (и нигде больше).
Кстати, можно было бы сделать и гибридный вариант - т.е. дать возможность управлять определениями программно - но только в специальном модуле - который отрабатывал бы только в момент компиляции конфигурации. Вообще - такая исполнение - ОГОНЬ было бы! Эдакий модуль первичной инициализации конфигурируемого решения!
Ну и ещё, такие определения хотелось бы вешать не только на код алгоритмов, но и на метаданные -
Добавил, например, измерение регистру, пометил его как использующее определение "МояОпция" на значение ИСТИНА - если при компиляции конфигурации оно будет определено как ИСТИНА - измерение будет добавлено в конфигурацию информационной базы. Иначе - его там не будет. Ну, а, соответствующим образом (через ветвление по этом определение), помеченные алгоритмы, сами разберутся, когда использовать это измерение, а когда не использовать.
Суперский был способ упрощать и оптимизировать сложные конфигурации - отключая не используемые механизмы или делая их более вариабельными, модульными ещё на этапе компиляции, а не исполнения.
Эх.... наверное никогда этого не дождёмся.... :-(
Хотя, знаете, именно сейчас, пока 1С не прикрыла работу такой лавочки
вполне можно было бы это всё реализовать самому - попросту прогоняя тексты модулей через свой внешний препроцессор и заменяя
на
Когда в каком-то модуле будет определно значения МояОпция = ИСТИНА
Как определить? Да хоть так
Формально для 1С это не исполняемый и не компилируемый текст, но свой препроцессор может вполне его правильно разобрать
Ну, аналогично можно и с метаданными конфигурации
Правда помещать пометку придётся в свойство "Комментарий", как то так
"#ЕСЛИ МояОпция=ИСТИНА #КОНЕЦЕСЛИ" без "ТОГДА" оно здесь не нужно
Ну, в общем, что-то я совсем от темы удалился....
Мне статья понравилась, узнал что такая конструкция может иметь место быть
#Если Север Тогда или так
&НаСервереНаКлиентеБезКонтекстаТо есть опечатки или просто не правильные имена (когда подразумевалось правильное имя директивы)
А вообще в 1С лучше бы ввели оператор как с С++ #define, чтобы можно было самому определять свои директивы (и самому же их обрабатывать), как-то так:
#Define MyOption ой, простите, - по русски:
#ОПРЕДЕЛЕНИЕ МояОпция
...
//где-то в далёком далёком модуле в одном месте алгоритма
#ЕСЛИ МояОпция ТОГДА
//некий алгоритм, завсящий от наличия выставленной опции МояОпция
#КОНЕЦЕСЛИ
Показать"#ОПРЕДЕЛЕНИЕ МояОпция" можно дополнить и окончанием "#ОПРЕДЕЛЕНИЕ МояОпция #КОНЕЦОПРЕДЕЛЕНИЯ"
Было бы круто! Можно было бы самостоятельно код ветвить ещё на стадии компиляции....
Хотя.... тут нужно более чётко логику прорабатывать
С одной стороны хочется чтобы эти опции можно было бы устанавливать в момент выполнения программного кода (но тогда это не как с C++ #define), чтобы можно было программно опцию выставлять - но это уже не директива препроцессора - и формально это решается либо константами, либо функциональными опциями, либо даже параметрами сеанса, с приправой кешированием через модули повторного использования.
Если же делать их именно классическими сишными, т.е. определяемыми в момент компилирования - тогда встаёт вопрос - где их размещать, чтобы алгоритмы ветвления корректно отработали. Но это, в рамках логики 1С, не проблема - ведь можно же найти сначала все дефайны во всех модулях (ну или хотя бы общих модулях)- сразу их все определить и затем уже ветвить компилить алгоритмы всех модулей конфигурации (и внешних обработок/отчётов кстати тоже, но уже при их открытии-создании).
Можно и просто отдельный новый модуль завести - типа как "Модуль сеанса" (или именно его и использовать) - где можно было бы размещать такие определения директив (и нигде больше).
Кстати, можно было бы сделать и гибридный вариант - т.е. дать возможность управлять определениями программно - но только в специальном модуле - который отрабатывал бы только в момент компиляции конфигурации. Вообще - такая исполнение - ОГОНЬ было бы! Эдакий модуль первичной инициализации конфигурируемого решения!
Ну и ещё, такие определения хотелось бы вешать не только на код алгоритмов, но и на метаданные -
Добавил, например, измерение регистру, пометил его как использующее определение "МояОпция" на значение ИСТИНА - если при компиляции конфигурации оно будет определено как ИСТИНА - измерение будет добавлено в конфигурацию информационной базы. Иначе - его там не будет. Ну, а, соответствующим образом (через ветвление по этом определение), помеченные алгоритмы, сами разберутся, когда использовать это измерение, а когда не использовать.
Суперский был способ упрощать и оптимизировать сложные конфигурации - отключая не используемые механизмы или делая их более вариабельными, модульными ещё на этапе компиляции, а не исполнения.
Эх.... наверное никогда этого не дождёмся.... :-(
Хотя, знаете, именно сейчас, пока 1С не прикрыла работу такой лавочки
#Если МояОпция Тогда
#КонецЕсливполне можно было бы это всё реализовать самому - попросту прогоняя тексты модулей через свой внешний препроцессор и заменяя
#Если МояОпция Тогда
...
#КонецЕслина
// так, увы, уже нельзя #Если ИСТИНА Тогда
#Если Сервер ИЛИ НЕ Сервер Тогда
...
#КонецЕслиКогда в каком-то модуле будет определно значения МояОпция = ИСТИНА
Как определить? Да хоть так
///#ОПРЕДЕЛЕНИЕ МояОпция = ИСТИНАФормально для 1С это не исполняемый и не компилируемый текст, но свой препроцессор может вполне его правильно разобрать
Ну, аналогично можно и с метаданными конфигурации
Правда помещать пометку придётся в свойство "Комментарий", как то так
"#ЕСЛИ МояОпция=ИСТИНА #КОНЕЦЕСЛИ" без "ТОГДА" оно здесь не нужно
Ну, в общем, что-то я совсем от темы удалился....
Мне статья понравилась, узнал что такая конструкция может иметь место быть
#Если Сервер И Не Сервер Тогда
&НаСервере
#Иначе
&НаКлиентеНаСервереБезКонтекста
#КонецЕсли
процедура какаято()....
(1) Не прокатывает такой вариант. Ложь - не нравится. Мишка косолапый в Штанах - лучше, но не то )
(0) Раз пошла такая пьянка, то можно вообще упроститься до
Платформа будто бы говорит "ой, всё! да вот вам чертов серверный контекст и не дурите голову!", предполагая что когда-нибудь этот бред все-таки не выполнится))
(0) Раз пошла такая пьянка, то можно вообще упроститься до
#Если Сервер Или Не Сервер Тогда
//#Если Клиент Или Не Клиент Тогда <<или так
&НаКлиентеНаСервереБезКонтекста
#КонецЕслиПлатформа будто бы говорит "ой, всё! да вот вам чертов серверный контекст и не дурите голову!", предполагая что когда-нибудь этот бред все-таки не выполнится))
(9) Да, действительно плохо проверил
У меня сработал такой вариант:
Только минус во всех этих подходах, что подсказка работает, но только для серверных методов, т.к. была объявлена директива &НаСервере.
У меня сработал такой вариант:
#Если А Тогда
&НаСервере
#Иначе
&НаКлиентеНаСервереБезКонтекста
#КонецЕслиТолько минус во всех этих подходах, что подсказка работает, но только для серверных методов, т.к. была объявлена директива &НаСервере.
(11) "Какие будут ваши доказательства?" (С) ))))
(17)
Это важное замечание.
Объявлять &НаСервере и не обязательно. Похоже что при наличии любых условий (##) такая директива добавляется в контекстной автоматом как директива по-умолчанию. Попробовал добиться, чтобы были видны клиентские методы (например, ПодключитьОбработчикОжидания) - вообще никак не получилось при любых вариациях с наличием условия (#Если + &НаКлиенте). Только при чистом &НаКлиенте видны.
Баловство это, но все равно интересно )
(17)
Только минус во всех этих подходах, что подсказка работает, но только для серверных методов, т.к. была объявлена директива &НаСервере.
Это важное замечание.
Объявлять &НаСервере и не обязательно. Похоже что при наличии любых условий (##) такая директива добавляется в контекстной автоматом как директива по-умолчанию. Попробовал добиться, чтобы были видны клиентские методы (например, ПодключитьОбработчикОжидания) - вообще никак не получилось при любых вариациях с наличием условия (#Если + &НаКлиенте). Только при чистом &НаКлиенте видны.
Баловство это, но все равно интересно )
(19) Не понял тебя. Заблуждаться в чем? Поясни примером.
Мои примеры "работают", все проверил... Т.е. у меня одно есть контекстная подсказка, больше ни у кого нет?
Такой пример дает серверную контекстную подсказку без объявления где-либо НаСервере. Отлично бесконтекстно выполняется при и при клиентском и серверном вызове.
Блин, в чем тут заблуждение????
Мои примеры "работают", все проверил... Т.е. у меня одно есть контекстная подсказка, больше ни у кого нет?
#Если Сервер Или Не Сервер Тогда
&НаКлиентеНаСервереБезКонтекста
#КонецЕсли
&НаКлиентеНаСервереБезКонтекста
#КонецЕсли
Такой пример дает серверную контекстную подсказку без объявления где-либо НаСервере. Отлично бесконтекстно выполняется при и при клиентском и серверном вызове.
Блин, в чем тут заблуждение????
(21) Наконец разобрался о чем ты пишешь...
Причина оказалась в версиях платформы.
Например, На 8.3.6.2390 подсказка в моем примере еще была, на актуальной 8.3.10 - уже нет.
Т.е. у меня одно есть контекстная подсказка, больше ни у кого нет?
Оказывается именно так.
Причина оказалась в версиях платформы.
Например, На 8.3.6.2390 подсказка в моем примере еще была, на актуальной 8.3.10 - уже нет.
(29)
В данном конкретном случае снегопат просто выводит в своём списке содержимое штатной контекстной подсказки. Определяется это просто - если рамка вокруг списка толстая - это список, который составляет сам снегопат. Если рамка тонкая - это перехваченный снегопатом штатный список.
В данном конкретном случае снегопат просто выводит в своём списке содержимое штатной контекстной подсказки. Определяется это просто - если рамка вокруг списка толстая - это список, который составляет сам снегопат. Если рамка тонкая - это перехваченный снегопатом штатный список.
(21) там весь прикол в том, что конструкция препроцессора не захватывает сам метод:
И в данном случае к контексту подсказки добавляется контекст по-умолчанию для модуля форм, т.е. &Сервер.
Если же #КонецЕсли будет после метода, то и контекст будет только тот, что указан препроцессору.
#Если Сервер Или Не Сервер Тогда
&НаКлиентеНаСервереБезКонтекста
#КонецЕслиИ в данном случае к контексту подсказки добавляется контекст по-умолчанию для модуля форм, т.е. &Сервер.
Если же #КонецЕсли будет после метода, то и контекст будет только тот, что указан препроцессору.
(18) С какого-то релиза платформы объявлять &НаСервере стало обязательно, иначе появляются ошибки при вызове РеквизитФормыВЗначение.
На ошибку нарвался буквально вчера в одной из обработок, которая раьше благополучно работала без этой инструкции..
На ошибку нарвался буквально вчера в одной из обработок, которая раьше благополучно работала без этой инструкции..
(43) Вот. Без директивы &НаСервере будет ошибка
Процедура УстановитьОграниченияТипа()
Попытка
ОбработкаОбъект = РеквизитФормыВЗначение("Объект");
РегистрационныеДанные = ОбработкаОбъект.СведенияОВнешнейОбработке();
Исключение
ОбщегоНазначенияКлиентСервер.СообщитьПользователю(
НСтр("ru = 'Возможно, обработка (отчет) устарела или не является дополнительной:'")
+ КраткоеПредставлениеОшибки(ИнформацияОбОшибке()));
Возврат;
КонецПопытки;
КонецПроцедуры
Показать
Помогите разобраться чем предложенный вариант будет отличаться от:
&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
НастроитьЭлементыФормы(ЭтаФорма);
КонецПроцедуры
&НаКлиенте
Процедура Реквизит2ПриИзменении(Элемент)
НастроитьЭлементыФормы(ЭтаФорма);
КонецПроцедуры
// ---------------------->>>
&НаСервере
Процедура НастроитьЭлементыФормы(ЭтаФорма)
Элементы = ЭтаФорма.Элементы;
Элементы.Реквизит1.Видимость = ЭтаФорма.Реквизит2;
КонецПроцедуры Показать
(34) Денис а разве не для того нужен режим &НаСервере чтобы настраивать форму прямо на сервере до возврата управления клиенту?
В противном случае нам за глаза хватило бы &НаСервереБезКонтекста передали нужные данные обработали, вернули на клиента и настраиваем форму как хотим :)
В противном случае нам за глаза хватило бы &НаСервереБезКонтекста передали нужные данные обработали, вернули на клиента и настраиваем форму как хотим :)
(38)
К сожалению, не понял как вы пришли к такому выводу, а может и к счастью.
(38)
Не нужно вырывать фразы из контекста. Речь идет о настройке формы. Например, смена доступности элемента. Или вы считаете, что для этого нужно обязательно бежать на сервер. А о политике 1С ничто не говорит лучше чем их официальные источники:
Как раз в этой заметке разработчики платформы признают, что не очень оптимально вызывать сервер для смены видимости элемента и начиная с 8.3.7 этот механизм перенесен на клиента.
Ни вижу смысла дальше развивать эту тему. Каждый случай индивидуален. И посему откланиваюсь
Вот послушали бы сейчас вас в 1с и убрали сразу два режима &НаСервере и &НаКлиентеНаСервереБезКонтекста...
К сожалению, не понял как вы пришли к такому выводу, а может и к счастью.
(38)
И кстати фраза "Зачем занимать ресурсы сервера" целиком и полностью противоречит текущей политике 1с :)
Не нужно вырывать фразы из контекста. Речь идет о настройке формы. Например, смена доступности элемента. Или вы считаете, что для этого нужно обязательно бежать на сервер. А о политике 1С ничто не говорит лучше чем их официальные источники:
Как раз в этой заметке разработчики платформы признают, что не очень оптимально вызывать сервер для смены видимости элемента и начиная с 8.3.7 этот механизм перенесен на клиента.
Ни вижу смысла дальше развивать эту тему. Каждый случай индивидуален. И посему откланиваюсь
(34) Реквизиты формы доступны на клиенте и на сервере. Менять их можно на клиенте и на сервере. Поэтому и настраивать свойства элементов формы после их изменения также хочется на клиенте и на сервере по возможности одинаково. Для этого я и делаю такой метод.
Также я понимаю, что не все изменения можно обработать без серверных вызовов. Такая обработка уже выполняется в обычном клиент-серверном стиле.
Также я понимаю, что не все изменения можно обработать без серверных вызовов. Такая обработка уже выполняется в обычном клиент-серверном стиле.
Не нужно вырывать фразы из контекста. Речь идет о настройке формы. Например, смена доступности элемента. Или вы считаете, что для этого нужно обязательно бежать на сервер.
Не пытайтесь спорить сами с собой...
Никто не говорил что нужно ОБЯЗАТЕЛЬНО бежать на сервер.
Речь идет о том что не обязательно ждать когда управление вернется клиенту.
Из всей дискуссии я понял, что мы тут занимаемся извращенными недокументированными возможностями.
А ведь 1С могла решить проблему подсказок одной конструкцией, о которой давно мечтаю - типизированием параметров методов.
Т.е. чтобы можно было описывать методы как-то так:
Процедура СделатьЧтоТо(Форма: УправляемаяФорма, Список: СписокЗначений)
Понятно, что язык 1С не строго типизированный, но это можно сделать не для ограничения типов параметров, а только для подключения подсказки.
А ведь 1С могла решить проблему подсказок одной конструкцией, о которой давно мечтаю - типизированием параметров методов.
Т.е. чтобы можно было описывать методы как-то так:
Процедура СделатьЧтоТо(Форма: УправляемаяФорма, Список: СписокЗначений)
Понятно, что язык 1С не строго типизированный, но это можно сделать не для ограничения типов параметров, а только для подключения подсказки.
(45) К сожалению, ты не вник в суть. Поэтому и дал такую поверхностную оценку В контекстной подсказке нужна не просто форма, а контекстная форма. Поэтому твоей конструкцией проблему не решить, а нужны именно инструкции (а не декларации) для контекстной подсказки.
(45) Кстати, есть в мире не строго типизированные языки, в которых параметрам функции можно добавлять описания ограничений (специальными выражениями) на передаваемые значения, эдакие условия - зачатки методологии "Контрактов". Такие функции нельзя вызвать с неправильным параметром - сработает встроенный механизм и сам выдаст соответстввующую ошибку с лаконичным пояснением. В то же время, наложение такого ограничение на параметр даёт возможность редактору формировать контекстную подсказку при работе с ними внутри таких процедур, а так же при их написании их вызова в другом месте. И для генерации документации тоже.
1С вполне могла бы так сделать, но пока она лишь ввела вывод подсказок параметров для места использования функций, из комментариев этих функций.
1С вполне могла бы так сделать, но пока она лишь ввела вывод подсказок параметров для места использования функций, из комментариев этих функций.
Раз пошла такая пьянка, то вот коллегам еще фишка:
В модуле формы можно спокойно объявить несколько функций с одним наименованием, если они все будут с директивой &НаКлиентеНаСервереБезКонтекста
Обнаружил это случайно при парсинге модулей ERP 2.4
Там в нескольких отчетах такая копипаста.
При вызове функции берется вроде как первая объявленная
В модуле формы можно спокойно объявить несколько функций с одним наименованием, если они все будут с директивой &НаКлиентеНаСервереБезКонтекста
Обнаружил это случайно при парсинге модулей ERP 2.4
Там в нескольких отчетах такая копипаста.
При вызове функции берется вроде как первая объявленная
(50) Сейчас проверил... Да, действительно, это жесть! Написал три метода:
Не ругается, при вызове выводит "1". Что-то разработчики платформы вообще "без контекста".
&НаКлиентеНаСервереБезКонтекста
Процедура ОдноИмя()
Сообщить(1);
КонецПроцедуры
&НаКлиентеНаСервереБезКонтекста
Процедура ОдноИмя()
Сообщить(2);
КонецПроцедуры
&НаКлиентеНаСервереБезКонтекста
Процедура ОдноИмя()
Сообщить(3);
КонецПроцедуры ПоказатьНе ругается, при вызове выводит "1". Что-то разработчики платформы вообще "без контекста".
Это все хорошо, и клиенты, и серверы. А вот как обходить проблему, что в обработках нет общего реквизита (в общем случае - общей таблицы данных), куда можно было бы писать общие перекрестные данные?
Реквизиты обработки - не видны на форме; реквизиты формы - не найдешь в другой форме и в общем модуле...
Реквизиты обработки - не видны на форме; реквизиты формы - не найдешь в другой форме и в общем модуле...
(68)
Не так. Без директивы в модуле формы УФ будет по-умолчанию "НаСервере"(Толстый клиент УФ файлового варианта не рассматриваем). Да, она будет доступна с клиента, но как серверный метод с контекстным вызовом.
Если не ставить директиву то будет и на сервере и на клиенте, разве не так?
Не так. Без директивы в модуле формы УФ будет по-умолчанию "НаСервере"(Толстый клиент УФ файлового варианта не рассматриваем). Да, она будет доступна с клиента, но как серверный метод с контекстным вызовом.
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.