2012 Jul 12 9:15 PM
I’m using cl_gui_alv_grid, in input mode, to allow a user to edit rows of data. The user has the functionality to duplicate rows, though I need to reinitialize some fields on the dup. The reinitialization is done in a local method HANDLE_DATA_CHANGED_FINISHED.
So, let’s say I have three rows, and hit the dup button. When I get to HANDLE_DATA_CHANGED_FINISHED() , there are ‘n+1’ rows available. I loop through them and modify as needed – no problem.
Here’s the issue – some of the fields have domain level value validation. So, if the dup occurs and there is a bad value in a cell, the row is duplicated, a popup calls out the error, and the DATA_CHANGED_FINISHED event is NOT raised, so I’m not able to initialize my values.
I tried looking at handling the plain DATA_CHANGED event, but it only has ‘n’ rows available to it. I set a watchpoint on the output tab, but can’t catch where it goes plus one. Ideally, I’d like to just be able to allow the duplication, and set my values.
Alternatively, I’d like to stop the dup.
Any ideas?
2012 Sep 07 9:31 PM
I feel your frustration. In fact I avoid using DATA_CHANGED_FINISHED for exactly this reason. I still haven't figured out how to use that event appropriately...
When you say the DATA_CHANGED event "only has 'n' rows available to it" where are you looking? The CL_ALV_CHANGED_DATA_PROTOCOL instance passed into the event stores the table data in many different places, so if the inserted rows aren't available in one place, you should look for another. For example ER_DATA_CHANGED->MT_INSERTED_ROWS[]. Once you know the ROW_ID of the duplicated rows (hopefully they will be in MT_INSERTED_ROWS) you may be able to call ER_DATA_CHANGED->GET_CELL_VALUE to read field values in that row if necessary, and ER_DATA_CHANGED->MODIFY_CELL to set field values in that row (I believe you said that this is what you needed to do).
I feel your frustration. In fact I avoid using DATA_CHANGED_FINISHED for exactly this reason. I still haven't figured out how to use that event appropriately...
When you say the DATA_CHANGED event "only has 'n' rows available to it" where are you looking? The CL_ALV_CHANGED_DATA_PROTOCOL instance passed into the event stores the table data in many different places, so if the inserted rows aren't available in one place, you should look for another. For example ER_DATA_CHANGED->MT_INSERTED_ROWS[]. Once you know the ROW_ID of the duplicated rows (hopefully they will be in MT_INSERTED_ROWS) you may be able to call ER_DATA_CHANGED->GET_CELL_VALUE to read field values in that row if necessary, and ER_DATA_CHANGED->MODIFY_CELL to set field values in that row (I believe you said that this is what you needed to do).
2012 Sep 07 9:31 PM
I feel your frustration. In fact I avoid using DATA_CHANGED_FINISHED for exactly this reason. I still haven't figured out how to use that event appropriately...
When you say the DATA_CHANGED event "only has 'n' rows available to it" where are you looking? The CL_ALV_CHANGED_DATA_PROTOCOL instance passed into the event stores the table data in many different places, so if the inserted rows aren't available in one place, you should look for another. For example ER_DATA_CHANGED->MT_INSERTED_ROWS[]. Once you know the ROW_ID of the duplicated rows (hopefully they will be in MT_INSERTED_ROWS) you may be able to call ER_DATA_CHANGED->GET_CELL_VALUE to read field values in that row if necessary, and ER_DATA_CHANGED->MODIFY_CELL to set field values in that row (I believe you said that this is what you needed to do).
| User | Count |
|---|---|
| 3 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |