‎2010 Jan 07 9:40 PM
You set the headers of columns dynamically in CL_SALV_TABLE. However, when you modify the layout and then save it, some of the headings revert to the original ABAP Dictionary headings. Sometimes the changes to short text are lost and sometimes the medium and long text are lost.
Is this a bug which has been fixed by an OSS note? I wasn't able to find one. Or is it something I am missing when setting the key or something for the saved layout?
Many thanks for your help.
‎2010 Jan 08 3:55 PM
Are you setting column optimization to ABAP_TRUE? I see a difference in my column headings when I do that, as opposed to initial or false. Perhaps if you specifically control the width of the columns:
data:....
gr_column type ref to cl_salv_column_table
try.
get the column named in col_name variable.
gr_column ?= gr_columns->get_column( lv_col_name ).
catch cx_salv_not_found into gr_error.
concatenate 'Column name' lv_col_name 'not found.'
into lv_msg separated by space.
message lv_msg type 'I' display like 'E'.
endtry.
. . .
gr_column->set_output_length( '10' ). ", etc....
That might change the column titles behavior?
‎2010 Jan 08 3:55 PM
Are you setting column optimization to ABAP_TRUE? I see a difference in my column headings when I do that, as opposed to initial or false. Perhaps if you specifically control the width of the columns:
data:....
gr_column type ref to cl_salv_column_table
try.
get the column named in col_name variable.
gr_column ?= gr_columns->get_column( lv_col_name ).
catch cx_salv_not_found into gr_error.
concatenate 'Column name' lv_col_name 'not found.'
into lv_msg separated by space.
message lv_msg type 'I' display like 'E'.
endtry.
. . .
gr_column->set_output_length( '10' ). ", etc....
That might change the column titles behavior?
‎2010 Jan 08 8:14 PM
Hi Dave,
Thanks for that info. I do notice that some columns seem to keep their short text whilst others keep their medium or long text (based upon what is displayed when changing the column width).
I do use column width optimization because the whole report doesn't easily fit on the screen. And since user's are likely to adjust column widths as they scroll down the report I don't think that solution would be complete.
In desperation I reverted to the old funtion module which had a similar problem (not exactly the same) until I set reptext_ddic. Then it was stable. However, I have not been able to find a method which allows this field to be set in CL_SALV_TABLE.
Cheers, Kevin.
‎2010 Jan 08 10:55 PM
For FULLSCREEN ALV, Medium Text is being used as the REPTEXT_DDIC.
Method GET_SLIS_FIELDCATALOG in class CL_SALV_CONTROLLER_METADATA
ls_slis_fcat-seltext_s = ls_column-r_column->short_text.
ls_slis_fcat-seltext_m = ls_column-r_column->medium_text.
ls_slis_fcat-seltext_l = ls_column-r_column->long_text.
ls_slis_fcat-reptext_ddic = ls_column-r_column->medium_text. "Y7CK002776
For GRID (ALV created with Container, medium text being used as the REPTEXT.
Method GET_LVC_FIELDCATALOG in class CL_SALV_CONTROLLER_METADATA
ls_lvc_fcat-scrtext_s = ls_column-r_column->short_text.
ls_lvc_fcat-scrtext_m = ls_column-r_column->medium_text.
ls_lvc_fcat-scrtext_l = ls_column-r_column->long_text.
ls_lvc_fcat-reptext = ls_column-r_column->medium_text. "Y7CK002776
Regards,
Naimesh Patel
‎2010 Jan 09 12:42 AM
Hi Naimesh,
Thanks for replying to my question. I am not sure where your code snippets come from but perhaps they relate to an older version of ALV.
The class CL_SALV_CONTROLLER_METADATA seems to be an SAP internal class since there is no documentation and it doesn't seem to fit with class CL_SALV_TABLE.
However, I did try it and tried to modify the field catalog with method SET_SLIS_FIELDCATALOG but it didn't work at all.
Perhaps you could post a larger amount of the code so that I can see what else is being done.
Many thanks, Kevin.
‎2010 Jan 09 5:01 AM
Hi Kevin ,
If you wish to know that , how are long . short and medium texts are used in field catalog .
you can check for SALV* , select any report specific with column attributes.
you can find the code there,You can assign LONG, MEDIUM and Short text to any column using code avaliable.
Hope this helps you.
‎2010 Jan 09 6:50 PM
Hi Harsh,
Thank you for taking the time to reply.
More specifically, for anyone else reading this thread, you can view SALV_DEMO_TABLE_COLUMNS. But unfortunately it doesn't work. The column 'EXCEPT' should become 'MY EXCEPT' , 'MY EXCEPTION' and 'MY EXCEPTION COLUMN' for short, medium and long text respectively. It doesn't.
Thanks,
Kevin.
‎2010 Jan 09 10:14 PM
Hi Kevin,
if you change tzext, you should do do for short, medium and long text because SALV will determine which is to be used:
lv_scrtext_s =
lv_scrtext_m =
lv_scrtext_l = lv_description.
lv_colname = get_colname_4_column( <any> ).
TRY.
lr_column = lr_columns->get_column( lv_colname ).
lr_column->set_long_text( lv_scrtext_l ).
lr_column->set_medium_text( lv_scrtext_m ).
lr_column->set_short_text( lv_scrtext_s ).
CATCH cx_root INTO mo_exception.
ASSERT 1 = 2.
ENDTRY.If you set a longer text MY EXCEPT for original EXCEPT in the short text, SALV may switch to shorter medium text EXCEPT still present..
Regards,
Clemens
‎2010 Jan 10 2:26 AM
Hi Clemens,
Thank you for your response.
As you will see from previous posts, I have been setting all three text. However, in the old function module 'REUSE_ALV_GRID_DISPLAY' you also need to set reptext_ddic for it to work correctly. There doesn't seem to be any way to do this in the newer CL_SALV_TABLE class.
I thought the problem might be with the environment so I wonder if anyone could run the program SALV_DEMO_TABLE_COLUMNS in there environment and see if the first column has the correct header as it is expanded and shrunk. It should not be 'Exception' as it is in my case.
Regards,
Kevin.
‎2010 Jan 10 2:32 AM
Hi Clemens,
Thank you for your response.
As you will see from previous posts, I have been setting all three text. However, in the old function module 'REUSE_ALV_GRID_DISPLAY' you also need to set reptext_ddic for it to work correctly. There doesn't seem to be any way to do this in the newer CL_SALV_TABLE class.
I thought the problem might be with the environment so I wonder if anyone could run the program SALV_DEMO_TABLE_COLUMNS in there environment and see if the first column has the correct header as it is expanded and shrunk. It should not be 'Exception' as it is in my case.
Regards,
Kevin.
‎2010 Jan 10 11:41 AM
Hi Kevin,
I have no satisfying explanation. For me, SALV_DEMO_TABLE_COLUMNS works correct. You can and should run report BALVBUFDEL from time to time, especially if you have been playing with field catalog.
For reasons not to be discussed (here), parts of the field catalog are buffered in some secret dictionary tables and renewed not before the next day, So, possibly your trouble will not come today
Also in SALV, you can invoke the ALV consistency check within SALV: In the control, but outside the grid cell area, i.e. scroll to the righmost, right of the last column, hold down the right shift key and double-right-click. Weird? I haven't found out what kind of event (handling) this is, but it invokes the ALV consistency check. Here you have ample opportunity to check the field catalogs content at run time.
Apart from that, you may discover that the ALV consistency check itself has inconsistencies: An error is reported for internal type 'y' of field XSTRING. I think this is a coding error.
Some more coding inconsistencies report warning where they are to justified.
I think the encapsulation of the 'old' grid into the SALV was great work. It made the whole thing very complex so that we can hope, the developers will tale care of some remaining bugs. If, for instance, you use a table with fields without full dictionary reference, with direct type input but no domain, SALV will also create inconcictent field catalog.
This may be a result of wrong behavior of function 'DDIF_FIELDINFO_GET': It is called with
tabname = 'CHAR1'
fieldname = ''This does not make sense, but the SY-SUBRC is zero and the retrun table dfies_tab is empty. The program (SAPLSKBH, method check_fcat_ddic_exist) reads the table with index 1, does not care about sy-subrc and carries on with what was left in ls_dfies from the last succesful call. I'm afraid this will not be considered a severe error.
So, not everything is 100 % fine, but we can live with it. And report BALVBUFDEL.
Regards,
Clemens
‎2010 Jan 12 12:19 AM
Hi Clemens,
Are you saying that when you run SALV_DEMO_TABLE_COLUMNS the first column has the correct column name and changes as you expand the column?
Thank you for advising me about BALVBUFDEL. I will keep that in my toolbox but unfortunately, I have been fighting this issue for several days already so that won't solve it. Also, I haven't made any changes to the SALV_DEMO_TABLE_COLUMNS.
Your method of running the consistency check doesn't work for me but when I try it using the old method of calling transaction code &SOS from the print preview it short dumps on the colour definition field. The consistency check works OK for program SALV_DEMO_TABLE_COLUMNS but shows a lot of errors including multiple field cataloque entries for column 'EXCEPTION'. (Are you sure that work OK for you? Can you run the consistemcy check on that program and see if it is clean in your environment?)
Many thanks,
Kevin.
‎2010 Jan 12 10:43 AM
Hi Kevin,
The Exception column in my system does not show the text ('MY EXCEPT', 'MY EXCEPTION';'MY EXCEPTION COLUMN') as column header regardless of columns width. But i shows the text 'MY EXCEPTION COLUMN' as tooltip. Programs last change was 14.02.2005, so I think we have the same version. I don't get a dump, the header text is always 'EXCEPTION' regardless of column width.
I did not analyse all program code involved, just noted that CL_GUI_ALV_GRID has a last change date of 28.01.2008.
Actually, I never used that built-in Exception handling. I always create an icon column and put an icon ICON_RED/GREEN/YELLOW_LIGHT. I think the wrond columns heading results from that special exception use.
And, as I already mentioned, the consistency check is not fully consistent. The coding lead to unjustified errors
Data type of field BUTTON is different from the field catalog definition
Data type of field DROPDOWN_N is different from the field catalog definition
Data type of field EXCEPTION is different from the field catalog definition
Data type of field HOTSPOT is different from the field catalog definition
Data type of field HYPERLINK is different from the field catalog definition
Data type of field ICON is different from the field catalog definition
Data type of field SYMBOL is different from the field catalog definition
Strings can be displayed with 128 characters at most
Field XSTRING has a wrong value y in FCAT-INTTYPEBut I have no multiple entries for anything. Our system is
SAP_BASIS 700 0013 SAPKB70013 SAP Basis Component
SAP_ABA 700 0013 SAPKA70013 Cross-Application Component
PI_BASIS 2005_1_700 0013 SAPKIPYJ7D PI_BASIS 2005_1_700
ST-PI 2005_1_700 0005 SAPKITLQI5 SAP Solution Tools Plug-In
SAP_BW 700 0015 SAPKW70015 SAP NetWeaver BI 7.0
SAP_AP 700 0011 SAPKNA7011 SAP Application PlatformIf I run &SOS Fcode (I didn't know that, what is it?) in print preview, I get the same dump
The reason is, that in the grid the color column is defined type LVC_T_SCOL but the field-symbol <t_color> is type slis_t_specialcol_alv. The &SOS Fcode can not work for cell-colored grids.
You should not use the exception concept as proposed here by SAP. You are more flexible defining am ico-type colimn and setting the icons yourself. Then you are not limited to Light icon but may also use others.
And the header text issue will be reolved as well.
Regards,
Clemens
‎2010 Jan 20 11:51 PM
Kevin,
I'm having the same problem, and I've had it before. I usually end up changing the table field to a generic type to get rid of the DDIC reference. I found note 880921, but we have the support package already and the problem persists. Maybe it will work for you.
--Steve
‎2010 Jan 28 11:06 PM
Hi Steve,
Thanks for that info. We tried to implement the S/Note which had several prerequisite notes and although SNOTE shows them all as being implemented the code has not changed and the problem persists. We will persevere but in the mean time will continue to use the old functional method.
Kevin.