FYI I'm planning a session for this year's Elevate 2020 on how to use the PFC resize service standalone without the full PFC where you can just register your userobject with the service.  The service will then manage resizing your object based on the window resizing.  I will be posting code to CodeXchange also.

Kevin

Hi Chris,

thank you for your valuable advice.

Just one question: If we ignore the pbm_size (resize) event, how could we handle situations when the user is resizing the window by dragging the border? How could we even notice?

Regards,

Peter

Hi Hua,

Good news that PowerBuilder 2019 R2 MR version (build 2328) has been officially released. The issue you reported has been fixed in this release. Please download and install it to verify the issue you reported and let us know if any problems.
You can get the installer from our Downloads portal at https://account.appeon.com/download/2019.

We welcome all feedback from you!

Regards,
Ken

This bug should be fixed in an MR that we will release next week.

Hi Hua,

Thanks very much for providing the test case.

We reproduced it on our end and will do further research to figure it out. We will keep you posted on the progress.

Regards,

Ken

Hi Ken

Yes, looks like it may related theme function.

My app is a MDI with a theme and there is a child window with a custom visual object. I manually added a resize event with event ID 'pbm_size' in this custom visual object. When I open the child window from the menu the resize event gets triggered before constructor. But if I rename the theme folder to something else to prevent loading the theme the app triggers the constructor event w/o resize event execution when I open the child window, which is what I expected.

Attached is mini-app in PB2019R2B to simulate the situation above.

The workaround is simple:

1. add an instant var in the custom visual object

2. mark the var in constructor event

3. in resize event check the var to see if the constructor is executed or not. If not do not continue.

Hope explanation above helps you to identify the issue.

Regard

Hua Yan

Hi Hua,

Thanks for providing this issue and for finding out a workaround!

We’d like to further understand the issue you mentioned so that we could better improve the PB products. I tried but still am not able to reproduce this issue. Please try to do the following

1. Is the Theme functionality enabled in your application? If yes, please disable the Theme and then try and see if the issue persists.
2. Can you create a small reproducible case about this issue? If yes, please submit a bug at our support ticketing system (https://www.appeon.com/standardsupport/newbug) and also upload this small case when submitting it. Thanks in advance.

Regards,

Ken

Thank you Chris for your quick response.

It is a good design idea to prevent the misbehavior from version to version. I cannot do this right now to our system because of so big effort on this. But I have a workaround to handle this particular situation since I know what the issue is.

Thanks again.

Regards... Hua

Hi Hua; 

   I've seen these type of issues throughout PB versions since the days of PowerSoft. Here is the proper way to fix this for now handle and the future. Remember that the resize event can be fired multiple times during the Open() processing and event firing order / timing can change between PB releases. Here is what I do since PB 3.0 ...

Do not use (map) the pbm_size event on any UO.

• Do not rely on the Constructor to initialize.
• Create a "Post Constructor" unmapped event on every object class. Perform 99% of all initization here.
• Create a User Event on all custom user objects to handle resizing. Use this to also pass along resize chaining when user objects are nested inside other user objects. This allows for 100% encapsulation.
• Do not rely on the Window class's open event to initialize. Instead, create a "Post Open" event and do 99% of your initialization on the UE.
• Following the above architecture design since PB 3, I have never had migration behaviour issues even when migrating older code to today's PB2019R2.

Food for thought.

Regards... Chris