(1) Спасибо. Действительно с "#Иначе" будет смотреться лаконичнее. По поводу "#Если Ложь" сам применял раньше такой подход, но он опасный, т.к. следующие выражения эквиваленты для препроцессора:
#Если Ложь
#Если Истина
#Если Штаны
Уже давно я попросил компанию 1С считать такие выражения некорректными, чтобы снизить вероятность скрытых опечаток, но пока они не стали этого делать.
(3) Под "считать такие выражения некорректными" имелось ввиду, что препроцессор будет выдавать ошибки. Сейчас он их не выдает и просто считает все неизвестное равным ЛОЖЬ.
(4) когда должен выдавать ошибки препроцессор?
Если выдает ошибки при сохранении. Если сохранить, то при открытии:
"Ошибка в операторе препроцессора
#Если <<?>>ИСТИНА Тогда
Пропущен оператор препроцессора Если (If)"
Это кто ошибку дает?
(5) Препроцессор выдает (и должен выдавать) ошибки при проверке модуля (до проверочной или боевой компиляции). Если включена опция "Проверять автоматически", то будет проверять в частности при сохранении модуля.
(7) Проверил. Ты прав. Действительно теперь препроцессор ругается именно на "истина" и "ложь". Видимо мое пожелание реализовали как то частично (только для самых популярных слов).
(10) они тем самым сделали еще больше проблем.
Вот такой код будет корректен, но никогда не выполнится:
#Если Фигня Тогда
Сообщить("Фигня");
#КонецЕсли
А если перед ним написать:
Фигня = Истина;
то конфигуратор даже не среагирует. А при попытке открыть, выбросит исключение. Ведь снова получается:
#Если Истина Тогда
Да и любые комбинации, которые дают логическое значение, так же не будут работать.
(13) Начиная не помню с какой версии, нестандартные директивы компиляции трактуются как ошибки. Т.е. "Если Фигня" писать уже нельзя. Но, возможно, это накрыто режимом совместимости, и поэтому у некоторых компилируется без ошибок.
(71) Лучше чем что? Если это к приему из статьи, то это похоже на предложение заменить теплое на мягкое, т.е. предложение способа решения другой задачи.
(72) Не, извиняюсь, неясно выразился. Сам примем великолепный. Давно уже видел статью и пользуюсь им. Раз уж 1С не дает писать код красиво, то пусть будет хотя бы удобно. Просто опять наткнулся, проглядел и обратил внимание, что в этой же конструкции с сервера всегда вызывал настройку формы из ПриЧтенииНаСервере, а не ПриСозданииНаСервере. Непосредственно к самому фокусу с директивами вопрос никакого отношения не имеет. Собственно это был именно вопрос, а не замечание.
То есть опечатки или просто не правильные имена (когда подразумевалось правильное имя директивы)
А вообще в 1С лучше бы ввели оператор как с С++ #define, чтобы можно было самому определять свои директивы (и самому же их обрабатывать), как-то так:
#Define MyOption ой, простите, - по русски:
#ОПРЕДЕЛЕНИЕ МояОпция
...
//где-то в далёком далёком модуле в одном месте алгоритма
#ЕСЛИ МояОпция ТОГДА
//некий алгоритм, завсящий от наличия выставленной опции МояОпция
#КОНЕЦЕСЛИ
Показать
"#ОПРЕДЕЛЕНИЕ МояОпция" можно дополнить и окончанием "#ОПРЕДЕЛЕНИЕ МояОпция #КОНЕЦОПРЕДЕЛЕНИЯ"
Было бы круто! Можно было бы самостоятельно код ветвить ещё на стадии компиляции....
Хотя.... тут нужно более чётко логику прорабатывать
С одной стороны хочется чтобы эти опции можно было бы устанавливать в момент выполнения программного кода (но тогда это не как с C++ #define), чтобы можно было программно опцию выставлять - но это уже не директива препроцессора - и формально это решается либо константами, либо функциональными опциями, либо даже параметрами сеанса, с приправой кешированием через модули повторного использования.
Если же делать их именно классическими сишными, т.е. определяемыми в момент компилирования - тогда встаёт вопрос - где их размещать, чтобы алгоритмы ветвления корректно отработали. Но это, в рамках логики 1С, не проблема - ведь можно же найти сначала все дефайны во всех модулях (ну или хотя бы общих модулях)- сразу их все определить и затем уже ветвить компилить алгоритмы всех модулей конфигурации (и внешних обработок/отчётов кстати тоже, но уже при их открытии-создании).
Можно и просто отдельный новый модуль завести - типа как "Модуль сеанса" (или именно его и использовать) - где можно было бы размещать такие определения директив (и нигде больше).
Кстати, можно было бы сделать и гибридный вариант - т.е. дать возможность управлять определениями программно - но только в специальном модуле - который отрабатывал бы только в момент компиляции конфигурации. Вообще - такая исполнение - ОГОНЬ было бы! Эдакий модуль первичной инициализации конфигурируемого решения!
Ну и ещё, такие определения хотелось бы вешать не только на код алгоритмов, но и на метаданные -
Добавил, например, измерение регистру, пометил его как использующее определение "МояОпция" на значение ИСТИНА - если при компиляции конфигурации оно будет определено как ИСТИНА - измерение будет добавлено в конфигурацию информационной базы. Иначе - его там не будет. Ну, а, соответствующим образом (через ветвление по этом определение), помеченные алгоритмы, сами разберутся, когда использовать это измерение, а когда не использовать.
Суперский был способ упрощать и оптимизировать сложные конфигурации - отключая не используемые механизмы или делая их более вариабельными, модульными ещё на этапе компиляции, а не исполнения.
Эх.... наверное никогда этого не дождёмся.... :-(
Хотя, знаете, именно сейчас, пока 1С не прикрыла работу такой лавочки
#Если МояОпция Тогда
#КонецЕсли
вполне можно было бы это всё реализовать самому - попросту прогоняя тексты модулей через свой внешний препроцессор и заменяя
#Если МояОпция Тогда
...
#КонецЕсли
на
// так, увы, уже нельзя #Если ИСТИНА Тогда
#Если Сервер ИЛИ НЕ Сервер Тогда
...
#КонецЕсли
Когда в каком-то модуле будет определно значения МояОпция = ИСТИНА
Как определить? Да хоть так
///#ОПРЕДЕЛЕНИЕ МояОпция = ИСТИНА
Формально для 1С это не исполняемый и не компилируемый текст, но свой препроцессор может вполне его правильно разобрать
Ну, аналогично можно и с метаданными конфигурации
Правда помещать пометку придётся в свойство "Комментарий", как то так
"#ЕСЛИ МояОпция=ИСТИНА #КОНЕЦЕСЛИ" без "ТОГДА" оно здесь не нужно
Ну, в общем, что-то я совсем от темы удалился....
Мне статья понравилась, узнал что такая конструкция может иметь место быть
#Если Сервер И Не Сервер Тогда
&НаСервере
#Иначе
&НаКлиентеНаСервереБезКонтекста
#КонецЕсли
процедура какаято()....
(1) Не прокатывает такой вариант. Ложь - не нравится. Мишка косолапый в Штанах - лучше, но не то )
(0) Раз пошла такая пьянка, то можно вообще упроститься до
#Если Сервер Или Не Сервер Тогда
//#Если Клиент Или Не Клиент Тогда <<или так
&НаКлиентеНаСервереБезКонтекста
#КонецЕсли
Платформа будто бы говорит "ой, всё! да вот вам чертов серверный контекст и не дурите голову!", предполагая что когда-нибудь этот бред все-таки не выполнится))
(11) "Какие будут ваши доказательства?" (С) ))))
Картинка (17)
Только минус во всех этих подходах, что подсказка работает, но только для серверных методов, т.к. была объявлена директива &НаСервере.
Это важное замечание.
Объявлять &НаСервере и не обязательно. Похоже что при наличии любых условий (##) такая директива добавляется в контекстной автоматом как директива по-умолчанию. Попробовал добиться, чтобы были видны клиентские методы (например, ПодключитьОбработчикОжидания) - вообще никак не получилось при любых вариациях с наличием условия (#Если + &НаКлиенте). Только при чистом &НаКлиенте видны.
Баловство это, но все равно интересно )
(19) Не понял тебя. Заблуждаться в чем? Поясни примером.
Мои примеры "работают", все проверил... Т.е. у меня одно есть контекстная подсказка, больше ни у кого нет?
#Если Сервер Или Не Сервер Тогда
&НаКлиентеНаСервереБезКонтекста
#КонецЕсли
Такой пример дает серверную контекстную подсказку без объявления где-либо НаСервере. Отлично бесконтекстно выполняется при и при клиентском и серверном вызове.
Блин, в чем тут заблуждение????
(20) Возможно ты прав, но просто какие то еще влияющие инструкции не показал. Покажи полностью модуль и покажи контекстную подсказку через точку от ЭтаФорма.
Т.е. у меня одно есть контекстная подсказка, больше ни у кого нет?
Оказывается именно так.
Причина оказалась в версиях платформы.
Например, На 8.3.6.2390 подсказка в моем примере еще была, на актуальной 8.3.10 - уже нет.
(29)
В данном конкретном случае снегопат просто выводит в своём списке содержимое штатной контекстной подсказки. Определяется это просто - если рамка вокруг списка толстая - это список, который составляет сам снегопат. Если рамка тонкая - это перехваченный снегопатом штатный список.
(21) там весь прикол в том, что конструкция препроцессора не захватывает сам метод:
#Если Сервер Или Не Сервер Тогда
&НаКлиентеНаСервереБезКонтекста
#КонецЕсли
И в данном случае к контексту подсказки добавляется контекст по-умолчанию для модуля форм, т.е. &Сервер.
Если же #КонецЕсли будет после метода, то и контекст будет только тот, что указан препроцессору.
(26) Контекстный вызов это всегда вызов с клиента на сервер с синхронизацией данных формы. В статье же рассматривается локальный (без передачи управления на сервере) вызов с доступом к контексту формы.
(28) Извините настолько привык пользоваться только &НаСервереБезКонтекста что как-то в упор не увидел что у вас &НаКлиентеНаСервереБезКонтекста и что вызов с клиента вообще не будет трогать сервер... Спасибо за науку :)
(30) Ваше желание иметь одинаковый код на сервере и на клиенте мне понятно. Не понятно его целесообразность. Как часто вам приходиться настраивать форму с сервера минуя клиента?
(34) Денис а разве не для того нужен режим &НаСервере чтобы настраивать форму прямо на сервере до возврата управления клиенту?
В противном случае нам за глаза хватило бы &НаСервереБезКонтекста передали нужные данные обработали, вернули на клиента и настраиваем форму как хотим :)
(36) Нет. Сомневаюсь, что сакральный смысл режима &НаСервере настраивать форму для клиента. Зачем занимать ресурсы сервера на настройку формы коли сервер вы вызвали с клиента и туда же вернетесь.
(37) Вот послушали бы сейчас вас в 1с и убрали сразу два режима &НаСервере и &НаКлиентеНаСервереБезКонтекста... И кстати фраза "Зачем занимать ресурсы сервера" целиком и полностью противоречит текущей политике 1с :)
И кстати фраза "Зачем занимать ресурсы сервера" целиком и полностью противоречит текущей политике 1с :)
Не нужно вырывать фразы из контекста. Речь идет о настройке формы. Например, смена доступности элемента. Или вы считаете, что для этого нужно обязательно бежать на сервер. А о политике 1С ничто не говорит лучше чем их официальные источники: http://v8.1c.ru/o7/201505layout/index.htm Как раз в этой заметке разработчики платформы признают, что не очень оптимально вызывать сервер для смены видимости элемента и начиная с 8.3.7 этот механизм перенесен на клиента.
Ни вижу смысла дальше развивать эту тему. Каждый случай индивидуален. И посему откланиваюсь
(34) Реквизиты формы доступны на клиенте и на сервере. Менять их можно на клиенте и на сервере. Поэтому и настраивать свойства элементов формы после их изменения также хочется на клиенте и на сервере по возможности одинаково. Для этого я и делаю такой метод.
Также я понимаю, что не все изменения можно обработать без серверных вызовов. Такая обработка уже выполняется в обычном клиент-серверном стиле.
Не нужно вырывать фразы из контекста. Речь идет о настройке формы. Например, смена доступности элемента. Или вы считаете, что для этого нужно обязательно бежать на сервер.
Не пытайтесь спорить сами с собой...
Никто не говорил что нужно ОБЯЗАТЕЛЬНО бежать на сервер.
Речь идет о том что не обязательно ждать когда управление вернется клиенту.
Из всей дискуссии я понял, что мы тут занимаемся извращенными недокументированными возможностями.
А ведь 1С могла решить проблему подсказок одной конструкцией, о которой давно мечтаю - типизированием параметров методов.
Т.е. чтобы можно было описывать методы как-то так:
(45) К сожалению, ты не вник в суть. Поэтому и дал такую поверхностную оценку В контекстной подсказке нужна не просто форма, а контекстная форма. Поэтому твоей конструкцией проблему не решить, а нужны именно инструкции (а не декларации) для контекстной подсказки.
(46) А, в том смысле, что так в подсказке будут все методы и реквизиты формы как класса, но не будет конкретных реквизитов и элементов текущей нужной формы?
Да, это случай особый, но ту функцию, которую я описал, все равно иметь хочется. :-)
(45) Кстати, есть в мире не строго типизированные языки, в которых параметрам функции можно добавлять описания ограничений (специальными выражениями) на передаваемые значения, эдакие условия - зачатки методологии "Контрактов". Такие функции нельзя вызвать с неправильным параметром - сработает встроенный механизм и сам выдаст соответстввующую ошибку с лаконичным пояснением. В то же время, наложение такого ограничение на параметр даёт возможность редактору формировать контекстную подсказку при работе с ними внутри таких процедур, а так же при их написании их вызова в другом месте. И для генерации документации тоже.
1С вполне могла бы так сделать, но пока она лишь ввела вывод подсказок параметров для места использования функций, из комментариев этих функций.
Раз пошла такая пьянка, то вот коллегам еще фишка:
В модуле формы можно спокойно объявить несколько функций с одним наименованием, если они все будут с директивой &НаКлиентеНаСервереБезКонтекста
Обнаружил это случайно при парсинге модулей ERP 2.4
Там в нескольких отчетах такая копипаста.
При вызове функции берется вроде как первая объявленная
(50) Очень не хватает во встроенном языке 1С перегрузки.
Хотя бы в упрощенном варианте, с возможность объявлять подпрограмму с одним именем в двух вариантах: для сервера и клиента.
(63) это можно реализовать общими модулями.
А в модуле формы это невозможно из-за толстого клиента. В нем все на клиенте исполняется, соответственно получится дублирование процедур.
Это все хорошо, и клиенты, и серверы. А вот как обходить проблему, что в обработках нет общего реквизита (в общем случае - общей таблицы данных), куда можно было бы писать общие перекрестные данные?
Реквизиты обработки - не видны на форме; реквизиты формы - не найдешь в другой форме и в общем модуле...
Если не ставить директиву то будет и на сервере и на клиенте, разве не так?
Не так. Без директивы в модуле формы УФ будет по-умолчанию "НаСервере"(Толстый клиент УФ файлового варианта не рассматриваем). Да, она будет доступна с клиента, но как серверный метод с контекстным вызовом.