ASP.NET + Reporting Service + Dynamic controls help

Dynamic Controls are giving me nightmares.
I have a normal drop down list called Reports:
Reports - let's user select the report they want to generate
The number of parameters of the report is never known ahead of time,
which is why I need to dynamically create them based on the selected
report.
Let's say I have 3 drop down lists that depend on each other as the
paramters:
Country - has list of countries in the world
Province - empty initially.
City - - empty initially.
1. First you select "Canada" from the Country list
2. Post Back with value "Canada"
3. Load back Country list with Canada selected, and List of Provinces
4. Click on provinces and select Ontario
* PROBLEM: I can't get the value "Ontario" back :-( It's like it dies
on the second try
The 3 drop down lists are created dynamically in Page_Load. They have
to be because another drop down list (Report), has to be selected
first. If I were to create them in Page_Init, the viewstate would take
care of my postback headaches, but I can't because the Reports drop
down list is not available. The viewstate is loaded _after_ Page_Init.
To make matters worse, I can't query a database or else I'ld be done a
long time ago. I'm using a web service. MS Reporting Service's web
service to be exact. To resolve cascading parameters, I need to get
those 2 values (Canada, Ontario) and call
GetReportParameters(report, historyID, forRendering, values,
credentials)
with values containing (Ontario, and Canada).
I tried adding a event handler for the dynamically created drop down
lists, but that fires after post back, so no help at all since it seems
to work when I select Canada, but then when I select Ontario, I check
the "sender" and it's back to it's initial state. I'm so frustrated
and tired of this.
I'm doing all of this because I wanted a datepicker, so I'm recreating
a web UI that does all that. I did it, and works perfectly, only not
for reports that have cascading parameters.
I'm getting slaughtered here :-(Hi Roy,
I feel your pain, I did very similar work setting up a dynamically built
report front end for this beast. What I had to end up doing is adding a call
in to (re)call a sub routine that had already been fired on post back. Due
to the order of operations and which pieces of information you get and where,
I determined the only way for me to dynamically build the page corrctly after
postback was to run through the code (sub routine) again. In my case, after
I got to a certain point and I had gathered all the info I needed, I had to
call PageLoad(Me) which runs the page load code again. If I understand your
plight correctly, you might see if this would work for you somehow. I am
storing all of the parameters for the chosen report in Session and reading
them back out on page load again.
"Roy Assaly" wrote:
> Dynamic Controls are giving me nightmares.
> I have a normal drop down list called Reports:
> Reports - let's user select the report they want to generate
> The number of parameters of the report is never known ahead of time,
> which is why I need to dynamically create them based on the selected
> report.
> Let's say I have 3 drop down lists that depend on each other as the
> paramters:
> Country - has list of countries in the world
> Province - empty initially.
> City - - empty initially.
> 1. First you select "Canada" from the Country list
> 2. Post Back with value "Canada"
> 3. Load back Country list with Canada selected, and List of Provinces
> 4. Click on provinces and select Ontario
> * PROBLEM: I can't get the value "Ontario" back :-( It's like it dies
> on the second try
> The 3 drop down lists are created dynamically in Page_Load. They have
> to be because another drop down list (Report), has to be selected
> first. If I were to create them in Page_Init, the viewstate would take
> care of my postback headaches, but I can't because the Reports drop
> down list is not available. The viewstate is loaded _after_ Page_Init.
> To make matters worse, I can't query a database or else I'ld be done a
> long time ago. I'm using a web service. MS Reporting Service's web
> service to be exact. To resolve cascading parameters, I need to get
> those 2 values (Canada, Ontario) and call
> GetReportParameters(report, historyID, forRendering, values,
> credentials)
> with values containing (Ontario, and Canada).
> I tried adding a event handler for the dynamically created drop down
> lists, but that fires after post back, so no help at all since it seems
> to work when I select Canada, but then when I select Ontario, I check
> the "sender" and it's back to it's initial state. I'm so frustrated
> and tired of this.
> I'm doing all of this because I wanted a datepicker, so I'm recreating
> a web UI that does all that. I did it, and works perfectly, only not
> for reports that have cascading parameters.
> I'm getting slaughtered here :-(
>|||Thanks Myles.
I just used the Session() variable like you said and 3 hours later I'm
done some spiffy logic and blamo! My web UI now supports Cascading
Parameter for dropdownlists. Hopefully I didn't break anything! lol.
Thanks.|||Are you sure you don't load the provinces list on each post back.
Your code should look something like this (Page_OnLoad) :
if (!IsPostBack)
{
this.GetCountries();
}
if (cbxCountry.SelectedValue != null && cbxCountry.SelectedValue.Length
> 0)
{
this.GetProvinces(cbxCountry.SelectedValue);
}
Also check that the UseViewState of your controles are set to true.|||Hi Julich,
I wish it was that simple, but what I actually ended up "rewriting" was
the MS Reporting services front end GUI! So it has to be generic
meaning that the names of the controls (cbxCountry) are not known until
runtime when the user selects the report and the paramters are fetched.
I just used Country/Province/City because it's an excellent and easy to
understand problem when it comes to cascading parameters.
In essence, I get the report name, then I get the report parameters,
and based on their name, I autogenerate all the necessary controls
(dropdownlist, textbox, or my custom date picker - which MS left out!
grrr..) I do strict type checking to determine what control to
dynamically create and I also validate so no garbage can be place as
default values or any other type of values.
All controls have a nomenclature like:
_REPORT_PARAMATER_x where x is the parameter name. This convention
makes it easier to find them in the Control tree, and in my case, the
root of the tree is actually a placeholder.
Again, I basically rewrote MS's reporting service's front end GUI in
ASP.NET (VB.NET) code behind. I hate reinventing the wheel but the
lack of a calendar/date picker is unforgivable. I was REALLY
disappointed that MS didn't put it in. The last thing I want is a
client to start entering dates in a text box. Does month go first, or
day?! And the idea of having 3 drop down lists (year, month, day) is
not acceptable because it looks ugly. Appearance is important.
+ roy
Julich wrote:
> Are you sure you don't load the provinces list on each post back.
> Your code should look something like this (Page_OnLoad) :
> if (!IsPostBack)
> {
> this.GetCountries();
> }
> if (cbxCountry.SelectedValue != null && cbxCountry.SelectedValue.Length
> > 0)
> {
> this.GetProvinces(cbxCountry.SelectedValue);
> }
> Also check that the UseViewState of your controles are set to true.|||I totally agree with you on the poor quality of the default MS RS GUI.
I'm also surprised that no ISV did publish an improved one. Didn't have
time to test the 2005 version but I hope it will be improved in a
significant way.
+1 on "appearance is important".
Julich|||The biggest UI improvements are multi-select parameters (this is a big one
for me), end user sorting of the report (click on the column to sort on),
calendar pick list for parameter (I am not 100% sure of this one), custom
report items (this will open up RS for 3rd party controls like guages, etc).
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Julich" <julich@.gmail.com> wrote in message
news:1121865468.539733.287500@.z14g2000cwz.googlegroups.com...
>I totally agree with you on the poor quality of the default MS RS GUI.
> I'm also surprised that no ISV did publish an improved one. Didn't have
> time to test the 2005 version but I hope it will be improved in a
> significant way.
> +1 on "appearance is important".
> Julich
>|||Hi Bruce,
yes, we are looking for custom report items to do our charting....we
are very keen on getting higher quality and more flexible charting over
the standard product...looking forward to RS 2005... :-)
Peter