Simutrans crashes if a schedule window is open and a new game is loaded. Here is a patch. I do not know however if this patch causes difficulties at other places. The window-close function mainly called in destructors, so it should not break other things.
Since some of the windows are calling handles, which are not freed during destruction, it may result in crashes. Especially in MSVC, which is less forgiving for acessing objects during their destruction. Windows are only in the kill list, if they are in event handling. That means they are ****uming that there is still a valid "this" with all virtual functions, when event handling resumes. Closing the windows anyway seems like invitation of errors. Rather one needs to find out, why they are not closed by close all windows ...
The crash happens also on Linux.
Because 'inside-event-handling' is active: 'loading' is treated by the internal event handler.
How to reproduce:
Open schedule window of a convoi, load a game. What happens then:
-- All windows are moved to the kill list
-- Current world is destroyed including the convoi with open schedule window
-- Upon calling ~convoi_t it is tried to destroy the schedule window too, but since this window is in the kill list already, it is not found and hence not closed.
-- Then the kill list is processed. The schedule window is closed, but on closing it wants to cleanup schedule. However, the pointer now points to already freed memory - crash.
Then there might be more positions, where that fails, i.e. the clearing of the world must be moved outside from the event handler. Since the loading routine is directlz called from load frame, it should be deferred to the simmain (which would be the appropriate place anyway.)
New window handling implemented, a little less braindead than the old, but still with vast room for improvement.