2023 Aug 02 9:18 AM
Hi Guys,
I'm facing the problem how to change the ALV Grid line color if something has changed in Grid. I show you my problem.
I use field to display my color:
line_color TYPE c LENGTH 4,
If condition is active i set the color
MOVE 'C700' TO gs_data-line_color.
So far so good, color is displayed. But if I now switch the condition that set the color in ALV grid, I want to remove the color after user changed the condition value for it. Therefor I use data_changed event.
CALL METHOD er_data_changed->modify_cell
EXPORTING
i_row_id = ls_good-row_id
i_fieldname = 'LINE_COLOR'
i_value = ''.
I thought just putting an empty value then to line_color would help and it looks like that value is really cleared, but nothing changed on ALV grid. There is also modify_style method but it looks like that it is only for cell color and not for line color. So how to change the line_color?
Regards
Michael
2023 Aug 02 4:20 PM
2023 Aug 02 4:27 PM
No I didnt do any refresh. With refreshing data in event data_changed_finished it works. But only there. In data_changed refresh does not have any impacts, I think because of data is not yet updated there when working with ALV Grid modify_cell methods.
But my goal is to do it without refresh. Normally in ALV grid change event I did table read of my data table into a field symbol and changed the field symbol value directly with the changes in mt_good_cells. After that I did refresh and everything worked, also the color fields.
But in this case I tried with only using ALV Grid standard methods, so no usage of field symbol, just change all the values with modify_cell method and do no refresh. SAP updates the grid values then without any refresh, dont know how it is done but it is done. But it only works for "normal" field inputs, not for the color column.
2023 Aug 02 6:45 PM
2023 Aug 02 6:48 PM
So, your question is about CL_GUI_ALV_GRID, in edit mode.
In the handler of the event DATA_CHANGED, you have to use the method er_data_changed->modify_style
METHOD on_data_changed.
er_data_changed->modify_style(
EXPORTING
i_row_id = 1
i_fieldname = 'PLANETYPE'
i_style = alv_style_color_positive ). " constant from the include <cl_alv_control>
ENDMETHOD.
2023 Aug 03 7:58 AM
That does not work. modify_style expects a RAW4 value so 8 digit number which is the same like in structure LVC_S_STYL which is used to set column color. But in my case I use row color to color the complete row and this is character 4 type which has values like C300, C400, etc.
2023 Aug 03 8:21 AM
Sorry, I answered for cell only, but why not doing it for all cells of the row, maybe not the exact solution you expect but at least it works.
2023 Aug 03 8:37 AM
Doing this code, the color of whole line is changed:
LOOP AT er_data_changed->mt_fieldcatalog REFERENCE INTO DATA(fcat).
er_data_changed->modify_style(
i_row_id = er_data_changed->mt_mod_cells[ 1 ]-row_id " first line changed
i_fieldname = fcat->fieldname
i_style = alv_style_color_positive ).
ENDLOOP.
2023 Aug 03 9:16 AM
Hm, interesting workaround. Do you have any idea what's the difference between cell and row colouring? Or how SAP ALV Grid does the renewing of cells without doing a refresh? Characteristical for refresh is the stucking of whole screen while "reloading" the data. When working with internal SAP methods like modify_cell this does not happen but fields are getting updated correctly. I did some debugging and found out that some 'SET_AUTO_REDRAW' method in Grid actually did the change of fields because after it the new values were displayed.
2023 Aug 03 1:03 PM
I think that it's what MODIFY_STYLE does, calling SET_AUTO_REDRAW.
I also think there's a good reason why the editable ALV Grid is officially NOT SUPPORTED, there are lots of flaws, risks of short dumps, etc., when using the CL_GUI_ALV_GRID methods (I don't know if it's the reason, but I find these methods difficult to use, buggy, need to use many tricks to make it work as you wish...)
2023 Aug 04 1:09 PM
So you prefer doing the grid change by your own like this?
lt_data_c = gt_data.
LOOP AT er_data_changed->mt_good_cells INTO ls_good.
READ TABLE gt_data ASSIGNING <ls_data> INDEX ls_good-row_id.
IF sy-subrc = 0.
ASSIGN COMPONENT ls_good-fieldname OF STRUCTURE <ls_data> TO <feld>.
IF sy-subrc = 0.
<feld> = ls_good-value.
ENDIF.
ENDIF.
IF ls_good-fieldname CS 'PLAN0'
OR ls_good-fieldname CS 'PLAN1'.
<ls_data>-planjahra = <ls_data>-plan01 + <ls_data>-plan02 + <ls_data>-plan03
+ <ls_data>-plan04 + <ls_data>-plan05 + <ls_data>-plan06
+ <ls_data>-plan07 + <ls_data>-plan08 + <ls_data>-plan09
+ <ls_data>-plan10 + <ls_data>-plan11 + <ls_data>-plan12.
ENDIF.
ENDLOOP.
IF gt_data NE lt_data_c.
gd_save = 'X'.
PERFORM alv_refresh.
ENDIF.
2023 Aug 04 1:29 PM
Not at all, but I don't get your question, is it linked to the colors?
2023 Aug 04 1:35 PM
No it was just an other example of me. I often created editable ALV and always coded it like the way above means with field symbol and refresh. Never got any problems with it, color, data update, totals, everything works fine. This time I tried with only SAP internal ALV Grid methods, also because I read that you should not do direct data update with field symbol, but it only causes problems as you see. So I'm wondering whats the best way.
2023 Aug 04 2:01 PM
2023 Aug 04 2:08 PM
Because there are so many flaws, maybe the best way would be to create a custom helper class to improve productivity, reduce risks, e.g.,
METHOD on_data_changed.
DATA(z_er_data_changed) = zcl_cl_gui_alv_grid_helper=>wrap_on_data_changed( er_data_changed = er_data_changed ... ).
z_er_data_changed->mt_good_cells->...
...
Design to be "thought thoroughly..."
2023 Aug 04 2:18 PM
Hm but for inserting and deleting rows of a grid, you have to do the refresh, right? The standard buttons do it without but as I can see there is no way to change the behaviour e.g. validations and field substitutions. I used my own duplicate and delete buttons for it but without refresh it was not possible to update the grid "internally".
2023 Aug 04 4:24 PM
Yes, a refresh, but that's outside DATA_CHANGED. Use DATA_CHANGED only to operate on data changed. You have other events. You can't just say that you always have to refresh when you change something, it depends.
2023 Aug 07 8:39 AM
Why not? In case of the Grid for this questions I now have a mix between DATA_CHANGED which only leads to a refresh in DATA_CHANGED_FINISHED when row color has to get updated and a refresh in USER_COMMAND for inserting and deleting rows. But I'm not really happy with it because I find it difficult for user to understand how action 1 leads to refresh and action 2 does not lead to refresh. OK normal standard user does not care about the difference as long as it works, but for me as developer I find different reaction of the same handling (something has changed) not that clean coding. And as said before I never had any problems when doing direct update of data table with help of field symbol and doing refresh after that. What speaks against it?