none
ReportViewer -- Client-side Event Handling for Print/Export in Local Mode RRS feed

  • Question

  • Is it possible to handle events such as Printing and Exporting on the client side when using local mode?  Essentially, I would like to determine (on the client side) whether or not a report has been printed or exported.  Thanks in advance.
    Friday, November 13, 2009 7:20 PM

Answers

All replies


  • You can take advantage of the event print and export once the user fire the event store some value in a variable (I stored the value in the form .tag) you can store it into a public variable and before the form close check for the variable value

    something like this

    Public Class Form3
    
        Private Sub Form3_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
            Me.ReportViewer1.RefreshReport()
        End Sub
    
        Private Sub ReportViewer1_Print(ByVal sender As System.Object, ByVal e As System.ComponentModel.CancelEventArgs) Handles ReportViewer1.Print
    
            Me.Tag = "Print"
        End Sub
    
    
        Private Sub ReportViewer1_ReportExport(ByVal sender As System.Object, ByVal e As Microsoft.Reporting.WinForms.ReportExportEventArgs) Handles ReportViewer1.ReportExport
    
            Me.Tag = "Export"
    
        End Sub
    
    
        Private Sub Form3_FormClosing(ByVal sender As System.Object, ByVal e As System.Windows.Forms.FormClosingEventArgs) Handles MyBase.FormClosing
    
            Select Case Me.Tag
    
                Case Is = "Print"
                    MessageBox.Show("Print Done")
                Case Is = "Export"
                    MessageBox.Show("Export Done")
                Case Else
                    MessageBox.Show("You can't exit without export or print")
                    e.Cancel = True
    
            End Select
        End Sub
    End Class

    John
    Saturday, November 14, 2009 2:32 PM
  • Thanks, John.  Unfortunately, I am using a Webform instead of a Winform, so there are no specific events to hook into for both Print and Export.  I have considered creating custom buttons for Print and Export to take advantage of an onClick event; but I would rather use the functionality that is already in place rather than have to reinvent the wheel.
    Monday, November 16, 2009 6:29 PM
  • ReportViewer on a WebForm has less events. I think you have to create your own custom events :--(

    Sorry.


    John
    Monday, November 16, 2009 8:45 PM
  • Thanks, John.  Unfortunately, I am using a Webform instead of a Winform, so there are no specific events to hook into for both Print and Export.  I have considered creating custom buttons for Print and Export to take advantage of an onClick event; but I would rather use the functionality that is already in place rather than have to reinvent the wheel.

    It turns out that creating custom buttons probably isn't feasible either.  With Webforms, I do not think there is a way to invoke the printer dialog to actually print the report.  You can, of course, call window.print() on the client side; however, doing so prints the entire screen as opposed to the actual report that may be multi-paged.

    There are numerous examples on the forum dealing with directly printing without the need for a print dialog; nevertheless, this implementation has a major limitation: it does not support network printers.  Direct printing makes use of EMF and System.Drawing.Printing.  Unfortunately, PageSettings.PrinterSettings only detects printers installed directly on the machine running the report and not printers on a network.

    It's really a shame that there is no event handling on Print and Export.  Simple button click events would prove useful.
    Wednesday, November 18, 2009 9:56 PM
  • It's true that there is currently no way to invoke the report viewer print dialog in the browser.  But we have added a client side javascript API in VS 2010, including the ability to launch the print dialog.  This article talks about how to use it: http://blogs.msdn.com/brianhartman/archive/2009/11/09/javascript-api.aspx
    • Marked as answer by Joe Duero Monday, November 23, 2009 12:29 PM
    Sunday, November 22, 2009 6:54 AM
    Moderator