Problems dynamically generating sub report

[Paul]

Hi All

I have a sub report and in the NeedDataSource event I extract my data.
For each row I loop through the columns collection and if that column contains any text I create a textbox on the fly and add it to the report. Each row appears on a new page.

This all works fine apart from one major issue.

• If the first row contains 6 columns containing text then I generate 6 textboxes.
• If the second row only has 4 columns containing text then I add 4 textboxes but an additional 2 empty textboxes appear at the end.
  

I am assuming that these textboxes are remnants from the previous iteration but for the life of me I cannot get a handle on them.
Is there any way I can get a handle on the current page of the sub report so I can remove these empty textboxes?

[Chris Gillies]

If I read your description right, you're trying to report your data manually. Yes, when you create multiple rows as per the data record count, you're doing the job of the report engine. In short you're using the product wrong, the report definition (Telerik.Reporting.Report) is a template, which has a detail section, which is repeated similarly to a repeater depending on the data it is bound to (see Understand the Why, What and How of Reporting Solutions for further info). The report items added to the definition (definition items) are repeated along with the detail section and they would exist for each of your data records.

Hope this clears your confusion.

[Paul]

The problem is that the datasource in in such a state it requires substantial coding.
Are you trying to tell me that if I have a collection of rows where each row needs to be treated differently and requires a substantial amount of code behind then Telerik is not a suitable solution.
Maybe I should generate on the fly a seperate sub-report for each row.
I cannot see any other solution to my problem.

[Chris Gillies]

What I meant is that any reporting solution would not be a feasible solution. Preparing the data in a proper state so that can be easily utilized by any databound control/component is always recommended and preferred over the alternative of writing substantial amount of code behind. Most of today's databound components work with almost any database or POCOs you throw at them directly, so if your data does not fit, you should change the data and not try to alter the product to fit your data.

Cheers!