Optimize dialog with frames

[simonb08]

How is it possible to optimize a dialog that contains frames?

Currently, I have a SmartDialog who contains 3 or more frames where fill-in are displayed.

When I run that dialog, the opening time is about 5 seconds.

We use OpenEdge AppBuilder 10.2B.

Thank you

 

[rzr]

What else does the Dialog do.. does it display data on these fillin fields...maybe this is taking more time? I'm just guessing....
You can use the PROFILER to check how long each section / block of code take to execute.

 

[RealHeavyDude]

Most likely your issue won't be a problem that is related to the number of frame you are using. I suspect that there is a logic that either retrieves data in a not efficient way or that the codes does something that it is not supposed to do.

Do you have any proof that the frames cause the performance issue?

Heavy Regards, RealHeavyDude.

 

[simonb08]

I have already done tests to determine whether it was not a piece of code that was double or was not optimized. The problem seems to be at the initialization of the dialog.

I did a test by storing the date and time in some places in the program. The problem clearly occurs when the dialog is called. When I click on my button to open the dialog, it takes 4 seconds before to reach the "definitions" section of the dialog. Between the "definitions" section and the end of "local-initialize" procedure, it takes only a second.

Thanks

P.S. Sorry for the late reply. I was out of the office last week due to illness.

 

[RealHeavyDude]

Since you are mentioning local-initialize I am suspecting that this is ADM1 (a framework that was introduced in Progress V8 somewhere at the beginning of the '90s of the last century and was commonly associated with smart objects). Anyway, unless you post some code I am afraid all we can do is speculate. All that I know is that Progress replaced the ADM1 with ADM2 in Progress V9 a few years later because it was to slow and "heavy". If I remember correctly it was based in loads of include files which made it that heavy and slow.

Heavy Regards, RealHeavyDude.

 

[simonb08]

Indeed, we are currently working with OpenEdge 10 with ADM1 because all our ERP software has been developed since 1998 ADM1 after we bought sources Varnet was the software used by my company at the time. However, we are studying the possibility of migrating to OpenEdge Architect in the coming years, but we still have much work to do before it happens.

Thanks

 

[simonb08]

I made ​​other tests this morning and I came to the conclusion that the reason for the opening is long is that my program is not compiled. I generated my .r file and then I removed my .w file to be sure I called .r file. Now, It said that my .w file is not available. So, if I'm not able to execute the .r file even if there is, it's probably that it's invalid. So the opening of my dialog is long because the program is compiled each time since not execute .r file.

I must find out why my program generates invalid .r file.

 

[simonb08]

I found the reason for my problem...

When I call my dialog, I put few arguments after INPUT/OUTPUT parameters. The problem is that we put these arguments, the .r file is not excecuted and the program is compiled each time.

In my case, as my dialog contains frames with multiple fields, it causes slowness problems because there are plenty of objects to initialize.


Thank you very much for your help.

 

[RealHeavyDude]

In case the source code is in the same directory where the .r file is located Progress checks whether the source has been changed and only loads .r when the source has not been changed. Otherwise the source code is compiled on-the-fly every time until you compile it or deleted the .r file. That behavior mostly is useful in a development environment where you want the most current version of your software to be executed.

You can override that behavior in supplying the -q parameter and Progress will always load the compiled version of a procedure as soon as there exists one. While that might be a good idea for a production environment because it speeds up the loading of the procedures it might not be a good idea in a development environment.

Heavy Regards, RealHeavyDude.