Re: [AD] non blocking menu bug

[Julien Cugniere <jcugniere@xxxxxxxxxx>]

Eric Botcazou wrote:
> > Does this mean that if I want to close a dialog from the code, I have to
> > wait for the user to close the menu?
>
> For the time being, I guess so. Remember that before the patch, menus were
> fully blocking (the control flow was stuck within a single function). I
> only detangled the situation so as to let the function return even though
> the menu is still active.

I understand, and I actually like this change :)

> > I could always try to simulate a keypress to the ESC key, hoping it will
> > discard the menu, but this feels rather ugly, no ?
>
> Indeed. I think the right approach would be to implement a menu_message()
> function that, upon being passed a menu, would instruct it to roll back its
> sub-menu hierarchy and properly return on the next call to update_menu(),
> very much like object_message() or dialog_message().

Yes, except that in this case, I don't have access to the menu_player, because 
it is created internally by d_menu_proc. Only the d_menu_proc object has 
access to it. 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. Note that the bug can be triggered any time a d_menu_proc has a 
menu opened and an object of the same dialog returns D_EXIT...

-- 
Julien Cugnière