DestroyMenu: Check if the menu is still used (fix for bug 1486)

[Michael Kaufmann]

Hi,

>>I've searched for other patches on this subject. I was very surprised to 
>>see that Andreas Mohr submitted a patch for the same problem about two 
>>years ago:
>>    
>>
>Oh, me? :-)
>
>True, I've been bitten by that issue at that time (and several applications
>failed on it, e.g. FilZip 2.01(?)), so I attempted to fix it.
>  
>
It's nice to hear from you! If you succeeded, I wouldn't have this 
problem now ;-)

>>http://www.winehq.com/hypermail/wine-patches/2002/08/0124.html
>>http://www.winehq.com/hypermail/wine-patches/2002/09/0039.html
>>
>>He describes the problem very well. It seems that his patch was not 
>>checked in, or it has been modified since.
>>    
>>
>cvs log should help here.
>I don't quite remember what happened, but I think we agreed that
>my patches caused some regressions with other apps, so it wasn't applied
>or so.
>Searching wine-devel around that time might help.
>  
>
I haven't found a comment about the revised patch. Comments about the 
first patch:

"Menu patch breakage": 
http://www.winehq.org/hypermail/wine-devel/2002/08/0396.html
"Re: Menu patch breakage": 
http://www.winehq.org/hypermail/wine-devel/2002/08/0399.html

>>My patch doesn't have the problem that he describes in the second post.
>>    
>>
>Hmm, the hMenu 0 problems?
>Why not?
>  
>
If the menu is assigned to a window, it calls GetMenu to check if the 
window's menu has been changed (as your second patch does)

>A quick hack (that doesn't break existing applications, as possibly
>mentioned on wine-devel around that time) may work and could be useful,
>but proper wineserver menu support fixing all this at the same time
>would be preferrable.
>  
>
Now I think too that my patch is a "quick hack", because it doesn't 
reset the menu handle of all windows displaying the menu.
But reusing a menu does not work in WINE anyway. I'll try to fix that.

Regards

Michael