Giters

svishnevsky / PDFtoPrinter

.Net Wrapper over PDFtoPrinter util allows to print PDF files.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Issue with printing with concurrency that one of the files stays with PDF XChange Viewer open blocking

dannymonteiro opened this issue · comments

commented

Hi,

I am using your nuget to print PDF to a printer with concurrency, and when i send to print 3 or 4 pdfs to printers, randomly one of them stays with the PDF XChange Viewer app open hanging and blocking the print.
Once i close the xchange viewer it prints the pdf.

I am doing what your samples show, creating the print for each file and waiting for the tasks at the end.

`var wrapper = new PDFtoPrinterPrinter(5);

var taskList = new List();
taskList.Add(wrapper.Print(new PrintingOptions(printerName, fileToPrint + "_1.pdf")));
taskList.Add(wrapper.Print(new PrintingOptions(printerName, fileToPrint + "_2.pdf")));
taskList.Add(wrapper.Print(new PrintingOptions(printerName, fileToPrint + "_3.pdf")));

Task.WaitAll(taskList.ToArray());`

Can you help me, of what i'm doing wrong?

Very thanks.

commented

Hi @dannymonteiro

Sorry, tried multiple times and still can't reproduce. Could you please say which .net version do you use and what kind of application (console, web, desktop etc)?

If you leave it open for 1 minute, does it close automatically?

commented

Hi,

Thanks for replying, and sorry that i've take some time to check your response.

I use .net version 4.7.2, and the app type is Windows Service, with a interface that is hidden.

If i leave it open for long time, more than 1 minute, i see that the PDFtoPrinter icon shows on the taskbar and after that time, even if does not print, it closes automatically, but the PDF XChange Viewer app stays open always, until i close it manually.
I've tested a scenario where, when it opens de PDF XChange Viewer app on the taskbar, if i close it after 5 seconds more or less manually, then it prints with success. So i guess is something that is blocking from the PDF XChange Viewer app i think.

Thanks.

commented

Hi, guys,
Any news on this? I am experiencing the same issue (I think). Here's my code:

[HttpPost("Print")]
public async Task<bool> PrintLabelAsync([FromBody] PDFPrintRequest request)
{
    var printer = new PDFtoPrinterPrinter();
    await printer.Print(new PrintingOptions("<PRINTER NAME>", "<PDF LOCATION>"));
    return true;
}

Attached is a video of what happens - at first I close the window manually, after closing it it is immediately printed. In the second attempt I let be and after 1 minute it the Task timeouts. The window never closes on its own and after closing it manually it does not print.

Any news on this?

clideo_editor_f2af8ddf0b014ba59ab767c1bf517b64.mp4
commented

Hi @deerware

Thanks for sharing your experience. I think I know what causes your issue, all tasks produced in scope of Http Request are automatically cancelled after the request completing. And process killing runs in a separate non-waitable task. So the task, which must kill the process is cancelled before timeout. Will try to solve this.

commented

Hello there. I have a similar issue, same as the video!
The PDFXChange Viewer opens up, then I get the same window as the one in the video. I am working in the same context as @deerware since it's wrapped inside an IEndpointRouteBuilder HTTP.GET endpoint
Here is my code below:

var pdfPrinter = new PDFtoPrinter.PDFtoPrinterPrinter();
Debug.Print(path);
await pdfPrinter.Print(new PDFtoPrinter.PrintingOptions("Printer", path), new TimeSpan(0, 0, 30))
```;
commented

Hi @dannymonteiro , @deerware , @raversa001

I published an updated version. Could you please try v1.5.1 and let me know if the issue still persist?

commented

Hi @dannymonteiro , @deerware , @raversa001

I published an updated version. Could you please try v1.5.1 and let me know if the issue still persist?

Hey, thank you for your answer

I updated to 1.5.1, but that didn't help I'm afraid
Still opens up an instance of PDFXcview.exe that I have to close for it to go on
I've made a workaround that just kills all the instances of PDFXcview after 5 seconds within a seperate thread, but it doesn't work all the time

commented

Hi @svishnevsky ,

Unfortunately, there doesn't seem to be any difference for me. It works exactly the same as before the update.

Nevertheless - thank you for such a speedy response!

commented

@svishnevsky what's weird is that if I try to use your PDFtoPrinter/build/PDFtoPrinter_m.exe file and call it directly from CMD for the same file, it's working without any issues or GUI, I don't even need to add the /s parameter.

C:\Users\mjelinek\Downloads>PDFtoPrinter_m "ART CU Receipt Test (1).pdf" "EPSON TM-T20II Receipt5"

I've tried calling it from my code and that seems to be working - no GUI

Process process = new Process();
process.StartInfo.FileName = "PDFtoPrinter_m.exe";
process.StartInfo.Arguments = "\""+  request.pdfData + "\" \"EPSON TM-T20II Receipt5\"";
process.Start();
if (process.WaitForExit(10000))
    return true;

process.Kill();
return false;
commented

I've tried to call it directly from a cmd like you did @deerware, sometimes it works, sometimes it just crashes 🤷

commented

Thanks @deerware

The valued difference is WaitForExit as I see. Changed the package, Please try v1.5.2.

Sorry, I still can't reproduce the issue you have even by using the same code as you provided, so making changes on a guess only.

commented

@svishnevsky , unfortunately nothing has changed for me. The WaitForExit probably provides no significant difference, in earlier development I used a simple Wait() and it worked the same.

commented

It works when ran as a normal .exe, however it does not when you run it from a Windows' scheduled task since no GUI is supported at all.

I think the issue is related to how PDF-XChange Viewer / PDFtoPrinter.exe works, not your library - In the meantime I'll just run the application with a local account instead of a Windows task, but if you come across a solution, please let us know :)

commented

I was experiencing the same issue as mentioned above and did some research on it as well.

The latest version of this package resolves the issue on published versions, but local builds don't use the newer version of PDFtoPrinter because the .exe file is not overridden after a build. I tried updated the .exe on my local machine manually to that newer version and now I'm not getting the popup anymore.

Maybe this condition should no longer be checked in the .targets file:
PDFtoPrinter/build/PDFtoPrinter.targets

EDIT: update comment due to different cause of the issue (copy condition instead of included version of PDFtoPrinter_m.exe)

commented

@svishnevsky @bjarne-callewaert unfortunately in the end I did not use the PDFtoPrinter.exe at all in the end product, because even though I managed to suppress the popup, It was just too unstable. The main issue was that we had no way of getting the result of the call, whether it succeeded or details of why it failed, nothing. It also used to fallback to the default printer when invalid name was specified and we couldn't have that.

So we went with a paid solution in the end.