1. Dinesh Babu Sivakumar
  2. PowerBuilder
  3. Friday, 30 September 2022 13:29 PM UTC

Hi everyone,

 

Do PowerScript language have any limit of No.of.Lines in a function or event in each and every PB objects? If yes, What are those limits for each PB object? Does this limit got improved in PB 2021 & 2022 version?

 

In our application, we found that one of a nested For loop, dynamic creating the tabpages and in each tabpage, userobject is inserted. My question is Do we have any limit of items under an user object? After 1250 - 1300  items on userobject, application crashes without any error prompt. 

 

 

Thanks,

Dinesh Babu

mike S Accepted Answer Pending Moderation
  1. Friday, 30 September 2022 15:49 PM UTC
  2. PowerBuilder
  3. # 1

" 1300  items on userobject "

thats a huge number of objects on one tab object, i assume that you mean they are all visual user objects?   windows can run out of resources and crash your application.   

 

instead of 1300 user objects, can you combine them into a small number of datawindows?  

 

 

Comment
  1. Dinesh Babu Sivakumar
  2. Friday, 30 September 2022 16:23 PM UTC
Yes Mike. they're all visual UOs. We've an alternate workaround for this but our application is growing and also so many places which was written similar like this. So my client wants to know is there any limitations on holding the user objects at a time though we went from 32-bit to 64-bit because of this issue.
  1. Helpful
  1. mike S
  2. Friday, 30 September 2022 17:00 PM UTC
windows can run out of resources

  1. Helpful
There are no comments made yet.
Andreas Mykonios Accepted Answer Pending Moderation
  1. Friday, 30 September 2022 14:03 PM UTC
  2. PowerBuilder
  3. # 2

Hi.

In our application, we found that one of a nested For loop, dynamic creating the tabpages and in each tabpage, userobject is inserted. My question is Do we have any limit of items under an user object? After 1250 - 1300  items on userobject, application crashes without any error prompt.

Can you tell us the amount of memory used by your application just before it crashes?

As for the first question, there was a limit in the past but it was large enough.

Read the following from help file. It mentions a limitation (the one I have in mind is a larger one).

There is an internal limit on the sizeof compiled Pcode on any script. Pcode is the interpreted language into which scripts are compiled. A script that exceeds this limit can be compiled successfully, but the error "Maximum script size exceeded" displays when you attempt to save the script. Note that the amount of Pcode generated from a given script is not directly proportional to the number of lines of code, so you might encounter this error in a script with 1200 lines of code, but not in a script with 1500 lines of code. To avoid receiving this error, move code to functions that you post or trigger in the event script.

Anyway, having really long scripts is considered a bad practice in modern programming languages, and should be avoided.

Andreas.

Comment
  1. Chris Pollach @Appeon
  2. Friday, 30 September 2022 14:56 PM UTC
Hi Andreas;

If you have a look at my STD Framework, you'll see that it tracks all memory use from individual object classes, DW buffers, variable storage, etc right down to the process ID level. It even starts notifying the Developer/ App user before the App's address space's memory becomes critical.

Have a look at the framework's Demo App to see these features in action. Even being able to give you graphs of your apps execution & also real time resource monitoring.

FYI: https://sourceforge.net/projects/stdfndclass/files/Applications/PowerBuilder/OrderEntry

HTH

Regards ... Chris
  1. Helpful
  1. Dinesh Babu Sivakumar
  2. Friday, 30 September 2022 15:14 PM UTC
Thanks Andreas for your response.



Around 270 MB of memory before application crashes (running on PB 2021 64 bit exe)

Noted on limitations which you described. It makes sense for me. Thanks again.
  1. Helpful
  1. Armeen Mazda @Appeon
  2. Friday, 30 September 2022 15:20 PM UTC
Have you correctly modified all your application code to be compatible with 64-bit? For example, there are data type changes to consider. Here is the 64-bit migration guide: https://docs.appeon.com/pb2022/migrating_32bit_applications_to_64bit/index.html

If you have correctly migrated your app to 64-bit, can you reproduce the problem with PB 2022?
  1. Helpful
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Friday, 30 September 2022 13:57 PM UTC
  2. PowerBuilder
  3. # 3

Hi Dinesh;

   What your app could be experiencing is the limitations of a 32 bit application. The MS-Windows O/S only allocates 4G of memory address space for any 32 bit App execution. It then installs part of its OS modules  in the upper address space. Leaving your app with just over 2G of memory left over to operate. Once your App consumes the 2G, the most likely ending will be termination of the App by the O/S without any chance of a recovery.

   In your case from what you have described of your App's design, the next best option would be to consider updating it to run as a 64 bit App. This will allow the MS-Windows O/S to allocate a much more robust address space for large object instantiation / large data set handling.

Food for thought.

Regards ... Chris 

 

Comment
  1. Dinesh Babu Sivakumar
  2. Friday, 30 September 2022 15:17 PM UTC
We're trying on 64-bit app in PB 2021 based on the suggestion given by Appeon in one of our client past conversation. Again in 64-bit, application crashes due to this.
  1. Helpful
  1. Chris Pollach @Appeon
  2. Friday, 30 September 2022 15:30 PM UTC
We would need to look at the specifics of the App crash to really determine what the real issue(s) are that are causing your crashing issues. The 64bit app crashes could possibly not be memory related but coding, Windows API use, 3rd party DLL, OCX, etc related.
  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.