Advantages of Silverlight/WPF viewer vs popping up a browser

4 posts, 1 answers
  1. danparker276
    danparker276 avatar
    389 posts
    Member since:
    Aug 2010

    Posted 30 Aug 2012 Link to this post

    I currently don't see much of an advantage of using the silverlight report viewer.  I think it would be better to just popup a web browser with the reports from my silverlight program.  The only advantage I can see is the zoom feature on silverlight and maybe the UI looks nicer.

    Also when I press print, the silverlight version has to wait for another popup to say ok before the OS print menu comes up.  The webforms viewer doesn't.  I'm not an expert in this, but is there any advantage of having the silverlight/WPF version print vs the webforms?  Printing is big to my clients.

    As for the load on the server, it seems like it would be almost the same.  I guess that there is some HTML on the asp.net version the server would have to render.  Since all the calculations and pages are stored on the server for both versions, it doesn't seem like there's a difference here.
  2. Peter
    Admin
    Peter avatar
    1611 posts

    Posted 04 Sep 2012 Link to this post

    Hello Dan,

    You are correct the Silverlight and WPF report viewers advantages are that they are native controls and that they utilize Telerik themes.

    About the printing we invoke a confirmation dialog because there is a limit on the time allowed between the user initiates the dialog and when the dialog is shown. If the time limit between these actions is exceeded, an exception will occur. For more information check out the Silverlight Printing MSDN article. In your case if your customers have Adobe PDF plugin installed and OOB is not required, our suggestion is to set the ReportViewer.UseNativePrinting property to False. This way the Silverlight viewer will use it's True Print functionality that is used in the Web report viewer. Generally the True Print is faster and doesn't require additional confirmation dialog, the only down side is the dependency for Adobe or Chrome PDF plugin and that OOB is not supported.

    Kind regards,
    Peter
    the Telerik team

    BLOGGERS WANTED! Write a review about Telerik Reporting or the new Report Designer, post it on your blog and get a complimentary license for Telerik Reporting. We’ll even promote your blog and help bring you a few fresh readers. Yes, it’s that simple. And it’s free. Get started today >

  3. DevCraft banner
  4. danparker276
    danparker276 avatar
    389 posts
    Member since:
    Aug 2010

    Posted 04 Sep 2012 Link to this post

    I just tested a WPF report and it seems like it is client side.  I'm a little confused, I thought the WPF viewer had to connect to the Reports web service, but I just added the reporting DLL to my WPF application and it works.  Is the app.config built into the DLL?

    So if my application is in WPF with report viewer, I won't hog the server memory/cpu with 100 people running reports?
  5. Answer
    Peter
    Admin
    Peter avatar
    1611 posts

    Posted 05 Sep 2012 Link to this post

    Hello Dan,

    The WPF and WinForms report viewers process reports on the client. Only Silverlight and Web forms report viewers due to technologies peculiarities are processing reports on server side.

    The class libraries configuration files are ignored in the application. More information on the topic is available in Using connectionStrings from configuration file KB article.

    Kind regards,
    Peter
    the Telerik team

    BLOGGERS WANTED! Write a review about Telerik Reporting or the new Report Designer, post it on your blog and get a complimentary license for Telerik Reporting. We’ll even promote your blog and help bring you a few fresh readers. Yes, it’s that simple. And it’s free. Get started today >

Back to Top