|
22.10.2010, 16:31 | #1 |
Участник
|
Странное поведение свойства mandatory
Всем доброго вечера.
Задача, при изменении одного из полей в форме(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 Последний раз редактировалось RomanK; 22.10.2010 в 16:40. |
|
22.10.2010, 16:49 | #2 |
Гость
|
в 2009 тоже так
похоже на баг |
|
|
За это сообщение автора поблагодарили: RomanK (1). |
22.10.2010, 16:53 | #3 |
Участник
|
Спасибо за ответ . очень жаль конечно, можно было один раз написать это дело в классе и потом вызывать для всех форм группы ledgerJournalTrans* , а так придется каждую из форм править
|
|
22.10.2010, 17:08 | #4 |
Участник
|
Допиши проверку на заполненность в тот же класс и вызывай для validateWrite всех форм той же группы.
Последний раз редактировалось AlGol; 22.10.2010 в 17:10. |
|
22.10.2010, 16:58 | #5 |
Axapta
|
Это видимо, фича, а не баг. Эта линия для того, чтобы просто "inform users". По-моему, так всегда было.
|
|
22.10.2010, 17:01 | #6 |
Участник
|
Подведя итог делаем вывод. Установить для поле обязательное заполнение можно способами:
1. На таблице 2. На датасоурсе 3. установка для контрола значение AutoDeclaration в Yes. |
|
22.10.2010, 17:05 | #7 |
MCP
|
Можно попробовать перекрыть метод validateWrite на датасорсе и проверять заполнение поля программно, если пустое или заполнено некорректно - можно выбрасывать сообщение.
|
|
22.10.2010, 17:07 | #8 |
Гость
|
|
|
|
За это сообщение автора поблагодарили: kornix (1). |
22.10.2010, 17:08 | #9 |
MCP
|
|
|
22.10.2010, 17:13 | #10 |
Участник
|
Ага, подкрашивание сделать способом на который были возложены надежды
И все таки раз зашел разговор о том что ставить свойство AutoDeclaration в Yes очень плохо, поясните почему. На мой взгляд вполне неплохо потому что: 1. Уменьшается трудоемкость выполнения задачи 2. Код и поиск что же происходит с контролом более читабелен. В чем минус? Противоречит Best practice? |
|
22.10.2010, 17:06 | #11 |
Axapta
|
Самый правильный способ.
Нехороший способ. Никогда его не использую. Вообще не люблю свойставами полей ДатаСорса пользоваться. Совсем плохо. Если нельзя поставить мандатори на таблице, то лучше добавить проверку в коде. Может даже в каком-нибудь validateWrite например. Может даже на табличном. И передавать туда параметр. Зависит от задачи. |
|
22.10.2010, 17:16 | #12 |
Гость
|
на формах вообще чем меньше меняешь, тем лучше.
с апгрейдом проблем меньше |
|
22.10.2010, 17:17 | #13 |
Axapta
|
Ставить Автодекларейшн в Yes - нормально во многих ситуациях. Но использовать свойство отдельновзятого контрола для недопущения незаполнения () поля уже неправильно. У вас поле на таблице должно быть заполнено в некотором случае, а не этот контрол. Вот придет кому-то в голову данное поле вынести еще и на другую закладку, например, и что? В одном случае оно будет мандатори, а в другом нет? Да и вообще на формах чем меньше меняешь, тем проще, лучше и правильнее.
Проверка должны быть в вашем случае в коде при сохранении записи. Вопрос только где этот код лучше писать. |
|
|
За это сообщение автора поблагодарили: RomanK (1), (1). |
22.10.2010, 22:02 | #14 |
Участник
|
Цитата:
Цитата:
Разве что для unbound-контролов А для bound-контролов, по-моему, лучше всегда и везде использовать группы полей с AutoDataGroup = Yes. На счет AutoDeclaration хочется (скромно так) еще раз пропиарить Итератор с поддержкой методов обратного вызова для обработки контролов на форме, который как минимум для тех контролов, которые могут располагаться в Grid'е, практически избавляет от необходимости обращения к ним "по имени" |
|
22.10.2010, 17:21 | #15 |
Участник
|
Отлично, спасибо за ясный ответ
|
|
23.10.2010, 07:39 | #16 |
Участник
|
Уже было. formDataObject.mandatory(true)
Скажите, а как можно передать параметр в validateWrite? |
|
23.10.2010, 11:37 | #17 |
Axapta
|
Так же, как и в любой другой метод. Перекрываем табличный validateWrite (если он еще не перекрыт), добавляем в него необязательный параметр и все. Какие проблемы? Или я вопрос не понял?
X++: 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; } |
|
25.10.2010, 02:35 | #18 |
Участник
|
А чем тогда такой перекрытый метод будет лучше мктода с другим именем? Вызывать же его прийдётся в ручную? Даже такая конструкция вроде бы не доступна
X++: //validateWrite источника данных формы boolean validateWrite() { boolean ret; // ret = super(true); //Для функции было указано неверное число аргументов. Table1.validateWrite(true) // если только так return ret; } |
|
25.10.2010, 02:38 | #19 |
Axapta
|
Тем, что о данной возможности смогут узнать и другие разработчики, которые с этой таблицей будут работать в будущем. А если сделать какой-нибудь метод с названием mySuperMethod(), то уже через пару недель вы сами забудете, что он есть.
|
|
|
За это сообщение автора поблагодарили: S.Kuskov (1). |
25.10.2010, 12:59 | #20 |
Участник
|
Спасибо всем кто отписался, не стал городить новые классы тем более нашел что класс LedgerJournalFormTrans как раз занимается нужными мне полями. Указание пользователю что поле является обязательным для заполнения(подчеркивание) реализовано в этом класее, а проверку вынес в таблицу в validateWrite.
|
|