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.