1. Thomas Welker
  2. PowerBuilder
  3. Wednesday, 14 October 2020 22:34 PM UTC

Howdy All,

Recently one of our customers started experiencing repeated slowdowns when opening windows, slowdowns that were not present a few months ago. We investigated and determined that the slowdown was seemingly occurring during datawindow retrieval after the backing sql statement had executed but before control was returned to the user. The backing sql statement was completing in seconds, but the user couldn't interact with the window for up to minutes at a time. We could not replicate this anywhere else but on the customer's site.

Eventually we found the following knowledge base article which mentioned a similar issue: https://www.appeon.com/developers/get-help/knowledgebase/powerbuilder-datawindow-hangs-temporarily-after-retrieve.html. We tried applying the workaround mentioned (setting Accessibility=0 in the PB ini file) and it fixed the problem.

This gets us past the problem with this specific customer, but now we're debating whether to make this change to our pb.ini file going forward so that all customers get this fix. Is this a valid long term solution? Are there any negative side effects that could potentially result from this? Thanks!

Accepted Answer
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Wednesday, 14 October 2020 23:27 PM UTC
  2. PowerBuilder
  3. # Permalink

Hi Thomas;

   FWIW: I run all my PB App EXE's with a PB.ini using the Accessibility=O setting. Then only for users that need Accessibility support do I turn it on for those Workstations.

Regards ... Chris

  1. Chris Pollach @Appeon
  2. Thursday, 15 October 2020 18:14 PM UTC
I agree but first, please try PB 2019 R3 Beta if you can and see if that alleviates the problem via R3's accessibility changes that Armeen mentioned.
  1. Helpful
  1. Phil Kimbrough
  2. Thursday, 15 October 2020 21:18 PM UTC
Whether it works better in 2019 isn't the question for us at the moment. We'd like to know if this issue was present in earlier versions of PB (like 11, 12.1, 12.6) or was it introduced in PB 2017? We're trying to understand why this didn't seem to happen in 12.6 but does in 2017 as we have customers on earlier PB releases or our software.
  1. Helpful
  1. Armeen Mazda @Appeon
  2. Thursday, 15 October 2020 22:02 PM UTC
12.6 and 2017 is basically the same code base so you should have the same issue with 12.6. Keep in mind it is possible this issue has existed even in much older versions than 12.6 but you did not discover because you were on a different version of Windows OS, Citrix, etc. Even different build can introduce change behaviors or break things.
  1. Helpful
There are no comments made yet.
Christopher McCoy Accepted Answer Pending Moderation
  1. Thursday, 6 October 2022 10:42 AM UTC
  2. PowerBuilder
  3. # 1

for what it's worth: I see that you all have already made that an entry in the pb.ini file for PB22. It wasn't there in PB21 (C:\Program Files (x86)\Appeon\PowerBuilder 21.0).  

  1. Arnd Schmidt
  2. Thursday, 6 October 2022 12:16 PM UTC
Hi Christopher,

the default value for Accessibility has changed in PowerBuilder 2022.




  1. Helpful
  1. Christopher McCoy
  2. Thursday, 6 October 2022 12:27 PM UTC
THANK YOU for the reply! I did NOT know that I had to "...add a pb.ini file to the directory where your PB app.exe resides" and have that entry in there, of course..... I will go do that!
  1. Helpful 1
There are no comments made yet.
Ken Guo @Appeon Accepted Answer Pending Moderation
  1. Friday, 23 October 2020 08:10 AM UTC
  2. PowerBuilder
  3. # 2

Hi  Thomas ,

#1. About ACCESSIBILITY=0 in pb.ini

Previously a customer found that there is a DW performance issue in PB: under some circumstances, when there is a large amount of data and the Accessibility is used, the performance is slow and it occupies much memory.
We haven’t found out a better solution to this issue. We provided a workaround for the customer, set ACCESSIBILITY=0 in pb.ini to shield the DW Accessibility function to improve the performance.


#2. About Accessibility Insights crash Issue

You mentioned that when using Accessibility Insights in PB 2019 R3 Beta, PB crashes. I can’t duplicate this issue (the Accessibility Insights version I used is 1.1.1369.1, I used the default options and tested it Windows 10).
However, it can be replicated in PB 2017 R3 but can’t be replicated in R3 Beta.

If you still encounter this issue in PB 2019 R3 Beta, to better track and handle it, please submit a ticket in the Appeon Support system (https://www.appeon.com/standardsupport/newbug) along with a reproducible case. Thanks in advance.


There are no comments made yet.
Armeen Mazda @Appeon Accepted Answer Pending Moderation
  1. Thursday, 15 October 2020 18:10 PM UTC
  2. PowerBuilder
  3. # 3

When 2019 R3 is released, try that out and see if you have issues still with accessibility turned on.  We did major enhancements to accessibility in 2019 R3, and also R3 is a long-term support version.

  1. Armeen Mazda @Appeon
  2. Tuesday, 20 October 2020 23:46 PM UTC
If possible for you to submit your app for us to do testing, we would love to reproduce your issue with the beta version and make sure the final version doesn't have such issue. If you can submit, please open a support ticket.
  1. Helpful
  1. Phil Kimbrough
  2. Thursday, 22 October 2020 15:26 PM UTC
We're trying to track down what process is consuming these accessibility messages leading to slow performance at the customer site (it's not something obvious from looking at their running processes). For PB 2017 (which is still MSAA and not the new UI Automation system, right?), can you tell us what windows messages you would stop sending when ACCESSIBILITY=0 is set so we could use Spy++ to traces those messages? For reference, the OS at this customer site is Windows Server 2019.
  1. Helpful
  1. Phil Kimbrough
  2. Thursday, 22 October 2020 19:53 PM UTC
I just ran a test using Spy++ on the same app with ACCESSIBILITY=0 and with it not specified in the PB.INI file (which I assume means it defaults to = 1?) and in both cases, the same messages were written so I'm guessing that setting it to 0 means you don't make some windows API call (like SetWinEventHook) so that another process can't consume those message? Is that correct?
  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.