Tk Source Code

built from CVS on OSX 10.1.5... wish for OSX Aqua

in tKMacOSXMenu.c, menus are posted with TkpPostMenu.  It sets the static inPostMenu, then unsets it at all exit points from the function...  further calls to the process bail out if inPostMenu is set.

For a normal '-command' menu entry, this code is executed:
result = TkMacOSXDispatchMenuEvent(menuID, LoWord(popUpResult));

It waits for the command to return... and does this before the menu is cleaned up and inPostMenu is unset.

This is breaking some code I'm using where I call up a blocking dialog that uses a menubutton.  Since the dialog calls tkwait, it doesn't return, right away... therefore the menu cleanup isn't completed, and menubuttons in the dialog are not able to post their menus.

allow_comments - 1

Logged In: YES 
user_id=233501

It looks like a copy of the patch hasn't been attached to the patch report yet.  Would someone upload it so I can test?

Also... here's some test code:

proc blockdialog {} {
    global arrrg

    toplevel .dialog
    menubutton .dialog.mb -menu .dialog.mb.m -text MB   
    menu .dialog.mb.m
    .dialog.mb.m add command -label unblock \
         -command {set ::arrrg 1}
    pack .dialog.mb
    tkwait variable arrrg  
    puts "UNBLOCKED $arrrg"
}


menubutton .mb -menu .mb.m -text Bleh 
menu .mb.m 
.mb.m add command -label dialog -command blockdialog
pack .mb

Logged In: YES 
user_id=169107

I thought about this a bit, and browsed through the Windows implementation.  There, the TkpPostMenu function tracks the mouse, but doesn't invoke the command.  Instead the tracking function generates a WM_COMMAND event, and the handler for that event is what invokes the menu.  

So I submitted a patch (690507) which, instead of directly calling TkInvokeMenu, registers a DoWhenIdle handler to call that.  It probably fixes the problem mentioned here, though there is no test case to try against.

I don't feel comfortable enough with this to stick it in right before the release, however.