1. Alexander Manes
  2. PowerBuilder
  3. Wednesday, 7 December 2022 22:25 PM UTC

Hello everybody,

since PB2021 (and still in PB2022) customers irregularly report application crashes which we did not have before.
In a recent case we were finally able to track this down to a very special behavior we see in PB2021 and PB2022.

We would like to know whether this is a bug (that will be fixed) or whether this is a change by design which we need to understand entirely to make the appropriate changes to our applications?!

What we discovered:

In our applications, we react to Key Events, e.g. ESC for closing an applocation window, and we also react to custom User Events which are sent from a DLL written in C++ to our applications frame windows. 

We discovered that, starting with PB2021, when such a Key Event or User Event is fired, the normal code executing which is currently happening in our application is interrupted and the code of the Key Event or User Event (and all subsequent function calls from this code) is executed immediately. After all that code from the Key Event or User Event is executed, normal code execution is continuing from the step where it was interrupted.

This sometimes causes the crashes e.g. when opening a window is suddenly interrupted by the Key Event or User Event and the code of these events wants to access components which are not yet initialized because opening and initialization of the window is not completed yet.

Prior to PB2021, this behavior was different: e.g. the window opened completely and Key Events and User Events were queued in a message queue and executed afterwards. There was no interruption of code execution.

We were forced to do a quick workaround by writing a second event and calling this event with "Post Event ue_myuserevent2" from the original User Event "ue_myuserevent". Using "Post Event" actually restored the behavior we knew up until PB2019.

Why is this? Can anyone explain whether this is a bug or by design?

 

--- Code Examples and Call Stacks ---

The call stack in the first screenshot shows, that the opening process of a response window is suddenly interrupted, here in the middle of the resize event, when the User Event "ue_handlemessageext" is fired and reached our application's frame windows:

 

The second screenshot shows our workaround:

Inside the User Event that interrupts normal code execution, we use "Post Event" to a second event which contains the actual code we want to execute AFTER the window is completely openend. Of course, "Post Event" puts this at the end of the message queue.
But do we really need to go through all of our code and make these changes for PB2021 and following PB versions???

 

Armeen Mazda @Appeon Accepted Answer Pending Moderation
  1. Thursday, 8 December 2022 02:48 AM UTC
  2. PowerBuilder
  3. # 1

Hi Alexander,

Thanks for the detailed analysis.  Our team cannot reproduce this issue.  Before we can say this is a bug or expected behavior, we will need a test case from you so we can reproduce and analyze in our labs.  Please open a support ticket: https://www.appeon.com/standardsupport/newbug

Thanks,
Armeen

Comment
There are no comments made yet.
Alexander Manes Accepted Answer Pending Moderation
  1. Tuesday, 13 December 2022 14:48 PM UTC
  2. PowerBuilder
  3. # 2

Hi Armeen, Hi Chris,

I'm getting back to you here in the forum asking for further advice.

We tried to build a simple test case to file a formal bug report as you suggested.

However, in the new workspaces we built specific for the test case, we are not able to reproduce the issue.

Just like our real applications in which the problem occurs, our current test case includes the following:

- serveral libraries

- PFC

- a frame window, a menu and by clicking a menu item we open a sheet windows within the frame

- the sheet has a Key Event of ESC that closes the window when ESC is hit

- while the sheet window is opening (we do some calculations in a loop in the open() event to keep it busy for a while)

- we then hit the ESC button while the sheet window is still busy opening, but the event is NOT interrupting the code execution of our loop. This definitiely happens in our real applications - whatever they do, this is interrupted by the ESC key event or other custom user events.

 

Obviously I cannot upload our real application.

Of course we can add more and more functionality like database connections, etc. to the test case and hope that something triggers the faulty event handling, but we do not really know, where to start.

>>> Do you have any suggestions or a more analytical approach (from your deeper understanding of PowerBuilder internals) what could possible cause immediate code interruption and immediate execution of the code of the fired event? It must be something that is in our real applications, but not in the simple test case yet. We'd be happy for any bit of advice.

Thanks. Alex

 

P.S. - Chris, you had posted an interesting repsonse and link to something about different event execution orders in the latest versions of Windows 11. Have you deleted that? What was the reason for deletion, have the facts about that other case changed?

 

Additional technical information of things we tried to rule out in our applications and the test case (this is a list of things we had issues or new behaviours with since introduction in the latest versions of PB):

- themes: with or without did not affect the event execution order

- ghosting: on/off did not affect the event execution order

- accessibility: on/off did not affect the event execution order

 

Comment
  1. Chris Pollach @Appeon
  2. Tuesday, 13 December 2022 15:22 PM UTC
Hi Alex;

Yes, I deleted that post as I found out that "what I perceived" as an event order change in W11 running under PB 2022 was an issue with my STD framework's execution under W11 version 22H2. I have since corrected the framework code & all works as it should now.

To resolve this issue though it just took some focused time tracing the logic flow using the PB IDE debugger and analyzing my framework's extensive application logging to point me in the direction of the erroneous code flow. HTH

Sorry for the misleading post.

Regards ... Chris
  1. Helpful
  1. mike S
  2. Thursday, 5 January 2023 15:02 PM UTC
If you can consistently reproduce the problem, can you run your application in trace mode (not via the debugger, but with the /debug runtime option)?

yourPBApp.exe /pbdebug



that will slow down execution a lot since it writes out every step to the trace file. but it will show exactly what it is doing.

  1. Helpful
  1. Friedrich Bräuning
  2. Tuesday, 10 January 2023 09:50 AM UTC
Hi Mike,

i tried it with the /pbdebug option and still only got, that the Key event is executed from the Resize-Event without any further info why.

When the application then crashes, it also doesn't show why.

I created the trace-files for a working and a crashing workspace and uploaded it to the bug report.

https://www.appeon.com/standardsupport/track/view?id=9546
  1. Helpful
There are no comments made yet.
Friedrich Bräuning Accepted Answer Pending Moderation
  1. Thursday, 5 January 2023 08:21 AM UTC
  2. PowerBuilder
  3. # 3

Hi Armeen,

we opened a bug with a dummy-workspace which can reproduce the problem:

https://www.appeon.com/standardsupport/track/view?id=9546

Comment
  1. Chris Pollach @Appeon
  2. Thursday, 5 January 2023 14:25 PM UTC
Hi Frederich;

Thank you for the Test Case in ticket # 9546! I noticed two things about your test case that were not correct ...

1) The Response window was inherited from the "Sheet" window (basically inbreeding)

2) The Response Window was opened via an OpenSheet() command instead of an Open().

After correcting these two issues above (see attached), the Test Case behaviour seemed correct to me.

Note: I tested this with PB 2021 build 1509 and PB 2022 build 1892 on W10 & W11 versions 22H2

Regards ... Chris
  1. Helpful
  1. Armeen Mazda @Appeon
  2. Tuesday, 10 January 2023 14:30 PM UTC
Hi Friedrich, Please try what Chris said.
  1. Helpful
  1. Friedrich Bräuning
  2. Tuesday, 10 January 2023 14:36 PM UTC
Hi Armeen,

Chris was correct in regards to the Response-Windows.

The Error with the wrong Execution order of Events when setting the Width of an inkpicture in a Posted Event as described in the Bug still persists.



Regards Friedrich
  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.