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

   Запрос.УстановитьПараметр("Принят", Перечисления.ПричиныИзмененияСостояния.ПриемНаРаботу);
   Запрос.УстановитьПараметр("парамПриход", ВидДвиженияНакопления.Приход);

Меня бесит, что при переносе запроса в консоль запросов приходиться заполнять по 100500 ненужных параметров. А как вы думаете?

где сувалка?

(1) Не засунул. :-)

Засунул

Значение не всегда было...

(4) Читай внимательно "Эта замечательная функция появилась в 8.1.".

и в добавок, что в конструкторе запроса нет метаданных

Правильный кодинг.

Либо изменяешь параметры в одном месте, либо километровый запрос править

Сам делаю параметры, даже если в запросе сравнение на Булево.

Проще потом иногда бывает, даже на маленьких запросах время экономится.

Где нужно используется значение, а где не нужно - параметр. Все очевидно.

>Запрос.УстановитьПараметр("парамПриход", ВидДвиженияНакопления.Приход);
Разве это можно через ЗНАЧЕНИЕ записать?

(12) в запросе можно

я другого понять не могу, зачем вообще изобрели конструкцию
Остатки.Качество = ЗНАЧЕНИЕ(Справочник.Качество.Новый)
нельзя разве было придумать просто писать
Остатки.Качество = Справочник.Качество.Новый

(14) ну, типа, чтобы чотко отделить поля от констант

(8) можно в конструкторе вызвать конструктор и оттуда получить Перечисления.ПричиныИзмененияСостояния

(13) Можно.
(14) Тогда это обращение к таблице:

|ИЗ
|    Справочник.Организации КАК Организации

(14) Имя предопределенного элемента может совпадать с именем поля.

(18) да ну?

(9) Что можно менять в параметре:

Запрос.УстановитьПараметр("ПустойКонтрагент", Справочники.Контрагенты.ПустаяСсылка());

(20) Ну да. Запретов-то нет.

(22) ну и пофиг, все равно видно визуально

(13)(17) Блин, не знал. Век живи - век учись, я думал там только перечисления из метаданных можно, пустые ссылки и предопределенные элементы справочников.

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

ва

Я особо не парюсь по этому поводу, сам далек от совершенства :)

(25) не вижу разницы...

(28) Если большой запрос и параметр пользуется в нескольких местах, то проще параметром отладку делать. А потом уже запрос поправить.

(0)так палка о двух концах же. Если это значение подставляется в одном месте запроса, то твое негодование можно оправдать. Однако, если в нескольких, то тут уже спорный вопрос - замена такого значения на другое может потенциально привести к неполной замене. Проблема из разряда "Меджик намберс" - толи по коду разбрасываем одно и тоже значение (несколько мест для правки), толи параметром его подставляем (одно место).

Ну и к холивару, опять же, все может скатиться :)

(24) А ещё можно счета, планы видов характеристик, планы видов расчета.

(30) Ну кстати, сейчас подумал, что через параметр даже наверное самую малость быстрее может работать :)

(29), (30) Ваше мнение понятно, но читая то, что 0 описал, тут факт "Меня бесит"

(33) Мне индифферентно, скажем так... Я вапще спокоен как стадо бегемотов. Потому и проголосовал за Другое.

(34) Это фигуральное выражение.

(16) Можно подробнее?

(33)таже ситуация с Коллекция[<ИмяПоля>] vs Коллекция.<ИмяПоля> - бесит :)

(37)
ИмяПоля = "ИмяПоля";
ЫЫ = Коллекция[ИмяПоля];

