Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (2)

Resolved New PB 2017 RTE broke our application.

  1. Issue
0
Votes
Undo
  1. Mark Hulser
    Mark Hulser
  2. PowerBuilder
  3. Monday, 11 September 2017 18:07 PM UTC

Hello, we migrated our application to PB 2017 in late July, and we were not aware of the change related to Rich Text / RTE.  We only have a couple places in our App that use RTE, but they are pretty important.  We have recently found out about the change to the new RTE control when we had to research very weird behavior on a window with RTE.  The window loads very slowly (compared to before), and it is not painting (i.e. rendering) properly.  If we remove the TER24.dll, the weirdness goes away; the window paints quickly and properly, but, of course, the RTE control does not work.

Apparently, we can revert to using the prior RTE control by purchasing separate licensing.  But why should I have to do that?  Why wasn't our prior RTE usage grandfathered somehow?

We're using PB 2017 Standard, build 1666.  We build in P-code 32-bit.  We're on the brink of a product release in October, which now we may have to delay.

Any suggestions?  Work-arounds?  Potential solutions?

Dissatisfied,

Mark Hulser

using different runtime-kit releases simultanly / ...
ItemFocusChanged event firing for button
Responses (2)
Tor-Egil Nygaard
Tor-Egil Nygaard Accepted Answer Pending Moderation
  1. Tuesday, 27 February 2018 13:41 PM UTC
  2. PowerBuilder
  3. # 1

We are experiencing the same problem and have reported this as a bug ( 834 ) with the following description

I think this is the same problem as ticket (bug) 629 and 364.

*Phenomenon:

Opening a window with the new RTE control is very slow when the application is run on a terminal server with printer redirection enabled, and the "default" printer is set to use the "Remote Desktop Easy print" printer driver. This happens when the client printer driver is not installed on the terminal server. If default printer is changed to a printer which is installed on the terminal server the window opens instantly.

 

*Reproduce Steps:

Create an application which only open a window with the new RTE control. Deploy it to a terminal server. Make sure that the client have a default printer which does not exist on the terminal server, but is redirected. Run the application. It takes 10-15 seconds to open the window.

If you change the default printer to a printer on the terminal server, not a redirected printer, and now the window opens instantly.

We have managed to reproduce this problem both when we connect using RDP and trough RDP Web app. Customers are also reporting the same problem trough Citrix.

 

Remark:

There is a workaround but it is not an easy sell to our customers. Open Local Group Policy editor on the terminal server and change the following setting:

Local Computer Policy->Administrative Template->Windows Components->Remote Desktop Session Host->Printer Redirection->Use Remote Desktop Easy Print printer driver first->Set to Disable.

Install the same printer driver as the clients default printer. Now the window with the RTE control will open instantly.

The problem exist both in PB 2017 and PB 2017 R2.

If possible we would need a fix for PB 2017 to service our customers.

Comment
There are no comments made yet.
Chris Pollach @Appeon
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Monday, 11 September 2017 19:59 PM UTC
  2. PowerBuilder
  3. # 2

Hi Mark;

  There are known issues with the RTF Control.  There are updates coming to the new PDF and RTF features in the new PB 2017R2 EBF release due out soon.

I would still recommend though opening a support ticket for this to make sure that we confirm and are addressing this issue if its truly a bug.

Q1: Are the PB runtime files on the same PC as your PB App?

Q2: Does this happen on your DEV PC or only on a deployed PC?

Regards ... Chris

 

Comment
Mark Hulser
  1. Mark Hulser
  2. Tuesday, 12 September 2017 13:45 PM UTC
Chris,



Q1 - the PB runtime files are deployed in the same folder as the application.



Q2 - On our two DEV machines, the window opens slower than before, but at least it paints correctly; possibly due to heftier memory(?).



We also noticed a spike in CPU usage due to the Print Spooler(?), splwow64.exe.



Based on your response, I'm assuming that there's nothing I can do right now to work around it(?).



 



Incidentally, we really wanted to use the Native PDF feature, but we backed off because it didn't seem accurate enough.



 



Thanks,



Mark

  1. Helpful
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.
We use cookies which are necessary for the proper functioning of our websites. We also use cookies to analyze our traffic, improve your experience and provide social media features. If you continue to use this site, you consent to our use of cookies.