PrintQueue.AddJob freezes when printing to non-xps based printers

I am trying to print an xps document for printers (network printer, some virtual local printers, xps and non xps) with the following code.

C # Source:

static void Main(string[] args) { PrintServer printServer = new PrintServer(@"\\printserver.csez.zohocorpin.com"); foreach (PrintQueue queue in printServer.GetPrintQueues()) { Console.WriteLine("Printer: {0}, Port: {1}, ShareName: {2}, status: {3}, PrintingIsCancelled: {4}", queue.Name, queue.QueuePort.Name, queue.ShareName, queue.QueueStatus, queue.PrintingIsCancelled); Program program = new Program(); Thread printingThread = new Thread(() => program.Print_XPXFile(queue, @"D:\Assist\RemotePrint\Spool\Donalduck.xps")); // Set the thread that will use PrintQueue.AddJob to single threading. printingThread.SetApartmentState(ApartmentState.STA); printingThread.Start(); printingThread.Join(); } } public void Print_XPXFile(PrintQueue pQueue, String FilePath) { // Create print server and print queue. bool fastCopy = pQueue.IsXpsDevice; FileInfo file = new FileInfo(FilePath); if (!file.Exists) { Console.WriteLine("There is no such file."); } else { Console.WriteLine("Adding {0} to {1} queue. share name : {2}", FilePath, pQueue.Name, pQueue.ShareName); try { // Print the Xps file while providing XPS validation and progress notifications. PrintSystemJobInfo xpsPrintJob = pQueue.AddJob(file.Name, FilePath, fastCopy); Console.WriteLine("Done adding."); } catch (PrintJobException e) { Console.WriteLine("\n\t{0} could not be added to the print queue.", file.Name); if (e.InnerException.Message == "File contains corrupted data.") { Console.WriteLine("\tIt is not a valid XPS file."); // Use the isXPS Conformance Tool to debug it. } else { Console.WriteLine("\tmessage : {0}", e.InnerException.Message); } } } } 

When printing to Microsoft XPS Document Writer, Microsoft Print to PDF, etc. It works great.

I found that it works fine with all XPS based printers . I even installed the XPS sample printer driver and added a virtual local printer to confirm this statement and as expected, it worked.

For non-xps printers, it actually gets stuck in the AddJob function. It does not generate any exceptions and does not proceed to the next statement.

I developed code based on this msdn resource.

What is the reason and solution?

All thoughts are welcome.

+5
source share
2 answers

I can not find the problem. But here is a more promising way to print XPS files:

  public static void PrintXPSToDefaultPrinter(string FilePath) { try { // Create the print dialog object and set options PrintDialog pDialog = new PrintDialog(); pDialog.PageRangeSelection = PageRangeSelection.AllPages; pDialog.UserPageRangeEnabled = true; FileInfo file = new FileInfo(FilePath); XpsDocument xpsDocument = new XpsDocument(FilePath, FileAccess.ReadWrite); FixedDocumentSequence fixedDocSeq = xpsDocument.GetFixedDocumentSequence(); pDialog.PrintDocument(fixedDocSeq.DocumentPaginator, file.Name); } catch (System.IO.IOException ex) { Console.WriteLine("The file is being used by some other process."); } catch (Exception ex) { Console.WriteLine("Exception occured : {0}", ex.Message); } } 

You should call this in STA mode just like you used:

 static void Main(string[] args) { Thread printingThread = new Thread(() => PrintXPSToDefaultPrinter(@"D:\Assist\RemotePrint\Spool\Donalduck.xps")); printingThread.SetApartmentState(ApartmentState.STA); printingThread.Start(); } 

You can also specify any printqueue u values ​​in the pDialog.PrintQueue property.

Hope this helps. Enjoy the man !!!

+5
source

I am also stuck in the AddJob () method. The problem was apparently more common as Windows 10 platforms became involved.

By disrupting execution during debugging, the stack trace showed that the STA thread was blocked during a call

MS.Internal.PrintWin32Thunk.XpsCompatiblePrinter.JobIdentifier.get

and this further blocked the low-level WaitOne () for an unknown synchronization object.

Although the details of this problem are subtle (this is the only message I have found on this topic), the THANKFULLY decision made works very well (and I have been trying to print in WPF for many years).

AddJob () is completely replaced in every way. You can even easily control PrintTicket through PrintDialog (to set paper size, orientation, single-sided printing, etc.)

0
source

Source: https://habr.com/ru/post/1271679/


All Articles