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???
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
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