To change the reporting parameters, go to the Properties container and you'll see them.
To change the designer parameters, you need to right-click the designer icon, open the context menu to Configure, then go through the wizard to get to the last page.
That's a bit of a hassle. Can the Designer-mode Parameters be added to the Properties page, with "Parameters" re-defined as "Run-time Parameters"?
In code (designer.cs), I don't see where the designer-mode parameters are stored at all. I'd guess this is why they aren't available under Properties. :)
Where is that data stored, and why does this need to be such a mystery?
Thanks.
4 Answers, 1 is accepted
The design-time parameters are part of the DataSource design-time Component. As this is not part of the report itself it cannot be shown in the property grid nor serialized in the .cs file. Additionally the design-time parameters are only used to retrieve the schema and are used for functions and stored procedures and basically their value won't make a difference, so once they are set, changing them would be meaningless.
Can you please elaborate further on your case and tell us why do you need to change the design-time parameters so often that you need quick access to them?
Kind regards,
Elian
the Telerik team
Have you tried the new visualization options in Telerik Reporting Q1 2013? You can get them from your account.
Rank 1
As discussed in another thread a while back, I have a need to distinguish between the schema used at design-time and that used at run-time.
Here is the problem I'm trying to solve:
- Consider a strongly-typed collection class providing data via an object data source. Let's say it has 100 fields from which a report developer can choose. Now assume a user just pulls 2 fields from there. At run-time if we use that same class object, there can still be 100 fields pulled across the wire with the reporting engine only using 2 of them.
- The same applies to a DataTable returned through an ObjectDataSource, with most of 100 columns being unused, though internally the structures to support all of those columns are still there, and depending on the datasource many or all of those unused column values could be returned for each row.
- The problem here is that there's are network/memory/cpu performance impacts when retrieving a result set that has data that's not going to be used.
So I've written components which behave differently when called from the designer versus from the run-time. Since design-time datasource queries don't go through the report (report parameters, NeedsDataSource, etc), I need to pass a flag from the designer through the ODS parameters. This means the designer parameters need to be slightly different from the run-time parameters.
At design-time I'm returning all of the fields allowed for a given datasource. So that flag needs to be present in the designer queries. At run-time I was going to parsing the report for Field values, and set a parameter in the ODS with them, so that the data source would then return data.
That proved to be difficult because the ODS doesn't have a NeedsDataSource type event. I tried to address this with a custom Component-derived ODS but creating that using the Telerik documentation caused VS to crash (reported to Support). I still need to review the response from Support, but while waiting I re-wrote part of this as follows.
I'm now just using the ODS for the design-time experience and telling the data source to return schema-only, no data. At run-time I'm setting the datasource to null, parsing the report for Field values, and generating a query and result set that will provide only those fields for the report. The result is then set as the report.DataSource from NeedsDataSource.
I have all of that working great, though I'm going to look for a way to avoid having to require users to use a custom class derived from Report which has that logic. (The custom ODS is probably the solution to that problem.)
What prompted this thread is that when in VS, I needed to go into the datasource definition frequently to change the parameters so that I could test to make sure the component properly rendered just the required fields for design-time. I was thinking that end-users with the stand-alone designer would be faced with the same problem. I've progressed beyond that but at times it still seems like it would be easier to use the Property Page to set values.
I'm doing all of that because I'm not using relational data sources. When I'm done with this, it might be marketable as a general-purpose solution for just about any source of data, whether RSS, CSV, REST-based data, MS Office products, Pick/MultiValue DBMS platforms, NoSQL, web server logs and other product/utility logs, and other non-RDBMS resources.
Bottom line - the original request might be invalid now, but at least you know what's driving it and how I'm navigating your product.
Phew. Thanks!
Thank you for the exhaustive answer and your time. Your scenario is very interesting and a bit odd.
The way that you worked it out is as we would have advised you to and probably the easiest.
However as previously explained the design-time values are properties of the designer component and not of the report item, so practically they can't be exposed in the property grid.
All the best,
Elian
the Telerik team
Have you tried the new visualization options in Telerik Reporting Q1 2013? You can get them from your account.
Rank 1