Всем привет.
Возможно решение очевидное, просто у меня уже голова не варит, но возникла такая проблема.
Есть редактируемая ALV из 4 полей, для полей есть дропдаун список или справка по F4, формируемый динамически, в зависимости от выбранного значения в предыдущем столбце.
В таком случае нам необходимо использовать событие mc_evt_modified, чтобы иметь возможность реагировать на выбор значения из дропдауна.
При этом, на полях висит куча проверок, которые также надо производить, но только в момент сохранения, в момент редактирования пользователю это будет только мешать.

Был создан класс с методом для обработки события handle_data_changed, тут же реализованы все проверки по полям. Для выбора значений все работает, событие успешно отрабатывает.
Но возникает проблема, что в момент выбора значения из дропдауна в первом поле, также сразу же идут все проверки, в результате мы получаем протокол с кучей ошибок(т.к. оставшиеся столбцы даже не было возможности заполнить). Если же не делать все проверки сразу, то ALV считает что в этих полях ошибок нет(хотя они есть, просто до сохранения мы не хотим их выводить пользователю), и не будет их повторно проверять при вызове метода

Если же мы не используем событие mc_evt_modified, то тогда не удается успешно подменять допустимые значения для ввода, т.к. нет возможности понять когда пользователь выбрал какое либо значение.
Конечная цель следующая: в момент редактирования ALV мы реагируем только на изменение значений в ячейках, но не проводим валидацию значений. В момент сохранения же записей как раз таки и необходимо проводить валидацию с добавлением ошибок в протокол. Можно ли это как-то реализовать стандартной комбинацией событий/методов?

ну там как минимум придётся после mc_evt_modified refresh ALV-грида каждый раз делать, с позиционированием курсора на текущую запись (что еснно впустую будет расходовать ресурсы сервера приложений).
А сохранение и формирование проверочного отчёта по всем модифицированным позициям ALV повесить на отдельную кнопку.

Сомнительная это идея, использовать ALV в качестве ленточной формы ввода с динамикой.

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

В событии changed_data можете собирать номера/ключи изменённых позиций в табличку,
а проверять при сохранении и выдавать пользователю лог.

Реагировать можно по событию data_changed_finished. А валидацию делать вручную в момент сохранения.

Опять же получается, что валидацию нам надо делать вручную(запоминать какие строки человек вставил/удалил/изменил).
А хотелось бы использовать стандартных механизм, ведь в методе data_change alv возвращает нам все измененные строки. Но почему-то нет механизма(или я не нашел), который бы позволил отложить проверку этих строк, поэтому alv каждый раз считает что раз мы не записали ошибку в протокол по какому-то полю - то это поле заполнено корректно, и по нему ошибок не было.

отложить наверное нельзя потому, что интерактив блокирования дальнейшего ввода (до исправления ошибки) возникает тутже.
Если будет его откладывать напотом, через буферную таблицу например, то потом вам ещё придётся городить в ALV функционал визуализации ошибочных позиций (т.е. ячейки красным красить, или ещё какой огород).

Вобщем, вы изобретаете новое слово в интерфейсах ввода данных.
Обычно, ни к чему полезному, кроме увеличения объёма Z-сопровождения, подобная деятельность не приводит.
Используйте стандартные механизмы саповских экранов.

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

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

По личному опыту: быстрее, удобнее, проще и гибче сделать валидацию вручную, чем победить стандартный механизм обработчика data_changed.

а что там такого сложного в data_changed?
Он просто атипично (по саповским меркам) модально блокирует ввод в поле экрана, пока не исправишь.
Т.е. аналог например FIELD: f1,f2,f3 MODULE check_f1_f2_f3 на data_changed врядли получится реализовать - а такое сплошь и рядом в сложных проверках бывает, когда ошибка проверки возникает в следствии некорректного ввода в сразу несколько взаимозависимых полей, и чтобы её исправить, нужно править сразу два-три поля, а не одно единственное, в котором data_changed сработал.

И круто через /nex из такой проверки не выскочишь (в силу модальности)

О чём выше и речь, что изобретается квадратный велосипед.

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

В целом, касательно, сомнительности такого интерактива согласен, с ребятами которые написали выше.
Если есть время ковырятся, можно попробовать поиграться с этим (в событии data_change)

Повлиять на эти атрибуты(перезаписать их), соответствено механизм валидации должен также отработать по другому.

Например, был один случай, если правильно помню, при изменении значения в ячейки 1 строки 1, через изменение этих атрибутов, заставляли думать ALV движок, что также изменили строку 2, для того чтобы обновить автовычисляемые ячейки в строке 2, что то вроде формул в экселе, только зависимость была не в рамках одной строки, а в рамках всего АЛВ. Муть еще та, но вроде работало.

Или еще как вариант, отказаться от листбокса, заменить его на кнопку или линку, чтобы при выборе значения отрабатывало событие, чтобы была возможность запомнить выбранное значение при это не дергать DATA_CHANGE. Далее, уже как у Вас написано, зная значение, собирать динамически F4.