Wine menu woes

[Geoffrey Hausheer]

I have an application that seems to work very well, except that the menus
don't work (in wine, they are fine in Windows)

The app is located here (free download):
http://www.acumeninc.com/download/tzmax50v3.21.exe

After some debugging, I found that the app creates a menu, then destroys
it and recreates it using different titles.

Something like:
hMenu = CreateMenu();
hSub1 = CreatePopupMenu();
...
hSub2 = CreatePopupMenu();
...
AppendMenu(hMenu, MF_STRING | MF_POPUP, hSub1, "&File");
AppendMenu(hMenu, MF_STRING | MF_POPUP, hSub2, "&Other");
...
SetMenu(hWnd,hMenu);

while(GetMenuItemCount(hMenu))
    RemoveMenu(hMenu,0, 0x400); //Note: this just detaches the menus

hOldMenu = hMenu;
DestroyMenu(hMenu);
hMenu=CreateMenu();

AppendMenu(hMenu, MF_STRING | MF_POPUP, hSub1, "[&File]");
AppendMenu(hMenu, MF_STRING | MF_POPUP, hSub2, "[&Other]");

if(hMenu != hOldMenu)
   SetMenu(hWnd, hMenu);

That last line is where wine and Windows differ.  In windows, the menuid
is always different, so hMenu never equals hOldMenu.  In wine, we reuse
the menuid, so hMenu always equals hOldMenu.  Since SetMenu didn't get
called after the last createMenu, the menus don't work.

I have no idea why the app implements its menus this way, but I removed
the 'USER_HEAP_FREE( hMenu );' in DestroyMenu() and the menus work fine,
as expected (obviously this isn't a fix, just a validation that the code
behaves this way).

I've included a test app that does the above if anyone is interested.

As a secondary issue, for some reason the 'Exit' item executes the
ID_DO_SOMETHING code instead of the ID_FILE_EXIT code.  It doesn't do
that in windows (it correctly exits instead).  I don't think it is
related, and i haven't looked into it, but I thought I'd mention it.

Thanks,
.Geoff

[Phil Krylov]

Hello Geoffrey,

Saturday, April 10, 2004, 9:20:56 PM, you wrote:

GH> I have an application that seems to work very well, except that the menus
GH> don't work (in wine, they are fine in Windows)

GH> The app is located here (free download):
GH> http://www.acumeninc.com/download/tzmax50v3.21.exe

GH> After some debugging, I found that the app creates a menu, then destroys
GH> it and recreates it using different titles.

If it can help: it is also an issue with The Bat! - the menus stop
working after their recreation on language change (from English to
another).

[Mike Hearn]

On Sat, 10 Apr 2004 12:20:56 -0500, Geoffrey Hausheer wrote:
> That last line is where wine and Windows differ.  In windows, the menuid
> is always different, so hMenu never equals hOldMenu.  In wine, we reuse
> the menuid, so hMenu always equals hOldMenu.  Since SetMenu didn't get
> called after the last createMenu, the menus don't work.

Good catch! Our menu handles are created entirely client side, I think the
right way to fix this is to merge the menu handles with the other handle
hashtables like I think Windows does it.

Ulrich has a patch to do this. What is the status of that work Ulrich?

thanks -mike

[Ulrich Czekalla]

I do have a patch that needs to be cleaned up that moves menu management to
the server. It's a rather large patch because all the menu painting and
event handling had to be rewritten. My plan is to finish it up once we
release our next version of Crossover.

/Ulrich

On Sat, Apr 10, 2004 at 11:07:14PM +0100, Mike Hearn wrote:
> On Sat, 10 Apr 2004 12:20:56 -0500, Geoffrey Hausheer wrote:
> > That last line is where wine and Windows differ.  In windows, the menuid
> > is always different, so hMenu never equals hOldMenu.  In wine, we reuse
> > the menuid, so hMenu always equals hOldMenu.  Since SetMenu didn't get
> > called after the last createMenu, the menus don't work.
>
> Good catch! Our menu handles are created entirely client side, I think the
> right way to fix this is to merge the menu handles with the other handle
> hashtables like I think Windows does it.
>
> Ulrich has a patch to do this. What is the status of that work Ulrich?
>
> thanks -mike