Проверка вводимого значения в управляющем элементе

[Metrofun]

Здравствуйте.
Axapta 3.0.
Задача проверять вводимое значение пользователем в управляющий элемент, например в IntEdit, и в случае выполнения определенного условия запрещать изменения значения.
Перекрыл метод modified, управляющего элемента.
Введённое значение не сохраняется, как и надо.
А как сделать чтобы значение было как до ввода пользователем?
public boolean modified()
{
boolean ret;

ret = super();

if (MyIntEdit.value() < 0)
{
ret = false;
info('Введённое значение меньше нуля!')
}

return ret;

}

[mazzy]

Цитата:

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

Задача проверять вводимое значение пользователем в управляющий элемент

Начнем с того, что задача в принципе неправильно поставлена.

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

проверять нужно значение, вводимое любым способом.

2.
неправильно проверять ОДНО отдельное значение.
часто в бизнес-логике есть взаимосвязанные значения.
например, при вводе строки общего журнала нужно выбрать тип счета и счет.
проверять счет без типа не имеет смысла

бывают более сложные случаи - параметры на вкладке Fixed Asset имеют смысл только если выбран тип Fixed Asset и код Fixed Asset.
Но вводить параметры на вкладках можно в любом порядке.



3.
Поэтому в Аксапте есть метод ValidateWrite на таблице.
Этот метод срабатывает, когда пользователь делает попытку сохранить запись (Ctrl+S, переход на другую строку в форме или закрыть форму),
когда программа вызывает ValidateWrite

В этом методе и нужно выполнить бизнес-проверку записи.

4.
если вам уж совсем надо проверить одно поле
то воспользуйтесь методом validateField на таблице.
там вам доступен this.orig() с оригинальными значениями полей

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

[Владимир Максимов]

Цитата:

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

4.
если вам уж совсем надо проверить одно поле
то воспользуйтесь методом modifiedField на таблице.
там вам доступен this.orig() с оригинальными значениями полей

Здесь опечатка Для проверки используются методы ValidateXXX. Для проверки одного поля ValidateField()


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

При этом методы на таблице-источнике ValidateXXX() будут вызваны автоматически если работа выполняется из формы. Однако не будут вызваны автоматически, если работа с данными выполняется программно. В этом и смысл. Проверка выполняется не всегда, а лишь тогда, когда в этом есть необходимость.

В объектах на форме это, соответственно, метод Validate() для проверки и Modified() для действий при изменении значения.

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


PS: Насчет значений меньше нуля для чисел есть настройка в свойствах ExtendedDataType с именем AllowNegative. Если там поставить No, то запрет отрицательных значений будет выполняться автоматически

[mazzy]

Опечатку исправил. Спасибо!

Цитата:

Сообщение от Владимир Максимов

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

полностью согласен.

Цитата:

Сообщение от Владимир Максимов

Где именно делать контроль - на форме или в методах таблицы - зависит от конкретной постановки задачи.

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

Если вам пришла такая поставнока, обязательно переспросите вашего постановщика о ботах, пакетных заданиях и надо ли выполнять проверку из кода. 99% - из кода проверять тоже надо.

Цитата:

Сообщение от Владимир Максимов

PS: Насчет значений меньше нуля для чисел есть настройка в свойствах ExtendedDataType с именем AllowNegative. Если там поставить No, то запрет отрицательных значений будет выполняться автоматически

Точно. Если можно сделать свойствами, а не проверкой - сделайте свойствами объекта в АОТ.

[Perc]

Два развернутых ответа, без ответа)
Очень здорово, что дали базовую теорию. А вот я например сталкивался с формой EcoResProductCreate от MS в акс2012. Там нет DS и полно validate и modified на контролах.

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

[Владимир Максимов]

Еще один ответ без ответа Вкратце, собственно ответ на задаваемый вопрос

Если метод Validate вернет false, то введенное значение будет отменено. Будет восстановлено значение, которое было до изменения

Modified - это действия после внесения изменений. Вернуть false он может. Но ведь значение уже изменено, поэтому на факт изменения это уже не повлияет. Хотя, конечно, можно поиграться контролем до и после super(), но лучше этого избегать

[Perc]

Цитата:

Сообщение от Владимир Максимов

Еще один ответ без ответа
Если метод Validate вернет false, то введенное значение будет отменено. Будет восстановлено значение, которое было до изменения

Что касается акс4, то зависит от того validate на контроле или на датасорсе.
Если на контроле, то в случае возврата false просто не выпускает. К первоначальному значению НЕ возвращает.

В акс2012 validate на conrol при возврате false тоже не выпускает, но возвращает первоначальное значение.

Так что автору с акс3, не факт что повезет с validate.