1. Steve Dove
  2. PowerBuilder
  3. Monday, 29 March 2021 16:31 PM UTC

We recently migrated our powerbuilder  applications to 2019 R3 from 2017.  Since then, no applications will print to a network printer.  We get, "Error Printing on" plus the name of the printer and print server.  We ran the same application with the 2017 executable and it printed fine.

Mark Goldsmith Accepted Answer Pending Moderation
  1. Thursday, 1 April 2021 02:50 AM UTC
  2. PowerBuilder
  3. # 1

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

Comment
  1. Steve Dove
  2. Thursday, 1 April 2021 11:45 AM UTC
Good Morning Mark, We did most of our testing with one very simple datawindow and one complicated ( has embedded datawindows ). I just checked both and neither have a "Document Name" on the Print Specification tab. I'll have to think about how to test this now since our network administrator has changed the printer settings in the control panel on network printers with the issues ( IE, they are all working now ). It will probably be next week before I broach the subject with our net admin since tomorrow is a holiday and we try not to break things before the weekend. Thanks again for your feedback.
  1. Helpful
  1. Mark Goldsmith
  2. Thursday, 1 April 2021 12:18 PM UTC
You're welcome Steve and yes, I can appreciate not wanting to break things at all let alone before a long weekend ;) Thanks for checking the two datawindows and letting me know they don't have a Document Name identified as I believe that's relevant.



I'll look forward to any follow-up you can provide but I can also appreciate there may be push-back to changing something back to a non-working state, even if only temporary. Thanks again and enjoy your long weekend.



Regards,

Mark
  1. Helpful
There are no comments made yet.
Steve Dove Accepted Answer Pending Moderation
  1. Wednesday, 31 March 2021 19:47 PM UTC
  2. PowerBuilder
  3. # 2

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

 

Comment
  1. John Fauss
  2. Wednesday, 31 March 2021 20:10 PM UTC
That is great news, Steve! Thank you for sharing the details of the diagnosis & resolution.
  1. Helpful
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Monday, 29 March 2021 19:20 PM UTC
  2. PowerBuilder
  3. # 3

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

Comment
  1. Steve Dove
  2. Monday, 29 March 2021 19:25 PM UTC
Yes. As soon as the printer is selected, the error flashes on the screen and the print job clogs up the print queue. If "PrimoPDF" is selected as the printer, it works fine. thanks, steve d
  1. Helpful
  1. Chris Pollach @Appeon
  2. Monday, 29 March 2021 19:57 PM UTC
Interesting .... PrimoPDF is not a "real" printer though. Its a PCL to PDF converter using PostScript.

I searched the Support Database (some tickets you cannot see) and I did not find any direct related issues in this area. Only issues related to RDP or Citrix where the App did not detect the "Default" printer correctly (where no pop-up printer dialogue requested).
  1. Helpful
There are no comments made yet.
Steve Dove Accepted Answer Pending Moderation
  1. Monday, 29 March 2021 18:51 PM UTC
  2. PowerBuilder
  3. # 4

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.

Comment
  1. Steve Dove
  2. Monday, 29 March 2021 19:57 PM UTC
Mike S, thanks for your help. steve d
  1. Helpful
  1. John Fauss
  2. Tuesday, 30 March 2021 01:43 AM UTC
Thanks for the responses, Steve. It really helps paint a more complete picture of your situation.



Is there any commonality between the printer(s) you cannot print with (manufacturer, model, etc.)? Can you tell us the specifics of one printer, as someone else in the Community may have experience with same. Can I assume you can print from other Windows applications (Word, Excel, Notepad, for example) on your development machine to the same printer? Do you have a default printer designated in Windows on your development machine? If not, can you please select one and retest?
  1. Helpful
  1. Steve Dove
  2. Tuesday, 30 March 2021 15:37 PM UTC
Good Morning John,

- we can print from Word, excel, etc to the printers in question.

- All users have a default printer set up on their work station.

- We have two printers that are the same model. One works, one does not. Our systems guys has checked the drivers. They are the same.



We are going to do some more debugging with our powerbuilder code. We need to find where it is setting up the printer parameters. Until we have more info, Appeon will tell us it's a "network printer problem". The people that support our printers / copiers will tell us, "since it works with the previous version (2017), it's a software issue.

We'll keep you updated. thanks again for your help, steve d
  1. Helpful
There are no comments made yet.
Steve Dove Accepted Answer Pending Moderation
  1. Monday, 29 March 2021 16:56 PM UTC
  2. PowerBuilder
  3. # 5

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.

Comment
  1. John Fauss
  2. Monday, 29 March 2021 18:07 PM UTC
Can you print from the application if you are running the application from within the PowerBuilder IDE?

Does the compiled application have access to all of the PB 2019 R3 runtime DLL's?

Does the compiled application work acceptably except for printing? If not, what else is not working?

Is the application built upon a framework? If so, which one, and when was the last time the framework code/libraries were updated?

What version of Windows O/S are you running the compiled application on?

Are you running the compiled application on a Citrix server, or through remote desktop?



The reason I ask all of these questions is because you have given us no information about your environment, which makes it next to impossible to troubleshoot. There have been no systemic, large-scale printing-related problems reported with 2019 R3, so the cause of this issue is very likely due to something related to your particular environment, so please help us help you?
  1. Helpful
There are no comments made yet.
mike S Accepted Answer Pending Moderation
  1. Monday, 29 March 2021 16:49 PM UTC
  2. PowerBuilder
  3. # 6

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

Comment
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.