We have this working at my job, b/c we use reporting services in dnn to render the parameters on the fly when you click your choice of report in the report control we built. Is this what you are talking about?

I took a look at your solution on SQL Server Central. Interesting idea. You’re querying your report via the web services interface of Reporting Services. The problem that I was trying to address above was coding a helper function that could be called WITHIN a report to display the current parameters without hard-coding the parameter list. For example, setting a textbox value to =ParameterHelper.RenderParameterList(). You could get the list of parameter names via the web service as you suggest, but this is an awful lot of overhead (making a remote call) to simply get a list of parameter names. As Kevin mentions, it’s possible if you build a custom report control as you’ll have full information about the report, but not if you’re trying to code a helper function that can be executed within a report.

I hit the exact same problem as highlighted above. Thought of the Webservice solution but didn’t like the overhead of it. In the end came up with a simpler solution although not as nice as just having a function that does everything. I created a function (C#):

public string DisplayParameters(Parameters objParameters, string strParameterNames, string strParameterLabels)

Pass in the paramaters object, a comma seperated list of the parameter names (so you can access the string key’d object array that is the Parameters object) and a comma seperated list of labels that are used as the output heading for a parameter. So it would be called in RS like – Code.Params.DisplayParameters(Parameters, "OfficeID, TeamID", "Office, Team") and it would return a string like "Offices: Sydney, Brisbane; Teams: All".

The code under the hood handles mutlivalue selection boxes v’s single select boxes, text boxes and date controls (the date is parsed to my preferred australian date format of dd-MMM-yyyy). This was done on Reporting Services with SQL Server 2005, and Visual Studio 2005, .net framework 2.0.

There are some tricks however and I would save you that pain:
1. The Parameter object changes how it responds based on its type and whether it is multi-valued.
2. A Selection box has a label and a value, a text box or date selection only has a value.
3. When multivalued the Parameter.Label and Parameter.Value become arrays but you cannot just access by Parameter.Label[0] as it will not compile. Tt has to be cast to its base type.
3.1 When multivalued the Parameter.Label becomes a string array and can be cast to a sting array like so:
string[] strValues = (string[])objParam.Label;
this can now be looped through to return the list of multiple values that were chosen by the user running the report.
3.2 When multivalued the Parameter.Value becomes an object array of objects and can be cast to a object array like so:
object[] objValues = (object[])objParam.Value;
this can now be looped through and the selected values accessed via objValues[0].ToString()

This seems to be working for me, hope it helps.
Cheers
John

Indeed Good Stuff John!

Thanks to your info about the Parameter object I was able to return a comma separated string of a multi-parameter selection. Here my function in VB that I put in Report Properties->Code.

Also, I don’t know if it’s a typo but for me Parameters returned an error but Parameter was accepted.

Public Function GetParamValues(ByVal obj As Parameter) As String

Dim returnValues As String
Dim values() As String

returnValues = ""
values = CType(obj.Label, string())

Dim i As Integer
For i = 0 To values.Length – 1
returnValues = values(i).ToString() & "," & returnValue
Next

Return returnValue
End Function

I know this is a bit dated, but this kind of discovery in SQL Reporting is so disappointing. I agree with the group sentiment here of "What the heck were they thinking?!?!?!" How many years has this product had to mature? Even MS Access offers finer control.

Does anyone know if MS has gotten the message about the lack of customizability in SQLRS or are we doomed to hacks and workarounds?

This is totally MOUTH! Any word as to whether or not RS2008 is going to address this? I’m a big user of the custom code block, but it’s always like having my hands tied.

I have developed a solution for this problem. It can be found here:

http://beaucrawford.net/post/Reporting-Services-(SSRS)-Enumerate-Parameters-in-RDL-Custom-Code.aspx

Does anyone know if there is a limitaion to the amount of arguments that can be passed to a method in a custom assembly? I have quite a few (in order to do some calculations) fields that I have to pass in. When I try to preview the report, it says that there are too many arguments. I have verified that I am passing all the required fields to supply the method. It seems that there isn’t any (that I have been able to find) documentation on the limitations of SSRS. I appreciate everyone’s ideas!