Добрый день всем!

Есть редактируемый ALV, где пользователь корректирует записи, добавляет новые. На каждое его действие вызывается событие DATA_CHANGED, где можно прогнать всякие проверки, запихнуть сообщения в журнал - в общем, всё привычно.

Теперь представим, что при запуске ALV в табличке уже имеются кое-какие данные, которые подгружены, скажем, из внешнего источника. Как проверить их корректность аналогичным образом? Ведь пока пользователь к ним не прикоснётся, DATA_CHANGED не отработает. Надо как бы перебрать все ячейки и для каждой запустить DATA_CHANGED. Есть идеи?

Заверните все проверки в DATA_CHANGED в подпрограмму и запускайте в цикле. Если надо.

Попробуйте зарегистрировать событие DATA_CHANGED на кнопку ENTER, потом при запуске программы сделайте имитацию нажатия ENTERa(на форуме где видел такое обсуждение), может получится.

Зачем заниматься извращениями и делать не явную и не чёткую логику отчёта?
Если есть необходимость проверить строки вн.таблицы на непротиворечивость и консистентность , то следует реализовать проверку в виде метода\подпрограммы\ФМ. Если какие то части кода пересекаются с кодом в обработчике события DATA_CHANGED - вынести их в отдельные методы\подпрограммы\ФМ и вызывать по мере необходимости.
John Doe правильно написал.

Это всё верно, конечно. Просто редактируемый ALV предоставляет очень удобный интерфейс анализа ошибок ввода. Ошибки выкидывает в журнал во всплывающем окне, при двойном клике на ошибке фокус устанавливается в соответствующую ячейку. Ячейки с неправильно ведёнными данными подсвечены красными рамками.

Очень бы хотелось на этот механизм. Если сначала запустить проверку имеющихся данных, я пока не очень представляю, в какой форме вывалить ошибки… И как сделать так, чтобы пользователю было удобно с этим работать…

Это вообще идеологически не верно - почему это вдруг прочитанные данные имеют ошибки и вываивают на пользователя проблему приведения данных в нормальный вид? Значит где то дыра в интерфейсе доступа к данным, кто то где то пишет в таблицы без проверок и т.п.
А проверку можно "вываливать" в виде журнала (см. примеры отчётов SBAL_DEMO_*) + можно светофорчик в строку добавить.

Чисто теоретически можно сделать примерно так:
Позвать метод CHANGE_DATA_FROM_INSIDE.
Позвать метод CHECK_CHANGED_DATA.
Написать обработчик на событие DATA_CHANGED.
В нем выдрать эксземпляр ER_DATA_CHANGED класса CL_ALV_CHANGED_DATA_PROTOCOL.

Прогнать отдельно написанные проверки и заполнить протокол так, как душе угодно.

Да, так и есть: создаётся некий массив данных, который нужно затолкать, скажем, в БЕ. При этом пользователю предоставляется возможность подгрузить «рыбу» из другой БЕ и дополнить/отредактировать её. Здесь возможны ошибки – к примеру, какой-либо дебитор расширен на исходную БЕ, а на целевую – нет. Пользователь должен со всем этим разобраться. Исправить мелкие ошибки всяко быстрее, чем колотить с нуля. Но не суть.


Ход мыслей абсолютно верный! Попробовал всякие варианты, но есть один затык: после любых программных изменений (CHANGE_DATA_FROM_INSIDE, APPEND ROWS, изменение таблицы данных + REFRESH) не вызывается событие DATA_CHANGED. Не помогает ни CHECK_CHANGED_DATA, ни REFRESH_TABLE_DISPLAY… Изменения, естественно, в таблице видны.

Есть идеи?

Я бы реализовал следующую логику:
1. Выделил проверку одной записи в процедуру. Опция вывода ошибок на экран - отдельный параметр.
2. При загрузке данных для каждой строки, в произошла хотя бы одна ошибка, выставляется статус "Ошибка" (например с помощью "светофора")
3. Для пользователя предоставил бы возможность по даблклику на светофоре(или на всей строке) получить в отдельном окне протокол ошибок (повторный запуск процедуры)
4.В DATA_CHANGED сделать вызов той же процедуры, чтобы проверка отрабатывала и при изменении. Если после изменения ошибок не обнаружилось, менять статус на зеленый "светофор".

В общем, изрядно помучившись, вышел на реализацию:

1. Собираем данные во внутреннюю таблицу, скажем gt_data_to_load
2. Инициализируем* ALV Grid с ПУСТОЙ внутренней таблицей, скажем gt_data
3. После инициализации вызываем метод CL_GUI_ALV_GRID->APPEND_ROWS и передаём число строк в таблице gt_data_to_load. Затем сразу же вызываем CL_GUI_ALV_GRID->CHECK_CHANGED_DATA. Это приводит к тому, что в ALV добавляются пустые строки и мы вываливаемся в обработчик события DATA_CHANGED. Важно: до внесения пользователем изменений в таблицу ни в коем случае не вызывать REFRESH_TABLE_DISPLAY, а то потеряется лог ошибок! Почему это происходит, я так и не понял.
4. В обработчике события DATA_CHANGED напихиваем данных в ALV из таблицы gt_data_to_load с помощью CL_ALV_CHANGED_DATA_PROTOCOL->MODIFY_CELL.
5. После выхода из обработчика DATA_CHANGED оказываемся в коде сразу после вызова CL_GUI_ALV_GRID->CHECK_CHANGED_DATA. Данные, которые мы добавили в ALV, уже перенесены в таблицу gt_data (естественно, значения только тех ячеек, которые не скрыты и доступны для изменения). Скопировав недостающие данные (если нужно), убиваем таблицу gt_data_to_load – она нам больше не нужна. Далее работаем с gt_data.
6. Работаем в редактируемым ALV как обычно.

* Можно нарисовать экран с контейнером и в PBO инициализировать объект, я же предпочитаю полноэкранный ALV – вызов REUSE_ALV_GRID_DISPLAY_LVC, затем в первой обработке события ON_TOP_OF_PAGE получаем объект GO_GUI_ALV_GRID с помощью GET_GLOBALS_FROM_SLVC_FULLSCR. Для приведённого алгоритма никакой разницы нет. Единственное, полноэкранный ALV автоматически не даёт сохранить данные, пока в логе есть красные ошибки, - просто не допускает к обработчику нажания на дискетку. Это достаточно удобно, пользователь не может это обойти (в нарисованном ALV пользователям как-то удавалось загасить лог и сохраниться).