бесконечный цикл deleteMarked AX 2012 R3 CU13

[ax_mct]

Цитата:

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

код этот, кстати говоря, стандартный и находится в форме Project WBS в части таблицы Estimates. можете попробовать выбрать несколько строк в ней и нажать "удалить".

не понимаю, как пофиксить этот косяк, ибо явно идёт вызов из недоступного для редактирования класса в методе deleteMarked. надо проверить эффект в D365!

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

Не вызывать validateDelete на форме Project WBS\Estimates если Estimates_ds,anyMarked или типа того??

[wojzeh]

Цитата:

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

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

Не вызывать validateDelete на форме Project WBS\Estimates если Estimates_ds,anyMarked или типа того??

validateDelete не вызывает проблем - зовёшь ты его или нет. прочитай уже ВНИМАТЕЛЬНО, что написано.

конкретно в данной ситуации всё более чем кошерно:

- отключаем валидацию на форме, чтоб не задавать вопроса о подтверждении, как доктор прописал;
- перед непосредственным удалением методом delete проверяем, всё ли в порядке табличным валидатором;

описанный подход - просто сказка!

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

можешь привести конкретный пример, где, как ты это называешь, "хакерство" приводит к плачевным последствиям?

[ax_mct]

Цитата:

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

validateDelete не вызывает проблем - зовёшь ты его или нет. прочитай уже ВНИМАТЕЛЬНО, что написано.

конкретно в данной ситуации всё более чем кошерно:

- отключаем валидацию на форме, чтоб не задавать вопроса о подтверждении, как доктор прописал;
- перед непосредственным удалением методом delete проверяем, всё ли в порядке табличным валидатором;

описанный подход - просто сказка!

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

можешь привести конкретный пример, где, как ты это называешь, "хакерство" приводит к плачевным последствиям?

Например вызов табличного валидатора в методе 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() && ) если нужно такое ограничить вызовами с формы.

[wojzeh]

Цитата:

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

deleteMarked() не вызывает _ds.delete(), а используется вместо. Что за цепочку методов он там использует - непонятно.

посмотри внимательно последнюю картинку в исходном сообщении и скажи, видишь ли ты, что ВЫЗЫВАЕТ? причём бесконечное количество раз, если не положить этому предел.

[ax_mct]

Цитата:

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

посмотри внимательно последнюю картинку в исходном сообщении и скажи, видишь ли ты, что ВЫЗЫВАЕТ? причём бесконечное количество раз, если не положить этому предел.

О, cупер, я ВИЖУ

MSDN пишет что
If no records have been selected, the FormDataSource.delete method is executed.
https://msdn.microsoft.com/en-us/lib...or=-2147217396

Но я вижу, что все интереснее. Получается что _ds.DeleteMarked() таки вызывает _ds.delete().

Но я бы переместил табличный validateDelete() в табличный Delete() так как есть чувство что
именно использование его на форме есть неприемлимый хак бага