Странное поведение свойства mandatory

[RomanK]

Всем доброго вечера.
Задача, при изменении одного из полей в форме(LedgerJournalTransCost) необходимо в зависимости от значения устанваливать обязательность заполнения другого поля. Сначала пошел первым путем
ledgerJournalTrans_ds.object(fieldNum(LedgerJournalTrans, RContractAccountCredit)).mandatory(true);
Каково было мое удивление, когда я обнаружил, что поле просто подсвечивается волнистой красной линией, при этом обязательность заполнения не проверяется, можно спокойно сохранить запись не заполняя его

Если пойти другим путем установив свойство AutoDeclaration у контрола в yes, то выполняя код
RcontractCredit_RContractAccountCredit.mandatory(true);
Все работает как надо.
Это глюк или я что то не понимаю

П.с. kernel 4.0.2503.836
app 4.0.2501.347

в 2009 тоже так
похоже на баг

[RomanK]

Спасибо за ответ . очень жаль конечно, можно было один раз написать это дело в классе и потом вызывать для всех форм группы ledgerJournalTrans* , а так придется каждую из форм править

[oip]

Это видимо, фича, а не баг. Эта линия для того, чтобы просто "inform users". По-моему, так всегда было.

[RomanK]

Подведя итог делаем вывод. Установить для поле обязательное заполнение можно способами:
1. На таблице
2. На датасоурсе
3. установка для контрола значение AutoDeclaration в Yes.

[kornix]

Цитата:

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

Подведя итог делаем вывод. Установить для поле обязательное заполнение можно способами:
1. На таблице
2. На датасоурсе
3. установка для контрола значение AutoDeclaration в Yes.

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

[oip]

Цитата:

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

1. На таблице

Самый правильный способ.

Цитата:

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

2. На датасоурсе

Нехороший способ. Никогда его не использую. Вообще не люблю свойставами полей ДатаСорса пользоваться.

Цитата:

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

3. установка для контрола значение AutoDeclaration в Yes.

Совсем плохо.

Если нельзя поставить мандатори на таблице, то лучше добавить проверку в коде. Может даже в каком-нибудь validateWrite например. Может даже на табличном. И передавать туда параметр. Зависит от задачи.

Цитата:

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

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

тогда уж лучше на таблице/классе
но тогда красненьких волночек не будет

[AlGol]

Цитата:

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

написать это дело в классе и потом вызывать для всех форм группы ledgerJournalTrans* , а так придется каждую из форм править

Допиши проверку на заполненность в тот же класс и вызывай для validateWrite всех форм той же группы.

[kornix]

Цитата:

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

тогда уж лучше на таблице

ой.. извиняюсь Согласен.

[RomanK]

Цитата:

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

тогда уж лучше на таблице/классе
но тогда красненьких волночек не будет

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

И все таки раз зашел разговор о том что ставить свойство AutoDeclaration в Yes очень плохо, поясните почему.
На мой взгляд вполне неплохо потому что:
1. Уменьшается трудоемкость выполнения задачи
2. Код и поиск что же происходит с контролом более читабелен.

В чем минус? Противоречит Best practice?

на формах вообще чем меньше меняешь, тем лучше.
с апгрейдом проблем меньше

[oip]

Ставить Автодекларейшн в Yes - нормально во многих ситуациях. Но использовать свойство отдельновзятого контрола для недопущения незаполнения () поля уже неправильно. У вас поле на таблице должно быть заполнено в некотором случае, а не этот контрол. Вот придет кому-то в голову данное поле вынести еще и на другую закладку, например, и что? В одном случае оно будет мандатори, а в другом нет? Да и вообще на формах чем меньше меняешь, тем проще, лучше и правильнее.

Проверка должны быть в вашем случае в коде при сохранении записи. Вопрос только где этот код лучше писать.

[RomanK]

Отлично, спасибо за ясный ответ

[gl00mie]

Цитата:

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

можно было один раз написать это дело в классе и потом вызывать для всех форм группы ledgerJournalTrans* а так придется каждую из форм править

