This refers to the msvc-Version of wxWidgets 3.3.x:
It seems that the new 3.3.x-Series of wxWidgets introduced some severe changes to the life-cycle of top-level window-instances, especially concerning the wxEVT_CLOSE_WINDOW. The current API-Doc still states that the Default-behaviour is that Destoy() will be called on a window-object when this event is raised. But throughout many applications I found out, that this does no longer happen reliably with wx3.3.x, no matter if no custom close-handler is installed at all or the installed custom handler calls Skip() on the event.
This leads to very strange behaviour of wx-Apps, which did not happen with all previous releases. Sometimes frames cannot be closed with the close button ('x') other applications will refuse to close on windows-logoff. Others just crash (CoreDump) on App-Close possibly because of double deletes on window objects 'at exit' (scalar deleting destructor)? Most of the times it helps to install a custom close-Handler and call Destroy() explicitly, but this gets critical e.g. in case more than one handler is installed on the close-event and you don't know which one gets called first.
Did I miss a breaking change in the api? Is there any docs I missed which describe a new intended behaviour?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
There have been no intentional changes to wxEVT_CLOSE_WINDOW and I have honestly no idea what could result in what you're seeing. Please try to reproduce the problem in one of the samples or try debugging it yourself, there is nothing we can do here without being able to see it ourselves.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
Thank you very much for the quick response, even though this is exactly the answer I was afraid of... I already spent so many hours trying to create a minimal conclusive example, reliably reproducing one of the effects, but no luck yet. I just hoped that this would probably ring a bell with someone else or point to some other issue report. I'll keep trying to isolate the issue from within the very large and complex codebase I'm working on, and I hope to be able to get back to you with a reproducable example.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
If you get reproducible crashes, they should be relatively straightforward to debug. If it's really a double delete, you need to check where is the object (window?) deleted the first time and second time (when it crashes).
BTW, which platform do you use?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
Platform is MS-Windows (MSVC 2022). wx-Version is 3.3.2. I'm struggling a bit with debugging what exactly happens e.g. on 'Session-End', when logging off from Windows and the OS tries to close all running apps...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
Logging off or shutting down is a different case and there have indeed been changes there in wxMSW, see #24903 and the related commits, i.e. at least
In particular the latter might be relevant if you're doing something unusual in your OnExit().
There could be bugs left, but normally things should work fine if you don't try to do anything "smart" on shutdown.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
Wow. Thanks a lot for the hints. I will work my way through all of this and get back, if I find something suspicious.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()