sql server reporting services: I found many hints that customer parameter interfaces are a possible solution
for several problems.

But I can't find one piece about how this can be done. Not in the
documentation, not in this news group and not in google. I'm really investet
many time, but don't find anything.

Here's the design doc I wrote for ours:

Reporting Phase II Design
A Dynamic User Interface for Report Navigation and Runtime Parameter Gathering
Introduction
Having a dynamic user interface to present reports to users and gather
runtime parameter values originates from a singular thought: report
customization. We desire that reports be developed by end user
administrators in addition to professional services and in-house developers.
By providing this support we must provide a means by which a report may be
deployed into the production environment and then appear in the application
without any user interface development activity on our part. The best way to
support this desire is to build our user interface such that it does not rely
on specific knowledge of any one report but rather is built with awareness
that reports are present and that they gather runtime parameters. In this
fashion, report developers are free to upload new reports or modify existing
reports independent of a release cycle. The following sections will
illustrate how we may expose this capability from within our application.
Report Navigation
The first challenge regarding our dynamic user interface is to present the
reports so a user may choose among them. Our current user interface design
calls for a hierarchical folder paradigm that contains and organizes all
reports. It begins with a root node labeled ‘My Reports’ that appears in the
‘Tracking’ page. This folder can contain any number of sub folders, which
serve to categorize all reports and will initially contain the folders ‘Email
Reports’, ‘Subscriber Reports’, ‘Admin Reports’, and ‘Custom Reports’. It is
not clear whether the folder ‘My Reports’ will ever contain reports
themselves and it is presumed these first level folders will contain reports
and perhaps additional folders.

The Report Services component, created to serve the user interface and other
consumers, provides a method GetReports() that takes no input parameters and
returns to the caller a data table containing all of the reports that the
calling user is authorized to view. This data table will also contain the
hierarchy of folders such that the consumer may illustrate reports in
accordance with the prescribed hierarchy.

The data table returned by GetReports() will contain the following items:
• ID – a unique identifier (GUID) that uniquely identifies the report item
• Type – an enumeration describing the nature of the report item. This is
supported by the public enum ReportItemType containing Folder and Report
(this may be expanded to include other types as demand warrants.
• Name – the plain text name of the report, suitable for illustration in the
user interface. (This value originates from the ‘name’ property of a report
on the report server, which gets its value from the ‘name’ property of the
report itself, which is established at design time. It is therefore
necessary for developers to assign a meaningful name at design time,
presumably assigned by Product Management at the time of envisioning.)
• Description – A plain text description that serves to illustrate the
content/functionality of the report in greater detail than ‘Name’ (above).
It may be useful perhaps as tool-tip text given the folder paradigm. This
value originates from the ‘description’ property of the report on the report
server, which gets its value from the ‘description’ property of the report
itself, which is established at design time. It is therefore necessary for
developers to assign a meaningful value during the development process;
presumably this text will originate from Product Management.
• Path – A text string that contains the fully qualified path to the report
on the report server. This item equally serves as a unique identifier for a
report, describes the location of the report within the folder hierarchy, and
is used as in input parameter by the RenderReport() method that identifies
the report to be rendered.
• Parent – a unique identifier (GUID) that points to a report item that
contains this report item. If null, it indicates the root of the hierarchy.

It is presumed that our user interface will use this data table to construct
the tree view that is illustrated in the user interface document. Further,
all attempts will be made to provide all of the information desired by the
user interface team and in a structure that is most suitable to their
consumption.
Runtime Parameter Value Gathering
While it is necessary to provide a listing of reports suitable for display,
the greater challenge comes in gathering the runtime parameter values that
will be used by the report to scope its contents and perhaps drive the order
in which result rows appear. To support consumers in the gathering of
runtime parameter values, the Report Services component exposes a method
GetReportParameters(). This method takes one parameter (string reportPath)
that is acquired through the ‘Path’ item returned by GetReports() as
described above and returns a collection containing the items described
below. (Note: the values these items contain are a function of developer
action at design time, primarily via the settings made in the ‘Report
Parameters’ dialog of the IDE.
• Bool AllowBlank – Determines whether a parameter value can be an empty
string. This applies only to parameters of type string (identified by
ETParameterTypeEnum Type, below)
• String[] DefaultValues – A string array that typically contains one
element whose value indicates the default for this parameter. The user
interface should populate the appropriate control with this value. (Note: in
the future we may choose to support multi-value parameters; perhaps for use
with the SQL IN operator. If and when this becomes true, the potential for
multiple default values becomes true, hence it is declared as an array.)
• Bool DefaultValuesQueryBased – Indicates whether DefaultValues (above) is
populated by an expression (false) or by a database query (true).
• Bool DefaultValuesQueryBasedSpecified – Indicates whether a determination
can be made at runtime to assign DefaultValuesQueryBased a value. If this
value is false the origin of the default value(s) for this parameter is
indeterminate.
• String[] Dependencies – If this parameter’s default or valid values are
based on a parameterized query and that query’s parameter(s) have
indeterminate values, then this array will contain the names of those
parameters. In other words, if this property is not null, you will need to
gather the values for the parameters named in this property, make a
subsequent call to GetReportParameters, and then gather the value for this

@ Herman K: Thank you very much! This is real help and furthermore an
valuable documentation.

My misunderstanding was, that I thought I can replace the parameter section
in a report with something like a custom control. But this seems to be
impossible.

[quoted text, click to view]