Skip to main content

I am currently working on the automation of a third-party app. At one point I need to perform a print screen on two of the pages to capture the customer’s visit information. Most other portals I use for this process have a “print screen” button in the UI, but this one does not.

I am using the Browser Automation package, and am first running a window.print() through javascript, after which I just send the Enter key to click the “Print” button on the pop up dialog. I then get the Windows SaveAs (only printer is Print2PDF) and can continue. This is all working, however window.print() treats the pop up dialog as blocking, so I have a timeout of 30 seconds before it moves on to the sendkeys action. I then have another 30 seconds before it sends the Enter key (just Simulate Keystrokes action), so I am losing a total of 60 seconds on each page needing printing. I could have up to a dozen pages per run.

Thus far, I have tried skipping the javascript and just doing Simulate Keystrokes on the page, but I get the same lag. I have also tried capturing the windows, and selecting the pop up dialog by its handle, hoping to at least cut the second 30 second delay, but no joy.

This is the only portion of the automation not running 5x faster than the old version which used Recorder actions. Just curious if anyone out there has a solid method for print screen through Browser Automation without the delays.

I used Developer Tools to execute a window.print() in both Chrome and Firefox. Chrome displays the print dialog slower, but neither takes too long.

Do you have a lot of network printers that are causing the dialog to take a long time to display? If you use Developer Tools (F12) in the browser, then execute a window.print() in the console, are you seeing the same performance issues? I’m interested in isolating what is causing the slowdown.

​@Aaron.Gleason that is a good point, when doing window.print() from the console I do not see a delay. In the bot itself, this is all it is doing:

 

The dialog box comes up immediately, however the runtime window stays on that executejs action for ~30 seconds:

 

It then moves to the Keystrokes action, where it sits for 30 seconds more before sending the RETURN], which is strange to me as this is just the normal Simulate Keystrokes on the active window.

 

As to printers installed, there is only the one Microsoft Print to PDF set to default.

 

That is very odd. I see something similar with Chrome. In fact, it just sat there on Run JavaScript until I pressed the Cancel button in the Print dialog box, then it finished the automation.

However, if I send a Control-P followed by an Enter (I used a key pacing of 500ms), it was very fast. No Run JavaScript necessary.

 

I get similar response if I open the page through the Browser package, but through the Browser Automation package it won’t find any Browser windows (guessing due to the way Selenium is handling the session), the only option open to me is the Application tab. That produces the delay finding the window (best guess same reason).

Nevertheless, I appreciate your help greatly. From your post I tried combining the CTRL+P and Enter, and bumping up the delay to 500ms. It still hangs but now only one action for 30 seconds, so I’ve effectively cut my delay time in half.

​@JLogan3o13

Use the updated version with print page to pdf directly, make sure to update version for all the tasks using same global session:
https://github.com/A360-Tools/Browser-Automation/releases/tag/A360BrowserAutomation-3.4.4
 



Execute JavaScript uses sync operation and will wait for result, suitable for sequential RPA process.
There’s a async method too but that will require users to understand async and callback.

​@Bot Dev updated this morning, worked like a charm. Many thanks

​@Bot Dev updated this morning, worked like a charm. Many thanks

My favorite type of community reply!

Reply


Terms & ConditionsCookie settings