1. François Rossignol
  2. PowerBuilder
  3. Friday, 11 January 2019



I'll try to summerize the problem I encounter

I use PowerBuilder 2017R3


I have a window

That window has 3 arrays of userobjects in the instance variables

u_datawindow idw_reports[] (the report datawindow)

u_sort_options iuo_sort_options[] (contains two datawindow)

u_report_criterias iuo_report_criterias[] (can contain anything from checkboxes radio buttons datawindows etc.)


the window has a menu that contains a list of reports.

The same window is used for several lists of reports (menu is loaded dynamicaly)


When I click on the menu I call a function open_report that acts like that.


if a_report_is_opened then 

this.idw_reports[displayed_report_index].visible = false

this.iuo_sort_options[displayed_report_index].visible = false

this.iuo_report_criterias[displayed_report_index].visible = false

end if

if report_has_already_been_openened_once then

this.idw_reports[report_index].visible = true

this.iuo_sort_options[report_index].visible = true

this.iuo_report_criterias[report_index].visible = true




this.openUserObject(this.iuo_report_criterias[report_index],u_report_criterias ,...)

end if

The openuserobject on iuo_report_criterias may trigger some post_construtor events.


Works great but I have performance issues

Each time I open a new report it takes exponentialy longer to open. if you open a report in first it will take a second, if you open the same report in 5th it will 10 seconds. It does seem it's not the actual open process but the application hangs.


During my tests:

I did not retrieve the report datawindow to avoid any unecessary overlay.

I activated the Trace with a trace all activities.

The open_report function always performs the same (modulo a few milliseconds) wether you open the same report in first or 5th or 10th)

I tried to time the open_report function and the result is consistent with the trace.

The application will hang the same wether I openuserObject or visible = true

The post_construtor events always performs the same as well.

You can see on the screen that objects are correctly displayed before the application hangs.


I checked the performance of the calls in the trace file, and this is where I'm at a loss, there is nothing there consumming the CPU appart from the opens and post_constructor, and they perform consistently across the board.


That means there os something that freezes my application for a few seconds (more and more with each call) and that is not traced by the PB Trace.


In my open_report function if I replace the visible = false with closeUserObject() the hang is less visible but it still happens.


if I drop my arrays for a non array instance variable of each type there is no problem.

That lead me to think that the problem comes from the object arrays getting bigger (even if the object in it are being destroyed).


The non array approach is not an option because I do not want my users to have to re-retrieve the reports they already have retrieved. I do not want them to lose the report criterias they filled each time they want to open a news report in the same window.


I need help to be able to pinpoint where the performance issue is coming from.

If you have any advice on how I could to the same thing without the object arrays I'd be gratefull.



Brad Mettee Accepted Answer Pending Moderation

There is an internal debugger that can be used, but not sure how much help it may be. It's undocumented and might take some trial and error to see which options give you the most output from object creation. Turning on the debugger will open a console window with results of current activities. DO NOT CLOSE THIS WINDOW, it will immediately end whatever you have running in the IDE or compiled EXE without any warning, and no events will be fired (it's like sending 'kill -9' in the *nix world, or "end task" in windows task manager).


1 - turn on logging console (warning, closing this will close PB dev env with no warnings or close events getting triggered, ditto for running exe)
3 - show memory related calls
20 - show internal calls
21 - pbl management - by itself, doesn't create log
23 - show internal calls
26 - show internal calls
27 - function pointer loading, structure pointer assigns
29 - object group processing
30 - show function/event calls
31 - show pcode trace
32 - show external func calls
34 - show pcode line execution
38 - event queue processing
42 - show internal calls
43 - global symbol references dump
44 - class ref
45 - routine symbol table dump
int ii_options = {1, 30, 32, 34}  // set this to whatever combination of flags you want from the above list

long l
sting ls_filename = "rt_debug.txt"

l = rt_dbg_outfile(ls_filename) // debug output file is required, or nothing works
for l = 1 to upperbound(ii_options)
l = rt_dbg_on()			// enable rd_debug

// open objects here

// clean up
for l = 1 to upperbound(ii_options)
l = rt_dbg_off()		// disable rt_debug
There are no comments made yet.
  1. 2 days ago
  2. PowerBuilder
  3. # 1
François Rossignol Accepted Answer Pending Moderation



First of all thank you for your answers.


No, I'm not running low on ressources, this is a new application which is still under development.

Yes, I loop for closeUserObject during the close event of the Window.

Yes, on the cirteria user object there can be anything and each one of them is different.

ExportJSON is not an option for the report DW because we have some Composite and Crosstab.

I know about the GetFullState/SetFullState which we used in a previous application but it crashes the application when the data is "large-ish".


For my tests, I open the application (either IDE or compiled version) , go straight to the report Window and open different reports (without retrieving them) this way I make sure it's not about ressources or bad cleanup.


What bothers me is that the aplication hangs and consummes CPU that is unaccounted for in the PB trace file.


I'm going to make my own timestamped trace to identify where the problem happens.




There are no comments made yet.
  1. 2 days ago
  2. PowerBuilder
  3. # 2
Olan Knight Accepted Answer Pending Moderation

Francois -

   Are you running low on platfrom resources after the 5th+ OPEN call?

   I have found that for my somewhat large corporate application it will lock up when I have too many other windows open on the platform. The app behave appropriately for a while, then just freezes. Expanding the platform resources resolved this issue for us.



There are no comments made yet.
  1. 5 days ago
  2. PowerBuilder
  3. # 3
Kevin Ridley Accepted Answer Pending Moderation

Do you have different buttons/functionality on each userobject?  If not you could save each datawindow either using GetFullState to a blob, or ExportJSON to a string and recreate the DWs as needed.

There are no comments made yet.
  1. 5 days ago
  2. PowerBuilder
  3. # 4
Chris Pollach Accepted Answer Pending Moderation

Hi  François;

   At the closure of this Window dialogue - are you using the CloseUserObject() method to clean up all the UO resources?

Regards  ... Chris

There are no comments made yet.
  1. 5 days ago
  2. PowerBuilder
  3. # 5
  • Page :
  • 1

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