App Closing, destruction order

Syntec

Hey Garry,

I've got a weird bug that doesn't always happen. I have my custom Titlebar which is a canvas based class. The window is a subclass of Window with some additional parameters one being HasTitleBarBorder As Boolean. The custom TitleBar is created at runtime and added to the window with Window.Add(MyCustomTitleBar). When the custom titlebar paints itself it checks for Me.Parent.HasTitleBarBorder. However sometimes when closing the window the titlebar will sneak in another paint event after HasTitleBarBorder has been destructed so I am getting "[Error] SYNWindowTitleBar.Paint Line 3: NothingReferenceException: Cannot read property 'HasTitleBarBorder' because the receiver is Nothing."

I can of course code around this, but I am curious of the order of destruction, I would assume the window calls the destructor of all controls before its properties but that doesn't appear to be the case.

Syntec

Syntec With further investigation adding If Me.Parent <> Nothing Then .... paint code .... End If fixes the issue so it suggest the window is being destructed before the control?

Garry

Thanks for the clear report and the follow-up. You've found a genuine runtime bug here, and your diagnosis is exactly right.

To answer your question about the order: there's no "window destructs its controls before or after its properties" step at all. When a window closes, teardown runs in this order:

The Closing/Close events fire.
Once the native window is gone, the window releases its children - it removes them and severs each control's Parent link at that point.
Destructors run separately under reference counting: an object is destructed when its last reference goes away. Since your Window subclass holds the titlebar in a property, the titlebar actually outlives the window's teardown.

So what you observed is the Parent link being severed during window release, before that last Paint had a chance to fire.

As for why the paint happens at all: a Canvas requests an automatic repaint whenever it's resized or re-rendered, and during the close sequence the renderer can still sneak in one final resize/render pass. That queues one last Paint event, but it gets delivered after the window has already severed the Parent link - so Me.Parent is Nothing inside the handler. It's intermittent because it depends on whether that final render pass beats the teardown, which is pure timing.

Your fix is the right one —-If Me.Parent <> Nothing Then around the paint body is exactly what I'd recommend, and it's good defensive practice for any Paint handler that reads its parent regardless of this bug.

I've logged it here: https://feedback.objo.dev/bug/1621 - the fix will stop the runtime from firing automatic Paint events once a window's teardown has begun.