none
System.ArgumentException: Handle 0 is not valid if user doesn't click on properties in the System.Windows.Forms.PrintDialog RRS feed

  • Question

  • Hi,
    We have a problem with one Printer, witch sometimes fails to print when using it with .Net.
    Sometimes we do get a InvalidPrinter Exception with the text 'No printers are installed.', if the user doesn't click on the properties button next to the Printer Combo in the System.Windows.Forms.PrintDialog-Dialog.
    This is the Exception we got:
    System.Drawing.Printing.InvalidPrinterException: No printers are installed.
       at System.Drawing.Printing.PrinterSettings.GetHdevmodeInternal(String printer)
       at System.Drawing.Printing.PrinterSettings.GetHdevmodeInternal()
       at System.Drawing.Printing.PrinterSettings.GetHdevmode(PageSettings pageSettings)
       at System.Drawing.Printing.PrintController.OnStartPrint(PrintDocument document, PrintEventArgs e)
       at System.Windows.Forms.PrintControllerWithStatusDialog.OnStartPrint(PrintDocument document, PrintEventArgs e)
       at System.Drawing.Printing.PrintController.Print(PrintDocument document)
       at System.Drawing.Printing.PrintDocument.Print()

    sometimes also this one:
    System.NullReferenceException: Object reference not set to an instance of an object.
       at System.Drawing.Printing.PageSettings.CopyToHdevmode(IntPtr hdevmode)
       at System.Drawing.Printing.PrinterSettings.GetHdevmode(PageSettings pageSettings)
       at System.Drawing.Printing.PrintController.OnStartPrint(PrintDocument document, PrintEventArgs e)
       at System.Windows.Forms.PrintControllerWithStatusDialog.OnStartPrint(PrintDocument document, PrintEventArgs e)
       at System.Drawing.Printing.PrintController.Print(PrintDocument document)
       at System.Drawing.Printing.PrintDocument.Print()
       at ITS.Reports.itsCrystalReportViewer.DoPrint(PrintDocument document1, PrinterSettings settings1)

    or this one:

    System.ArgumentException: Handle 0 is not valid.
       at System.Drawing.Printing.PrinterSettings.SetHdevmode(IntPtr hdevmode)
       at System.Windows.Forms.PrintDialog.UpdatePrinterSettings(IntPtr hDevMode, IntPtr hDevNames, Int16 copies, Int32 flags, PrinterSettings settings, PageSettings pageSettings)
       at System.Windows.Forms.PrintDialog.ShowPrintDialog(IntPtr hwndOwner, WndProc hookProcPtr, PRINTDLG data)
       at System.Windows.Forms.PrintDialog.RunDialog(IntPtr hwndOwner)
       at System.Windows.Forms.CommonDialog.ShowDialog(IWin32Window owner)
       at System.Windows.Forms.CommonDialog.ShowDialog()
       at ITS.Reports.itsCrystalReportViewer.PrintReport()

    Printing with the same code to other printers works fine.
    Could this be a problem with our code, or is it more likely that the driver is faulty?

    Also Printing from other (non .net) application like word,notepad,acrobad reader works fine almost every time we have this problem.

    Wednesday, March 13, 2013 10:56 AM

Answers

  • "Yes, as long as the PrintDialog doesn't create a new PrinterSettings instance and uses that one, I always use the same instance. (I pass it as a Parameter, and don't write to it, so It should always be the same)
    But I changed the Code now to use the PrinterSettings from the PrintDialog, instaed the instance I created before and set to the System.Drawing.Printing.PrintDocument.PrinterSettings property."

    You should always use the PrintDocument's properties.  The dialogs load from the PrintDocument on show and transfer to the PrintDocument on close. 


    • Edited by JohnWein Thursday, March 14, 2013 10:51 AM
    • Proposed as answer by Papy Normand Thursday, March 14, 2013 11:34 AM
    • Marked as answer by Mike FengModerator Sunday, March 24, 2013 12:24 PM
    Thursday, March 14, 2013 10:50 AM

