forum.clarionlife.net

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

Вот на недавнем примере. Как Вы решили вопрос с выдачей сообщения, если после редактирования/добавления запись не попадает в условия браузера? Используя заточенные под свои стандарты разработки шаблоны это делается минут за 30 (с запасом, специально не засекал). И это будет сразу работать во всех браузерах, используемых в проектах, а также в браузерах, которые в дальнейшем будут добавлены. Сделал раз и забыл.

1. Полностью с Вами согласен, что есть задачи для которых изменение шаблонов идеальное решение.
Например, если нужно на закладке карточки показать иконку с режимом её работы (просмотр, добавление, изменение и т.д.)
Мне для этого нужно будет вручную изменить все FORM, а Вы бы реально решили бы задачу через шаблоны за полчаса ...

2. Я рад, что Вам понравился пример с добавлением записи в спискок - но общее решение там немного иное ...
Любой список открываемый в потоке должен быть полностью изолирован и получать данные только через Notify / Event.
Т.е. при открытии он получает все настройки для работы, в т.ч. и рабочую дату для FORM.
И вот тогда описанная мною "проблема" не возникает в принципе, но там есть некоторые рабочие нюансы ...

Ничего не понял, кроме слов notify и event.

Давайте так.
1. Форма открывается в том же потоке, что и браузер?
2. Установите фильтрацию в браузере, откройте форму на редактирование, сделайте так, что после изменений запись перестаёт удовлетворять условиям фильтрации и "улетит" из списка отображаемых записей. Вот здесь мы хотим сообщить пользователю о данной коллизии. Речь про такую ситуацию была.

finsoftrz писал(а): 13 Июнь 2024, 7:32 кроме слов notify и event

И не заставляйте себя. Для этого нужно желание понять - как например у меня с алгоритмом нечёткого поиска.

finsoftrz писал(а): 13 Июнь 2024, 7:38 Вот здесь мы хотим сообщить пользователю о данной коллизии

Всё абсолютно верно ! Но ведь есть ещё вариант в котором можно просто избежать коллизии.

finsoftrz писал(а): 13 Июнь 2024, 7:38 Форма открывается в том же потоке, что и браузер

В общем случае это не имеет значения.
Открываемое окно (процедура) всегда наследует окружение родительского окна (процедуры).
Всё тоже самое, что и при создании нового класса на основе существующего, когда изначально SELF = PARENT.

Если утрировать - то FORM получает все настройки окружения из BROWSE, а не из БД или компьтера (ToDay() и т.д.)
Поэтому FORM, по умолчанию, просто не может влепить запись за пределами периода родительского окна.

Может быть не только период. Например, qbe фильтр или альтернативный отбор в зависимости от активной закладки. Вы все это хотите передавать в форму, а там вручную отслеживать значения? Или рассматриваете только кастрированный вариант с передачей периода?

finsoftrz писал(а): 13 Июнь 2024, 8:17 Или рассматриваете только кастрированный вариант с передачей периода

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

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

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

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

Игорь Столяров писал(а): 12 Июнь 2024, 18:51 Красненьким обвёл удобную опцию управления потоками, остальные различия просто видны.

А что она делает?

finsoftrz писал(а): 13 Июнь 2024, 8:48 А Вы при попытке копирования шлете его лесом...

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

Игорь Столяров писал(а): 13 Июнь 2024, 10:23

finsoftrz писал(а): 13 Июнь 2024, 8:48 А Вы при попытке копирования шлете его лесом...

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

Я реально не понимаю Вас. Неужели нельзя писать конкретику, а не общие фразы? Это вот кто написал и как это понимать?

Если утрировать - то FORM получает все настройки окружения из BROWSE, а не из БД или компьтера (ToDay() и т.д.)
Поэтому FORM, по умолчанию, просто не может влепить запись за пределами периода родительского окна.

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

Я не могу толковать каждое слово или как в соседнем посте учить мужиков по картинкам нажимать F1.

Так Вы запрещает или не запрещаете ввод даты документа за пределами периода просмотра в журнале документов? Вивиан, это да или нет? (с) Красотка.

finsoftrz писал(а): 13 Июнь 2024, 10:55 Так Вы запрещает или не запрещаете ввод даты документа

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

То есть, если текущая дата не в установленной периоде, то по умолчанию ставится другая, но пользователь волен сам её поменять на не попадающую в период. Правильно? А какую в этом случае подставляете дату по умолчанию? Начало и конец периода могут быть самыми разными.