Re: [AD] d_menu_proc MSG_DRAW handling

[Esaelon@xxxxxxxxxx]

In a message dated 5/29/03 3:10:19 AM Eastern Daylight Time, 
ebotcazou@xxxxxxxxxx writes:

>  "popup menus from the menu bar" sounds contradictory to me: don't you mean 
>  "scroll down menus from the menu bar" instead?
Well, I was under the impression that they were handled by the same code... 
but, I agree, that description seems more clear.

>  > Only the top-level menu bar is being redrawn.  I checked the source, and
>  > realized that that is all it does handle; d_menu_proc will not redraw 
> popup 
>  > menus in response to a MSG_DRAW.
>  That's right. d_menu_proc knows only of the underlying static dialog 
object.
Why not have it walk the active_menu_player tree and redraw them?

>  > I also noticed that there appears to be no way (in the external API, at
>  > least) to get a menu to redraw at all without using a d_menu_proc DIALOG?
>  That's right again. Redrawing is not a feature supported by menus 
themselves.

>  > I'll probably try my hand at figuring out how to modify the lib to redraw
>  > nested popup menus over the next few days, any input on any reasons for
>  > the current design or opinions on how I believe it should behave would be
>  > appreciated.
>  Dialogs and menus are two different beasts, driven by two different 
engines 
>  that don't play nice with each other:
>  - the dialog engine assumes that the objects have fixed size and position 
> and 
>  _do not overlap_,
>  - the menu engine assumes that no other drawing operation is performed 
when 
> a 
>  menu is pulled down, so no need for redrawing.
Understood.  However, with the non-blocking menu setup, the main loop which 
is calling update_dialog(), on a DIALOG array containing a d_menu_proc object, 
may alter the screen and wish for the (perhaps active) menu (particularly in 
such cases where it is the only portion of the GUI that is present) to be 
redrawn (dialog_message(MSG_DRAW)).

>  The bridge between the two engines is d_menu_proc but it is only a bridge: 
>  the two engines can't run simultaneously so:
>  - when a d_menu_proc is activated, the dialog engine is shut down and the 
>  menu engine is woken up,
>  - when no d_menu_proc is activated, only the dialog engine is active.
>  
>  What you want to do is to let the menu engine be driven by the dialog 
engine:
>  it means modifications of both engines. In particular, the dialog engine 
>  should be taught the notion of z-order so that it knows that a menu is 
drawn 
>  over another dialog object and sends its MSG_DRAW messages in the proper 
>  order.
>  
>  If you want to tackle this problem, I'd suggest you to use a very recent 
CVS 
>  snapshots because there have been some modifications made to this code 
>  recently.
D'oh.  I hadn't noticed that, though I was going to check before I submitted 
a patch.  The changes potentially break my planned code completely, arg.

My solution had been to have d_menu_proc(MSG_DRAW) walk through the 
active_menu_player tree and draw each child menu in order and update the player->saved 
bitmap for each; since d_menu_proc(MSG_DRAW) is not typically called with an 
active menu, it should only affect apps that meant for the child menus to be 
redrawn.  That would still work, but it would now be unable to tell any other 
dialog objects present to redraw themselves.  Back to the drawing board...

Charles Bilyue'