Событие -Кодеюнит, Кодеюнит - Событие!!!

[romeo]

Цитата:

Сообщение от by_HT

// Как мне в это случае В Этом Условие выйти из кодеюнита обратно в событие!

Гхм.. Вообще ERROR() используется в навижене для отката транзакции. Это гарантирует, что при критичной ошибке все действия по модификации данных в различных объектах будут корректно откачены назад. Что гарантирует корректную работу системы в целом. Коммитом вы не останавливаете все действия. Вы закрепляете в БД все изменения, которые сделал написанный до КОММИТА код. Вообще этот оператор нужно использовать очень осторожно. Когда вы полностью уверены в том, что хотите сделать и что делаете. А действия по остановке всех действий и корректному откату вызовет как раз оператор ERROR(). Этого будет достаточно для остановки. И еще. Применительно к вашему примеру .. Есть стандартный оператор TESTFIELD(). Использовать его вместо ERROR предпочтительно, потому что сообщение об ошибке более информативное и главное стандартное. Приучайте пользователей к адекватному восприятию СТАНДАРТНЫХ ситуаций, возникающих в системе.

Setup.TESTFIELD("Pattern Name");

[Corleone]

Цитата:

Сообщение от romeo

Использовать его вместо ERROR предпочтительно, потому что сообщение об ошибке более информативное и главное стандартное.

Setup.TESTFIELD("Pattern Name");

Ага, и сообщение будет типа Определите поле "Pattern Name" в таблице Setup, что для юзера то же самое что "Программа выполнила недопустимую операцию и будет закрыта".

[romeo]

Цитата:

Сообщение от Gmc

Ага, и сообщение будет типа Определите поле "Pattern Name" в таблице Setup, что для юзера то же самое что "Программа выполнила недопустимую операцию и будет закрыта".

Именно так. Только так. И пользователь программы Навижен должен привыкать ИМЕННО к этому, к такой реации системы. Этот оператор ОДНОЗНАЧНО определяет ключ записи и поле, значение в котором вызвало ошибку. К тому же сообщение об ошибке, присланное юзером разработчику даст последнему более исчерпывающую информацию и возможно сразу подскажет, в каком месте копать..

Цитата:

Сообщение от TRIgor

В том то и дело, что время дорого . А что касается MESSEGE. То я так понял человеку нужно дальше выполнение кода. Вот и предложил вариант, иначе написал, что при ERROR идет откат всех выполненных действий до него.

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

[Corleone]

Цитата:

Сообщение от romeo

Именно так. Только так. И пользователь программы Навижен должен привыкать ИМЕННО к этому, к такой реации системы. Этот оператор ОДНОЗНАЧНО определяет ключ записи и поле, значение в котором вызвало ошибку. К тому же сообщение об ошибке, присланное юзером разработчику даст последнему более исчерпывающую информацию и возможно сразу подскажет, в каком месте копать..

Это не user friendly. Это сообщение для прораммистов C\AL как говорится... Юзеру наду указать на его ошибку, а так любой юзер считает что ошибка вызвана системой. Просто ты принимаешь действительность такой какая она есть. Есть Navi какашка, пусть и привыкают.

[romeo]

Цитата:

Сообщение от Gmc

Это не user friendly. Это сообщение для прораммистов C\AL как говорится... Юзеру наду указать на его ошибку, а так любой юзер считает что ошибка вызвана системой. Просто ты принимаешь действительность такой какая она есть. Есть Navi какашка, пусть и привыкают.

Это сообщение системы. Стандартное. Юзеров много и быть с каждым из них friendly .. А еще некоторые, чтобы быть ближе к пользователям делают отмену учета вместо использования стандартных средств коррекции. Некоторые прописывают юзеров, с которыми нужно быть особенно friendly прямо на открытие форм в строке фильтра .. Ну не заводить же для этого новое поле в таблице Менеджер, выводить это поле в карточку Менеджера и обязать пользователям ставить эту галку кого-то ...

[Corleone]

Цитата:

Сообщение от romeo

Это сообщение системы. Стандартное. Юзеров много и быть с каждым из них friendly .. А еще некоторые, чтобы быть ближе к пользователям делают отмену учета вместо использования стандартных средств коррекции. Некоторые прописывают юзеров, с которыми нужно быть особенно friendly прямо на открытие форм в строке фильтра .. Ну не заводить же для этого новое поле в таблице Менеджер, выводить это поле в карточку Менеджера и обязать пользователям ставить эту галку кого-то ...

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

[romeo]

Цитата:

Сообщение от Gmc

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

У нас разные стили работы. Спорить здесь неуместно. Каждому свое.