Re: [AD] non blocking menu bug

[Julien Cugniere <jcugniere@xxxxxxxxxx>]

Eric Botcazou wrote:

> > You can also see it as a memory-leak: d_menu_proc creates a menu_player,
> > but doesn't destroy it upon receiving MSG_END; my patch aims at fixing
> > this.
>
> Does your patch unwind the whole hierarchy of sub-menus? If no, it doesn't
> really fix the memory leak.

Ah, ok, now I see what you meant. I thought shutdown_menu would take care of 
that, so my patch is wrong.

> The dialog engine is temporarily disabled when the menu engine is running;
> see the beginning of the body of update_dialog().

Right, I didn't think about that.

I've had a closer look at it and implemented "void close_menu(MENU_PLAYER*)" 
that unwinds a menu hierarchy and ensures the next call to update_menu will 
return FALSE, as you suggested (or do you really want to call it 
"menu_message" and have it take a message parameter in case we need more 
later ?).

However, I think this is not enough. Thinking more about it, when a 
d_menu_proc opens a child menu, this disables the dialog engine, like you 
pointed out. Currently there is no way to do anything about it, and the 
program needs to wait for the user to close the menu (the MENU_PLAYER created 
by the d_menu_proc is not accessible). But I can think of a few things that 
would help:

 (1) give the user access to a function that close any active menu so that the 
     dialog engine isn't disabled anymore,
 (2) move the global active_menu_player into DIALOG_PLAYER, so that a running
     menu only disables the DIALOG_PLAYER that created it,
 (3) have init_dialog() close any active menu.

What do you think about it ?

-- 
Julien Cugnière