Collapsing parameter area before rendering a report RRS feed

  • Question

  • Hi fellows,


    I am trying to implement the functionality seen in ReportViewer on the http://localhost/reports page of SSRS: when the user press the View Report button, the prompt area is collapsed allowing the progress indicator to show even in reports with many parameters.


    I am using the web version of the report viewer control and fount that I should do:


    ReportViewer1.PromptAreaCollapsed = True


    The question is: what event should I implement in order to collapse the prompt area when the user clicks on View Report? Thanks in advance for any help.



    Wednesday, June 13, 2007 8:45 PM

All replies

  • The ReportRefresh event... I think...



    Friday, June 15, 2007 4:08 PM
  • I already tried that one but that event fires when the user presses the refresh button, not wheb the user presses the View Report button. Thanks a lot for your reply Lisa.


    Any other ideas? I still can´t make it work  

    Tuesday, June 19, 2007 1:18 PM
  • Sorry -- waah -- Would PageNavigation work, if you checked the args.NewPage value and if it were 1....?


    The only other thing I can think of that might possibly work would be PreRender/OnPreRender ...I have absolutely not  tried with the webforms ReportViewer -- it's just a semi-educated guess based on the fact that it seems to be the ASP.NET catch-all place to hook in for lots of other reasons/controls/page scenarios . Messing with it seems to be regularly necessary *and* fraught with issues.



    Tuesday, June 19, 2007 3:08 PM
  • Hello Lisa,


    Sorry for this late reply: I was merged in another project. The OnPreRender event is a good candidate to collapse the prompt area, but what ReportViewer property would tell me that the user has pressed the View Report button, so that I can decide to collapse or not (If [user pressed ViewReport] then PromptAreaCollapsed=true)?


    Thanks again for your kind reply. Hope to have more feedback.


    Friday, July 6, 2007 7:36 PM
  • OK forgive me if I am misremembering this problem... but I'm thinking that maybe what would work is a different approach entirely than hooking into the events.

    What about this:


    • ShowRefreshButton false
    • Implement your own refresh button outside the report control area?
    • When you get the click, you know what to do...


    Friday, July 6, 2007 8:21 PM
  • It is a totally different approach indeed but even if I make ShowRefreshButton = false, the [VIEW REPORT] button will still show and that's the one that I want to act upon. Thanks for your help.



    Friday, July 6, 2007 8:29 PM
  • Cr*p.  I told you I was going to misremember the problem...


    The "View Report button" is part of the parameter area, isn't it.  You know, it's starting to look more and more as if the parameter area (with its limited formatting) is better replaced entirely by a custom panel outside the viewer, and then you can pass the parameter values how you want, format your custom panel how you want, etc...


    I realize that this is not the answer you were looking for.  But it's a limited, and limiting, interface.  The good news is that you aren't really limited *to* it -- you can obviate the whole problem if you just bite the bullet and collapse it from the start.


    Sorry, I can't think of anything else...



    Friday, July 6, 2007 9:15 PM
  • Yes Lisa, your solution would be the best one but also the most costly in terms of codding and thus, the one I am trying to avoid. If you take a look at the ReportViewer as it is implemented in the report server pages when you navigate to http://localhost/reports and ask to view some report, you will notice that the folks at Microsoft know how to implement what I've been trying to do .


    I initially posted this question in the hope that someone would know how they do that... Your ideas and time have been greatly welcome. Thanks again. I will go on with my research.

    Friday, July 6, 2007 9:23 PM
  • I am really sorry, again, Cato, that I can't do better to help you (and if you get stuck figuring something out that's specific I promise to help with the research -- best I can do)...


    But to be honest when I go to *my* "localhost/reports" I don't actually see the behavior you're talking about. It may be that I don't have the right kind of parameter arrangement in my reports to see it.  Or it may be because I somewhat-customized my copy of the report manager and server style stuff <g>.


    I also don't mean to make you do something you don't want to do.  However in exploring the properties, it really does look like "this is the way it's supposed to be done" -- the existing parameter stuff is so limited, it is meant as a starter kit and then you get to Do Other Stuff in your own interface. 

    I can also imagine that, especially for web interfaces, they assumed with some justification that the important thing was extensibility, so that people could brand the interface the way they wanted to see it, not make it look like it wasn't part of their app.


    It's quite possible that -- although the Report Manager interface *looks* like the control, it just isn't the control you're seeing and that's how they do it, IOW.  Can you see how this might be?


    And also I gotta tell you.... your freudian typo (codding) in this message gave me the best laugh I've had in a week. 


     Somewhere between ef codd and coddling users is where our work is... <g>


    Be well,



    Friday, July 6, 2007 11:29 PM
  • In order to trap the event of the View Report Button check this out:

    protected void Page_Load( object sender, EventArgs e )
        if (!Page.IsPostBack) 
            if (reportViewer.CurrentPage > 0)
                reportViewer.PromptAreaCollapsed =

    If Page.IsPostBack == true then the report is being loaded.  If the reportViewer.CurrentPage is greater than 0 then you have valid parameters for the report and know that the View Report button is true. 


    Mike M
    Tuesday, February 3, 2009 2:25 PM