|
13.04.2018, 00:00 | #1 |
Участник
|
бесконечный цикл deleteMarked AX 2012 R3 CU13
это баг или я что-то пропускаю?
если на форме у источника данных таблицы перекрыть validateDelete() return true, а в delete вызывать validateDelete самой таблицы, то: - удаление одной, не отмеченной галочкой записи, не вызывает никаких проблем; - удаление хотя бы одной, отмеченной галочкой записи вызывает бесконечный цикл внутри deleteMarked(); WTF? Sequence of Method calls while deleting the record in the Form Form --- Datasource --- validatedelete () Table --- validatedelete () Table --- delete () Form --- Datasource --- active ()
__________________
Felix nihil admirari |
|
|
За это сообщение автора поблагодарили: Logger (1). |
13.04.2018, 01:16 | #2 |
Banned
|
Цитата:
_ds.validateDelete() вызывается системой автоматически из _ds.delete() источника данных. И как результат table.validateDelete() вызывается и так. C учетом того что система и так дергает на форме validateDelete() вызывать его там явно избыточно. Но в то же время и не запрещает и в каких-то случаях не создает проблем, так что и баг тоже. |
|
13.04.2018, 02:13 | #3 |
Участник
|
Цитата:
X++: public boolean validateDelete() { return true; } в смысле, что вот такой вариант X++: public boolean validateDelete() { return super(); }
__________________
Felix nihil admirari |
|
13.04.2018, 11:59 | #4 |
Banned
|
Явно неверно вручную вызывать какой-либо ValidateDelete() в _ds.Delete() вообще.
Я об этом. А так, да. Баг. Но и код table.ValidateDelete() в _ds.Delete() - это желание доломать Нечего делать этому методу таблицы на уровне формы. В любом случае. Если у нас есть foo1() --> foo2() -->foo3() --> foo4() то вызывать foo1() { foo3() } представляется хакерством. |
|
13.04.2018, 17:38 | #5 |
Участник
|
Цитата:
Сообщение от ax_mct
Явно неверно вручную вызывать какой-либо ValidateDelete() в _ds.Delete() вообще.
Я об этом. А так, да. Баг. Но и код table.ValidateDelete() в _ds.Delete() - это желание доломать Нечего делать этому методу таблицы на уровне формы. В любом случае. Если у нас есть foo1() --> foo2() -->foo3() --> foo4() то вызывать foo1() { foo3() } представляется хакерством. код этот, кстати говоря, стандартный и находится в форме Project WBS в части таблицы Estimates. можете попробовать выбрать несколько строк в ней и нажать "удалить". не понимаю, как пофиксить этот косяк, ибо явно идёт вызов из недоступного для редактирования класса в методе deleteMarked. надо проверить эффект в D365!
__________________
Felix nihil admirari |
|
|
За это сообщение автора поблагодарили: ax_mct (5). |
13.04.2018, 18:44 | #6 |
Banned
|
Цитата:
Сообщение от wojzeh
код этот, кстати говоря, стандартный и находится в форме Project WBS в части таблицы Estimates. можете попробовать выбрать несколько строк в ней и нажать "удалить". не понимаю, как пофиксить этот косяк, ибо явно идёт вызов из недоступного для редактирования класса в методе deleteMarked. надо проверить эффект в D365! Не вызывать validateDelete на форме Project WBS\Estimates если Estimates_ds,anyMarked или типа того?? |
|
13.04.2018, 18:49 | #7 |
Участник
|
Цитата:
конкретно в данной ситуации всё более чем кошерно: - отключаем валидацию на форме, чтоб не задавать вопроса о подтверждении, как доктор прописал; - перед непосредственным удалением методом delete проверяем, всё ли в порядке табличным валидатором; описанный подход - просто сказка! теоретическая дискуссия о том, что можно и нельзя, всегда упирается в конкретные потребности бизнеса и наши возможности их реализовать. можешь привести конкретный пример, где, как ты это называешь, "хакерство" приводит к плачевным последствиям?
__________________
Felix nihil admirari |
|
14.04.2018, 00:57 | #8 |
Banned
|
Цитата:
Сообщение от wojzeh
validateDelete не вызывает проблем - зовёшь ты его или нет. прочитай уже ВНИМАТЕЛЬНО, что написано.
конкретно в данной ситуации всё более чем кошерно: - отключаем валидацию на форме, чтоб не задавать вопроса о подтверждении, как доктор прописал; - перед непосредственным удалением методом delete проверяем, всё ли в порядке табличным валидатором; описанный подход - просто сказка! теоретическая дискуссия о том, что можно и нельзя, всегда упирается в конкретные потребности бизнеса и наши возможности их реализовать. можешь привести конкретный пример, где, как ты это называешь, "хакерство" приводит к плачевным последствиям? (1)_ds.delete() --> (2)_ds.validateDelete() --> (3) table.validateDelete() --> (4) table.delete(). Согласен что отключение super в (2) _ds.validateDelete() для отключения диалога - нормальный ход который по идее прерывает эту цепочку. Но судя по всему мы не контролируем эту цепочку в случае deleteMarked. deleteMarked() не вызывает _ds.delete(), а используется вместо. Что за цепочку методов он там использует - непонятно. Почему не вызывать табличный (3) table.validateDelete() на уровне таблицы в (4) table.delete()? Можно добавить if (.dataSource() && ) если нужно такое ограничить вызовами с формы. |
|
14.04.2018, 02:42 | #9 |
Участник
|
Если отказываетесь от удаления, то снимите выделение записи на удаление
X++: // На DataSource - формы public void delete() { if (false) { super(); } else { // Отказались от удаления. Снимаем метку, если она есть if (this.anyMarked()) { this.mark(0); } } }
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
|
За это сообщение автора поблагодарили: wojzeh (1), S.Kuskov (5), ax_mct (3). |
14.04.2018, 02:50 | #10 |
Участник
|
старик, ты - гений!
__________________
Felix nihil admirari |
|
Теги |
ax2012r3, delete, deletemarked, formdatasource |
|
|