Hi Chris;

  Since PB 9 there were many changes to the PB runtime that changed Event Firing order here and there. These changes were mainly in the PB 10, 11 & 12 versions of PB when Sybase was in control of the PB product. But there have been subtle changes to PB event & instantiation timings since my experiences with almost every PB version wince the PowerSoft days (PB 1.x). Appeon took over PB from SAP in PB 12.6 in July 2016 and have since modified the product from using VC++ 2010 compiler to now being built using the VC++ 2022 compiler (PB 2022 R3). So the newer C++ compiler versions could also have altered the odd event/instaniation timing order as well (none of which come to mind specifically).

  The key thing that I have always done (since PB 3.0) is to make sure that i never code anything in a Constructor or Open event in my PB Apps. Instead, use a PostConstructor and PostOpen event instead to place my initialization code. That way, you never have to worry about Instantiation timing changes and initial event firing order changes as all controls get instantiated. The other key aspect is to never trust an object pointer. Always check the pointer by using an IsValid() command before trying to reference the pointer.  HTH

Regards ... Chris

I would guess your application code was probably always fragile as it is dependent on events running in an undocumented order.

I am not sure anything has changed in PowerBuilder behavior specifically. But we have experienced the same issue in past experience of Powerbuilder upgrades - but only in a couple of places so no major drama.

If a window is closed, there is not much point continuing with a posted event. I suggest placing this line at the top of the scripts affected (hopefully not too many);

if not isValid(this) return