А потом заменить все на
ИмяКоллекции = "ИмяКоллекции";
ИмяПоля = "ИмяПоля";
ЫЫ = Вычислить(ИмяКоллекции+"["""+ИмяПоля+"""]");

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

(0) Так а может это параметры по умолчанию, а потом объект запрос незаметно передается в какую нибудь процедуру, а та может установить какие нибудь другие параметры
Перечисления.ПричиныИзмененияСостояния.Перевод
и
ВидДвиженияНакопления.Расход
Например. А запрос-объект тот же самый

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

ЗначениеВФайл("С:\параметры.txt",Запрос.Параметры)

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

Пофиг. Я вот, например, не люблю метод .Заполнить(), хотя и знаю о нём. Люблю, когда значение каждого реквизита присваивается по рабоче-крестьянски. Так проще потом в отладчике найти.

(0) не встречал, но осуждаю

(43) Неужели есть принципиальная разница? Не, я понимаю, конечно, что "не академично" и всё такое... Но когда на каждое значение, которое хоть с какой-нибудь малой вероятностью может измениться, вводят переменную - я лично только рад. Может, дело в этом?

(1) Но мне больше не равиться, что в ТОРГ 12 не знают выбор когда (это про артикул или код)

какой-то опросник у вас профанский и рассуждения тож)

хотя вопрос от ленивого 1С-ка мог вызвать равноценные ответы от таких же ленивых

постулат о том, что они еще жадные и тупые мы пока забудем, мож сами поймете абсурд предъявы в сабже)

(0)
Ну... Может быть разработчики типовых почитывают Тома Кайта, в отличии от ТС?

автор дятел..

данный код был написан во времена 8.0
когда не было выражения "Значение"

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

а конструкторы кстати 1Совые когда ты взапросе укажешь переменную потом заботливо за тебя напишут

запрос.параметры.установить("виддокапоступления",виддокапоступления);

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


вывод: способ описанный в (0) который "типа бесит автора" - просто эргономичнее в процессе кодинга...

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

я тут был

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

нормально всё :)

Будь спокойнее.
Данная возможность появилась в 8.1
Разработчикам надо было кинуться и переписать все конфигурации?
Опять же, есть много разных причин почему писать именно так, а не иначе. Тут я согласен с (30).
Что-то тебе не удобно? ну напиши обработку, которая будет заменять такие параметры на "значение", это сделать не сложно.

(54) да понятно что ему не удобно - отлаживать в консоле, приходится заполнять параметры

Да разницы особой нет, все дело в удобочитаемости

с параметром запрос быстрее будет работать. По логике понятно, что там они сделали что-то, что бы ЗНАЧЕНИЕ не вычислялось в каждой записи, какой-то кеш там наверное, но на сто процентов не верю в это. Лучше написать старый добрый параметр.

В запросе не всегда сходу напишешь значение, вечно не могу сходу написать, параметрами проще...

(56) +1, иногда короткое и ёмкое название параметра читабелней чем длинное прямое указание константы. Особенно если встречается несколько раз.

&Интервалы
vs
ЗНАЧЕНИЕ(Перечисление.ПараметрыРаспределенияПокупателейПоСтадиямВзаимоотношений.ИнтервалыМеждуРасходнымиДокументами)

А иногда - наоборот.
Проблема и противопоставление надуманы, imho.

Вот ещё непонятный участок, привожу для сторонников параметров:

   Запрос.УстановитьПараметр("ОперацияВыполнена",        Перечисления.ВидыСостоянийРегламентныхОпераций.Выполнено);
   Запрос.УстановитьПараметр("ОперацияНЕВыполнена",    Перечисления.ВидыСостоянийРегламентныхОпераций.НЕВыполнено);
   Запрос.УстановитьПараметр("НеВыполнено",              Перечисления.ВидыСостоянийРегламентныхОпераций.НеВыполнено);
   Запрос.УстановитьПараметр("Выполнено",                Перечисления.ВидыСостоянийРегламентныхОпераций.Выполнено);

(52) Тебя расстрелять за излишнюю агрессию.

(0) а разве есть стандарт разработки на использование Значение()?
имхо.. на усмотрении разработчика, как удобнее ему.

Учитывая сроки разработки до каждого нового релиза порой нет времени думать о какой-то мегаоптимизации. Так что подобные случаи часты, и ничего раздражающего в них нет и быть не может. Кроме бОльшего количества букв такое объявление параметров запроса ничем не отличается от кода с использованием "Значение".

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

(0) "В одной и той-же конфигурации пользуются как старым, так и новым способом, причём в пределах одного запроса". Значит, знают.

это твои личные переживания.

Люди, ну нельзя же так. Почему все буквально понимают слово "бесит"? Каждый считает своим долгом зайти и проехаться по моим психическим переживаниям. Со мной всё в порядке. Слово "бесит" можно заменить на "доставляет неудобство".

(66) тебе за это платят

(66) какое неудобство? в чем оно проявляется?

+(68) хорошо. не будем зацикливаться на использованных определениях твоего негодования.

(68) Я уже писал. Когда запрос из отчета переносишь в консоль для отладки, то приходится вручную заполнять кучу параметров-перечислений и пустых ссылок. И даже автозаполнение параметров не всегда помогает.

сам недавно начал пользоваться. очень удобно.

(66) "доставляет неудобство" - значительно более правильная формулировка.

>> Разработчики типовых не знают о существовании "Значение"?

Об этом надо спросить у разработчиков. Ты наверняка уже писал в службу техподдержки. Что они тебе ответили?

+ к (72) голос забыл :)

(70) в (49) и (54) тебе очень хорошо ответили ребята. Не вижу смысла повторять их слова. Какую конфу интересно ты используешь, что тебе так часто приходится отлаживать запросы в консоли?

(72) :-)