Re: [AD] non blocking menu bug

[Eric Botcazou <ebotcazou@xxxxxxxxxx>]

> 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 ?).

No, close_menu() is probably sufficient for the problem we are discussing. We 
can always turn it into a full-fledged menu_message() later when we really 
need it.

> 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 this was an explicit design decision! I don't think the two engines can 
be running simultaneously without being first completely rewritten.

On the one hand, the dialog engine assumes that dialog objects have fixed 
position and size on the screen, and that they play nice with each other i.e 
no dialog object is allowed to overlap (even temporarily) another dialog 
object.

On the other hand, the menu engine assumes that menus can overlap any part of 
the screen without any harm, hence two consequences: the underlying screen 
must be fixed while a menu is activated and menus are allowed to draw 
themselves anywhere on the screen.

> 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,

I think that close_menu() (or any function dealing with menus) shall never be 
called directly by the user if the active menu is spawned by a d_menu_proc 
object.

Pending the rewrite I was previously talking about, we have to maintain a 
clear separation between menus and dialogs. In particular, when menus are 
invoked through the dialog layer (via d_menu_proc), their interface should 
be hidden behind that of dialogs. So we must implement hooks in the dialog 
engine so that, when a menu from a d_menu_proc is activated, we can control 
the menus through the dialog interface.

There is already such a hook: when a menu is activated, update_dialog() is 
basically redirected to update_menu(). If we were to implement close_menu() 
(and I'm willing to do so), we would need to devise hooks so that, for 
example, close_menu() is invoked when a MSG_END is sent to its parent 
d_menu_proc and invoked first when a MSG_END is broadcast to the whole 
dialog array containing the d_menu_proc.

>  (2) move the global active_menu_player into DIALOG_PLAYER, so that a
> running menu only disables the DIALOG_PLAYER that created it,

I guess this one is ok.

>  (3) have init_dialog() close any active menu.

I don't like it when init functions close something :-)

-- 
Eric Botcazou