All replies

  • Check the printer when the PrintDialog closes and throughout the print.  You should be able to troubleshoot the problem using breakpoints.

    Wednesday, March 13, 2013 1:55 PM
  • Hi JohnWein,

    >> Check the printer when the PrintDialog closes
    Do you mean with System.Drawing.Printing.PrinterSettings.IsValid?
    Also the last Exception was thrown from the 'System.Windows.Forms.PrintDialog.ShowDialog' - Call, as it tried to update the System.Drawing.Printing.PrinterSettings.
    So I don't know for sure witch printer the user selected.

    >> and throughout the print.
    I will add some checks to the Code, but the Exceptions I posted are from OnStartPrint.
    As far as I knwo only the BeginPrint-Event is called before OnStartPrint.
    But we don't handle the event, so I don't see how we could be responsible.

    >> You should be able to troubleshoot the problem using breakpoints.
    This doesn't happen on our development machines, only on the clients witch do have a release version of the program installed.
    I will add some checks and logs. if this doesn't help I will have to try remote debugging.

    Wednesday, March 13, 2013 2:09 PM
  • You should be able to write code to test for anything that would cause the exceptions you posted.  Check the printer before and after showing the PrintDialog.  That is trace PrintDocument.PrinterSettings.PrinterName.

    Wednesday, March 13, 2013 2:22 PM
  • >> You should be able to write code to test for anything that would cause the exceptions you posted.
    Even the Exception witch happens in the PrintDialog.ShowDialog Call?
    The only thing I do there is creating a PrintDialog, PrintDocument and PrintSettings.
    I do not set the printer here, because the User should select the Printer he wants to use.
    Should I set a printer/check IsValid here, before showing the PrintDialog in order to prevent an Error when the User Clicks on OK in the PrintDialog?

    >>Check the printer before and after showing the PrintDialog.

    >> That is trace PrintDocument.PrinterSettings.PrinterName.
    So I only should check the Name of the Printer?

    In other cases, witch I didn't report here, System.Drawing.Printing.PrinterSettings.IsValid and System.Drawing.Printing.PrinterSettings.IsDefaultPrinter returned true, and System.Drawing.Printing.PrinterSettings.PrinterName was valid, but when accessing System.Drawing.Printing.PrinterSettings.SupportsColor I got:

    System.ComponentModel.Win32Exception (0x80004005): Die Daten sind unzulässig
       at System.Drawing.Printing.PrinterSettings.GetHdevmodeInternal(String printer)
       at System.Drawing.Printing.PrinterSettings.GetHdevmodeInternal()
       at System.Drawing.Printing.PrinterSettings.CreateInformationContext(PageSettings pageSettings)
       at System.Drawing.Printing.PrinterSettings.GetDeviceCaps(Int32 capability, Int32 defaultValue)

    Thursday, March 14, 2013 9:18 AM
  • Are you consistent in the PrinterSettings you access?  Are you always accessing the PrintDocument's Properties?  Is the Document Property of all your dialogs set to your PrintDocument?
    Thursday, March 14, 2013 9:26 AM
  • >>Are you consistent in the PrinterSettings you access?
    Yes, as long as the PrintDialog doesn't create a new PrinterSettings instance and uses that one, I always use the same instance. (I pass it as a Parameter, and don't write to it, so It should always be the same)
    But I changed the Code now to use the PrinterSettings from the PrintDialog, instaed the instance I created before and set to the System.Drawing.Printing.PrintDocument.PrinterSettings property.

    >>Are you always accessing the PrintDocument's Properties?
    Where I can yes, but in the (PrintPage+QueryPageSettings)-Eventhandlers of the Print I access the Parameters given to the Eventhandler.

    >>Is the Document Property of all your dialogs set to your PrintDocument?
    Yes

    Thursday, March 14, 2013 9:44 AM
  • "Yes, as long as the PrintDialog doesn't create a new PrinterSettings instance and uses that one, I always use the same instance. (I pass it as a Parameter, and don't write to it, so It should always be the same)
    But I changed the Code now to use the PrinterSettings from the PrintDialog, instaed the instance I created before and set to the System.Drawing.Printing.PrintDocument.PrinterSettings property."

    You should always use the PrintDocument's properties.  The dialogs load from the PrintDocument on show and transfer to the PrintDocument on close. 


    • Edited by JohnWein Thursday, March 14, 2013 10:51 AM
    • Proposed as answer by Papy Normand Thursday, March 14, 2013 11:34 AM
    • Marked as answer by Mike FengModerator Sunday, March 24, 2013 12:24 PM
    Thursday, March 14, 2013 10:50 AM