Here is a further analysis.

Summary of the tests performed on the image.

- In the column you find the environment on which the test was done: from Powerbuilder (version/build) or exe (build)
- in the row you find the measurement steps: the windows opened to measure the speed (in this specific case up to 7 windows).

At the intersection between row and column you find how many handles are used.

The analysis shows that when approaching 6000 handles the system begins to slow down annoyingly.
Further checks show that, in addition to the slowdown in the opening of the dddw, even normal activity (switching windows, opening menus, etc.) slows down.

Does anyone have information on the fact that >6000 handles the system slows down annoyingly?

Thanks in advance for your answers

Are you using Themes? If so is it better without the themes being applied?

Further tests show that if we approach 7000/8000 handles the system has that problem.
Below is the code we use for the test.
we also noticed that when we reach 10000 the program crashes.

Could it be? Does it happen to anyone?

====================================================================

Function long GetCurrentProcess () Library "kernel32"
Function long GetGuiResources (ulong hProcess,  long  uiFlags) Library "user32.dll"

long ll_guiresource, llguiobj
ulong        hdlProcessHandle
if isvalid(inv_statusbar) then

    hdlProcessHandle = GetCurrentProcess()
    llguiobj = GetGuiResources(hdlProcessHandle, 1)
    inv_statusbar.of_modify("handle", " " + string (llguiobj) + " / 9999")
    
    if llguiobj > 8000 then
        messagebox('Avviso', 'Stai raggiungendo il limite delle finestre aperte, è opportuno chiudere alcune finestre!', Exclamation!)
    end if
end if
===========================================================================

"when I click on the dddw to open them, they open late"

I missed this when i first read it.  so it isn't the retrieve of the datawindows that is  your issue, it is when a user clicks on the dddw that it does not display the drop down until a delay?

Do all DDDW's exhibit this issue, or only a few?

Resources are finite. Also, the more "things" PB has to keep track of internally, the greater I would expect the impact of overhead of managing all of the objects to increase.

Can the latentcy your app is experiencing be attributed to repeated data retrievals of large amounts of data in the DDDW's? 

Approximately how many rows in the DDDW's?

How many columns in the DW's?

How many rows in the DW's?

How many windows are open?

32-bit or 64-bit?

Hi Gimmy;

• Is this when running the App from the IDE, EXE or both?
• Does this only happen on your development machine?
• Do other developers/ App users have this issue?

Regards ... Chris 

are you caching the dddw values? 

do you have autoselect on, or are you manually retrieving them (in a posted event or triggered)?

do you retrieve all of them regardless of whether the user can see them (you mention many tab pages)?