menu: Fix for menu tracking problem version 2

[Andrew de Quincey]

On Saturday 06 December 2003 19:46, Alexandre Julliard wrote:
> Andrew de Quincey <adq_dvb at lidskialf.net> writes:
> > I wrote a program in windows which had owner drawn menu items. Whenever I
> > received the WM_DRAWITEM message:
> >
> > 1) I called GetCapture(), and compared it with the hwnd of main window
> > containing the menu. It pops up a message box if they are different.
> > 2) I then called SetCapture() with the HWND of the menu item itself.
> >
> > This approximately simulates what IDA is doing.
> >
> > The message box never popped up. This shows that even though the capture
> > was changed in one WM_DRAWITEM, windows had reset the capture to the
> > window containing the menu by the time of the next one. I also checked
> > the messages _were_ being sent using Spy++ (in case of a programming
> > error).
>
> That's a good start, but it's not enough to know what Windows is
> really doing. You should also check the capture window right after you
> call SetCapture; and you should use GetGUIThreadInfo and print out all
> the details, especially the GUI_INMENUMODE flag. My suspicion is that
> the capture is not allowed to change at all in menu mode.

Hi, I see where you're going with this... I added your suggestion into the 
WM_DRAWITEM message handler.

Yes, calling SetCapture() doesn't actually result in a change... (I called 
GetCapture() immediately afterwards)

Yes, GUITHREADINFO.wFlags DID have GUI_INMENUMODE during in the above.

I'll have a poke about in the SetCapture/GetCapture code... also I'll see if 
GUI_INMENUMODE is being changed by the current menu code.