A: 

You could add them via the xml definition. I use xml to create an entire report based on selected sub-reports and other options. I can paste some code in here come Monday if you would like to look at this as a possible solution.

Edit: You can set values on the sub-report in the XML before you deploy the report. This is not very flexible and I am making the assumption that if you want to prompt for these values, you will most likely need them on the parent report.

If you want to see what the XML looks like, add a sub-report, enter values for it in the sub-report properties > parameters, then do a view code.

<Subreport Name="subreport1">
    <Parameters>
      <Parameter Name="StartDate">
        <Value>=Parameters!StartDate.Value</Value>
      </Parameter>
      <Parameter Name="EndDate">
        <Value>1/1/2009</Value>
      </Parameter>

Instead of using the =Parameters!StartDate.Value I'm guessing you would want to put an actual value like on the EndDate.

Dustin Brooks
how does that help? the xml definition is just the "outline" of the report, isnt it? No actual data there? I can define the parameters in the report editor thing. What I need to do is the set their value.
Svish
You can set the values in the XML before you deploy the report. If you are needing to prompt for these values though, I'm pretty sure you will have to have them in the parent report.
Dustin Brooks
A: 

After looking and looking, I have come to the conclusion that setting the parameters of a sub-report, in code, is not possible. Unless you do something fancy like start editing the xml of the report definition before you load it or something like that.

(But if someone else should know that I am wrong, please do answer, cause I am still very curious to know!)

Svish
+2  A: 

It does work but it sure is persnickety.

First thing I recommend is to develop your reports as .rdl. Much easier to test the reports this way. You can also get the subreport parameters set up and tested as rdl, making sure each parameter of the subreport is also defined as a parameter of the parent report. Once you get the reports - including the subreports - working that way you can rename the .rdl to rdlc and add the rdlc files to your ReportViewer Project. No further changes required. Use the names of the rdl datasources as the data source names in your code to provide data to the report in the SubreportProcessing event handler.

You don't assign values to the passed parameter. The subreport will use them as is. (Sounds like the step you are missing is adding the parameters to the parent report as well as the the subreport as mentioned above.) You can evaluate the parameters and use them as query parameters to get the datasource you will add. You have to think about the datasource like its on an undiscovered dimension for a subreport. You will have to poke around while debugging in the event handler to see what I mean. Some of the values in your application will be readily available, others that you use easily elsewhere will throw object not found exceptions. For example I create a dataset in a instance of a class created on my applications main form. I use the data set throughout my application. In the SubreportProcessing event handler I cannot use the common dataset, so I must create a new instance of the table I need for the report and populate it. In the main report I would be able to access the common dataset. There are other limitations like this. Just have to wade your way through.

Here is the SubreportProcessing event handler from a working VB.NET ReportViewer application. Shows a few different ways to get the datasource for a subreport. subreport1 builds a one row datatable from application business objects, subreport2 provides data the report requires without a parameter, subreport3 is lie subreport2 but evaluates one of the parameters passed to the subreport for use in date value required by the query that creates the ReportDataSource.

    Public Sub SubreportProcessingEventHandler(ByVal sender As Object, _
                                               ByVal e As SubreportProcessingEventArgs)
    Select Case e.ReportPath
        Case "subreport1"
            Dim tbl As DataTable = New DataTable("TableName")
            Dim Status As DataColumn = New DataColumn
            Status.DataType = System.Type.GetType("System.String")
            Status.ColumnName = "Status"
            tbl.Columns.Add(Status)
            Dim Account As DataColumn = New DataColumn
            Account.DataType = System.Type.GetType("System.String")
            Account.ColumnName = "Account"
            tbl.Columns.Add(Account)
            Dim rw As DataRow = tbl.NewRow()
            rw("Status") = core.GetStatus
            rw("Account") = core.Account
            tbl.Rows.Add(rw)
            e.DataSources.Add(New ReportDataSource("ReportDatasourceName", tbl))
        Case "subreport2"
            core.DAL.cnStr = My.Settings.cnStr
            core.DAL.LoadSchedule()
            e.DataSources.Add(New ReportDataSource("ScheduledTasks", _
                                                   My.Forms.Mother.DAL.dsSQLCfg.tSchedule))
        Case "subreport3"
            core.DAL.cnStr = My.Settings.cnStr
            Dim dt As DataTable = core.DAL.GetNodesForDateRange(DateAdd("d", _
                                                                          -1 * CInt(e.Parameters("NumberOfDays").Values(0)), _
                                                                          Today), _
                                                                  Now)
            e.DataSources.Add(New ReportDataSource("Summary", dt))
    End Select
End Sub
Yeah, that is what I came to see was what I would have to do as well. Problem is that adding all those parameters to the main report just ain't gonna be possible. We use one main report as a template, where we stick everything that should be on all reports. name, parameters, pages, logo, etc.
Svish
And then we stick the "real" report, inside a subreport in that. And it works great. Except for those parameters. Anyways, what was the idea, was to use parameters for translating things, but I have now created a class which fixes it for me: http://www.codeplex.com/rdlclocalizer
Svish
A: 

Svish - I'm not sure which side of the plumbing you're having trouble with.

To add parameters to the parent report open it then right click on the subreport and select Properties > Parameters.

You can then define parameter names and assign them a value, e.g.

Parameter Name | Parameter Value
---------------+---------------------
MyParameter    | =Fields!Params.Value

So on this side of the plumbing the parameters get their value from the parent report data source.

To add parameters to a subreport open the subreport and from the toolbar select Report > Report Parameters

Here you define a parameter to receive the parameter from the parent report, e.g.

Name      | myParameter
----------+---------------------
Data Type | String

For what it sounds like you want to do can't you do away with a subreport and just have the one report anyway? The information you're trying to wrap around the report sounds ideal for just including in the headers and footers of the report.

I'm having trouble with the fact that I can't set parameters of a sub-report, and then set them through code like I can with the datasources and report definitions. I can't and don't want to get rid of the sub-report because the top wrapping contains more than just a simple header and footer.
Svish
A: 

I had a similar problem in that I needed to pass a Properties.Settings.... value to prepend to the path in the database. To do this I had to set a property in the main report and use that property to set the second property in the subreport. Setting the main property then in turn sets the subreport property. YOU CAN set the main property in code as follows:

Suppose you have a ReportViewer name rv, then we would code:

var rp = new ReportParameter("MainReportParamName", Properties.Settings....);
rv.LocalReport.SetParameters(new ReportParameters[] { rp });
Dr. A