[wx-dev] wxMac glitch : menu highlighting

[David Elliott]

On May 23, 2007, at 7:13 AM, Stefan Csomor wrote:

> Hi
>
>> Does this mean that in order to get rid of this visually annoying
>> behavior I
>> should create all my dialogs that might be called from menu commands
>> as
>> MODELESS. Is there any possible way to create modality then?
>
> just to make sure : are you talking about the situation of  
> selecting the 'About' menu in the minimal sample and having the app- 
> menu highlighted while the modal dialog box is shown. Or are you  
> talking about eg the widgets sample which does not have a handler  
> for the about menu item, and therefore the app menu stays  
> highlighted until you are clicking again ?
>
> I've just seen the latter and fixed that in WX_2_8_BRANCH in CVS,  
> the former actually is the way the Human Interface Guidelines  
> wanted it to be (giving you a clue from where ie which menu that  
> modal dialog came from, it said "You must continue to highlight the  
> menu title until the operation is complete").
>
> However the current HIG edition does not say this anymore, and  
> looking at Cocoa applications I see that they don't do that exactly  
> but they keep it eg highlighted until some other indication of  
> progress is given, eg from the time the Export command is given  
> until the Export dialog really appears in the 'Pages' application.  
> If we wanted to emulate that I could make sure that any Show... is  
> calling a HiliteMenu(0); thus effectively clearing that blue at the  
> moment something else is being shown on the screen ...
>
The Pages Export "dialog" is not a dialog but a sheet.  Sheets are  
document modal not app-modal.  The only type of dialog that runs its  
own event loop in Cocoa is an app-modal dialog.

Recall that the way this menu highlight is implemented is as follows:

1. User has just selected a menu item.  There's some blink animation  
and then the menu is closed.  The menu label in the menubar remains  
highlighted.
2. Somehow call the app-defined method/function for handling that  
item.  In Cocoa, it's target/action.  Carbon is a callback, whatever.
3. The application-supplied method does its thing.  If the method  
displays a modal dialog then an app-modal event loop is run blocking  
everything else.  If the method displays a modeless dialog or a sheet  
(which is only document-modal) then that modeless dialog or sheet  
will be shown at this point.
4. Method returns and so now the highlight on the menu label is removed.
5. Control returns to the event loop.

In the case of a modeless dialog or sheet the event loop is the  
primary one, not a modal one.  In fact, it's really just plain wrong  
to run a sheet with a modal event loop because the user could  
definitely switch to another document window, bring up the same  
sheet, then switch back to the first and cancel the sheet.  If you  
use modal event loops for this then a very odd situation occurs here  
because the event loop recursion in the application does not match  
the event loop recursion that the user sees.  If the user closes the  
first document then you can really have some crashing fun here if  
exiting the modal event loop (which won't truly occur until the  
second event loop is exited) requires any data from the window object.

Depending on how careful you are, this can potentially cause some  
serious problems.  There really ought to be a sheet API in  
wxWidgets.  On non-OS X platforms it should be implemented as a plain  
modeless dialog with the document window disabled.  On OS X the OS  
will disable the document window but as far as event loops go it  
should ideally still be implemented as if it were modeless.

-Dave