Lennart Borgman (gmail) wrote:
Do you mean that the second menu is created before returning from the
first w32_menu_show. It does not look so to me, but I might be
misreading the code. Is not "selection" that is returned from the
first w32_menu_show what is used to decide to do?
w32_free_menu_strings is also called from elsewhere, to handle the case
where the menus are cancelled by pressing ESC or clicking outside the
menu. This is what causes the problems, as it is not easy to figure out
whether old strings need to be cleaned up. The creation of the second
menu has fooled the cleanup code into thinking that
w32_free_menu_strings has not yet been called at the point where Windows
has finished destroying the menu (actually after a delay, because doing
so immediately caused problems in the past), so it goes ahead and
destroys the second menu's strings, which causes problems if the second
menu needs to redraw its owner-drawn strings (the title) again.