Hi Steve,

From your latest message I understand that you have found a solution and so that's great. I am curious though as to whether or not the datawindows in question that have a problem printing have a Document Name identified in the Print Specifications tab of the datawindow painter or was it left blank? If it's blank is it being provided in script via the print.DocumentName property?

As strange as it seems I have found that to be an issue on some printers but not on others, which makes nailing this down tricky as you've discovered. Not sure if it would be called a bug per se, we'll leave that to Appeon, but I too did not have that issue on a previous version of PB using the same printer.

You can test this out, even on a PB dev machine that has access to the network printer in question, by trying to print from the PB IDE via the datawindow painter without a document name entered...and it will likely fail...then provide a document name and see if it works. I believe the most important line in your modified code is job = PrintOpen("HeadCount", true) because you're now essentially providing a Document Name, although the argument in bold is called the jobname, but I believe essentially serves the same purpose in providing a name for the print queue, the print manager dialog box and the Spooler dialog box.

Thanks in advance for indulging my curiosity here.

Regards,

Mark

An update on our printer isues;

After much trial and error, we found if we replaced this one line of code;

dw_1.print(false, true)

with these four lines;

long job
job = PrintOpen("HeadCount", true)
PrintDataWindow(job, dw_1)
PrintClose(job)

it would print.  This was not an attractive solution due to the number of places that one line of code exists in our applications.  It would have been very tedious and time consuming to change.

Luckily, we do not have to use that solution.

Since we have two identical printers where one would print and one would not, our network administrator started comparing settings.   Here are the steps he took to fix our issue; 

1. First thing he checked was the port it was connected on. When it was installed from the print server it was added with a wsd port.
2. He changed it to a standard TCP/IP port and typed in the IP address.
3. He downloaded the latest print driver from HP and changed it to that driver.
4. Next, he tried to set the print driver to HP Universal Printing PCL6 from the latest driver, still not working.
5. Then he changed the driver to HP Universal Printing PCL6 (v6.6.0) and it worked.
6. He switched the port back to the original wsd and it quit working.
7. So it needed to be a standard TCP/IP port and have HP Universal Printing PCL6 (v6.6.0) driver installed

Thanks to everyone that gave us feedback, steve d

Hi Steve;

  Since you are using the command "print(false, true)" ... are you getting the System Print dialogue window on each print request that is failing?

Regards ... Chris

I apologize for the lack of info.  I appreciate any help and do not want to waste anyone's time.  But, I have new info.

When I was first notified of the print problem, I tried printing from the exe and from source on my development system.  I tried printing to the network printer closest to my office.  I received the same error.  So, I assumed it was a company wide problem and went into panic mode.

Since I started this chat, I discovered it's only with certain printers.  I can print to the network printer on the next hall way.  Currently, my system guy is comparing drivers and such.

To answer some of your other questions;

- We built new Windows 10 development systems just for this migration.

- Other than some pop up forms displaying in different locations, everything is running perfectly.

- When we deployed the source and copied the PBD's and EXE's to the new executable folder, we then copied all DLL and OCX files from C:\Program Files (x86)\Appeon\Common\PowerBuilder\Runtime 19.2.0.2670 to the same executable folder.

- We do have users that run this software via Citrix, RDT, and Dame Ware but the problem work stations are not.

Again, I apologize for being so vague.  After a month of testing, we rolled 2019 R3 into production last week.  This has been the ONLY major issue we've had.  Another programmer and I spent the morning trying to figure out where in the different PBL's it was setting up the printers.  We did not have much luck.  We've both been creating powerbuilder forms / data windows for several years but most of the utilities like the "Print" logic / setup was in place before we got here.

Any suggestions you have will be welcomed.

The powerbuilder code is very old.  Most of the utilities were written by programmers that are long gone.  This is all I have;

dw_1.print(false, true)

But,  like I said, PB 2017 prints.  PB 2019 R3 gives the error.

you should provide details on what you are doing in PB in setting printer stuff