I have a table in my report header (since my datasource is bound to the report). The cells in the row of the table all have conditional formatting to give the table a striping effect. The number of columns in the table will differ based on a parameter of the report. However, in the case when I have two of the columns (that are right next to each other) hide at the same time, there is a slight vertical line (maybe 1px?) that appears. Is this a known bug or am I maybe doing something wrong?
I've attached three screenshots:
1. The design mode
2. A correct rendering where the line didn't appear (and no hiding was taking place)
3. An incorrect rendering where the line is appearing (and the hiding is occurring)
I am using conditional formatting to control the visibility of these fields. They are all set to Visible = True and then the conditional formatting sets the visibility through the Layout section.
5 Answers, 1 is accepted
The issue is reproducible with the described scenario for zoom levels > 100%. It is related to pixel rounding upon rendering the Table and the specifics of the EMF image file format we use internally.
Currently we cannot offer a workaround to avoid the issue.
Yeah, that's too bad, but thanks for the confirmation. I wasn't adjusting the zoom - I was just using the API to generate a PDF. I used that same approach in SSRS and it worked flawlessly there, so that's disappointing that similar functionality isn't available with Telerik Reporting.
I was, however, able to overcome this by taking a different approach. I used the binding on the header and another column to increase the width instead of hiding/unhiding extra columns.
We're glad you managed to resolve the current issue. However, it is not recommended to change the items structure at runtime. In the current scenario I would suggest to change the report definition prior to report processing and right after report instantiation. The report parameter that determines the layout of the table should be represented by external UI element. Its value can be passed to a report constructor that would change the table structure as needed. This way the table columns will be defined before processing the report and the issue in question would not appear.
Sorry for being vague. The suggested idea was not to use a report parameter, defined in the report - this would lead to the same result that you already observe. Instead, the parameter that controls if the table should display or hide these two columns, could be passed as an argument to the report constructor. Its values can be obtained via external UI control. For example in a WinForms scenario it would look like this:
The report constructor that accepts the boolean argument could do the necessary changes to the report definition like this:
This way the report is changed right after its initialization, removing the unnecessary columns from the definition, so they won't be processed at all. Here the table columns and groups are referred by their indexes, and the sell contents are rearranged just as it is done in the report's .designer.cs file.
Hope this helps.