Ни в коем случае не надо править все формы подряд! Напишите (или допишите) движок управления формами (иерархию классов, если у вас несколько схожих "разновидностей" журналов) и движок с бизнес-логикой (тоже иерархию классов), который будет решать, когда поле обязательно к заполнению, а когда нет; в качестве основы можно взять LedgerJournalEngine, хотя в ряде случаев проще написать с нуля свое, чем вырезать из него "лишнее". Тогда движок управления формами будет получать от движка с бизнес-логикой данные о том, какие поля являются обязательными, и подсвечивать их для пользователя красной волнистой линией за счет изменения свойств полей DataSource'а, а движок с бизнес-логикой на validateWrite будет проверять, на самом ли деле обязательные поля заполнены. Причем заметьте: проверять заполненность полей только на записи строк журнала на форме недостаточно, потому что сегодня журнал создает пользователь, а завтра он будет создаваться из кода, так что как минимум все те же самые проверки нужно выполнять в классе разноски ваших журналов - тут вам опять пригодится движок, содержащий бизнес-логику.

Цитата:

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

Допиши проверку на заполненность в тот же класс и вызывай для validateWrite всех форм той же группы.

Однозначно - и не только на формах.

Цитата:

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

Ставить Автодекларейшн в Yes - нормально во многих ситуациях.

Разве что для unbound-контролов А для bound-контролов, по-моему, лучше всегда и везде использовать группы полей с AutoDataGroup = Yes. На счет AutoDeclaration хочется (скромно так) еще раз пропиарить Итератор с поддержкой методов обратного вызова для обработки контролов на форме, который как минимум для тех контролов, которые могут располагаться в Grid'е, практически избавляет от необходимости обращения к ним "по имени"

[S.Kuskov]

Цитата:

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

Странное поведение свойства mandatory

Уже было. formDataObject.mandatory(true)

Цитата:

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

Если нельзя поставить мандатори на таблице, то лучше добавить проверку в коде. Может даже в каком-нибудь validateWrite например. Может даже на табличном. И передавать туда параметр. Зависит от задачи.

Скажите, а как можно передать параметр в validateWrite?

[oip]

Цитата:

Сообщение от S.Kuskov

Скажите, а как можно передать параметр в validateWrite?

Так же, как и в любой другой метод. Перекрываем табличный validateWrite (если он еще не перекрыт), добавляем в него необязательный параметр и все. Какие проблемы? Или я вопрос не понял?

public boolean validateWrite(boolean _validateField2 = false)
{
    boolean ret;

    ret = super();

    if (_validateField2 && !this.Field2)
    {
        ret = checkFailed(strfmt("@SYS26332", new DictField(this.TableId, fieldNum(Table1, Field2)).label()));
    }

    return ret;
}

В стандарте полно примеров. Первое, что приходит на ум - таблица InventJournalTable.

[S.Kuskov]

Цитата:

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

Какие проблемы? Или я вопрос не понял?

А чем тогда такой перекрытый метод будет лучше мктода с другим именем? Вызывать же его прийдётся в ручную? Даже такая конструкция вроде бы не доступна

//validateWrite источника данных формы
boolean validateWrite()
{
    boolean ret;

//    ret = super(true); //Для функции было указано неверное число аргументов.
    Table1.validateWrite(true) // если только так

    return ret;
}

[oip]

Цитата:

Сообщение от S.Kuskov

А чем тогда такой перекрытый метод будет лучше мктода с другим именем?

Тем, что о данной возможности смогут узнать и другие разработчики, которые с этой таблицей будут работать в будущем. А если сделать какой-нибудь метод с названием mySuperMethod(), то уже через пару недель вы сами забудете, что он есть.

[RomanK]

Спасибо всем кто отписался, не стал городить новые классы тем более нашел что класс LedgerJournalFormTrans как раз занимается нужными мне полями. Указание пользователю что поле является обязательным для заполнения(подчеркивание) реализовано в этом класее, а проверку вынес в таблицу в validateWrite.