Andrew de Quincey adq_dvb@lidskialf.net writes:
This is wrong, you have to use lParam, as the comment says. And the coordinates are always in screen coords when we are tracking the menu. Something else must be going on here.
On Thursday 04 December 2003 22:59, Alexandre Julliard wrote:
OK, I'll keep looking. I've printed out the coordinates I get in the tracking loop. As soon as the popup menu is displayed, they are immediately "off" by the position of the menu on the top of the screen. Its fine on menus without popups.
Out of interest, why do you specifically have to use lParam? Since it is (supposed to be) in screen coordinates, surely GetCursorPos() has to return the same values?
Andrew de Quincey adq_dvb@lidskialf.net writes:
Probably the app is messing with the mouse capture.
Some programs want to modify menu behavior by changing the message parameters, or even sending new messages that don't correspond to real events. And even if this wasn't the case, using GetCursorPos() is wrong since it returns the current mouse position, not the position at the time the message was generated.
On Thursday 04 December 2003 23:34, Alexandre Julliard wrote:
You're right. If I comment out the SendMessage(..., WM_INITMENUPOPUP) in MENU_ShowSubPopup, it works properly with the original code.
IDA *is* changing what has been captured. If I add a MENU_SetCapture(hwndOwner); just after the WM_INITMENUPOPUP is sent, this fixes the problem. Is this an acceptable solution?
Ah of course! I didn't think of that. Cool, thanks for the explanation.
Andrew de Quincey adq_dvb@lidskialf.net writes:
That depends on what Windows does. This will probably require writing a test program to find out.
-
Alexandre Julliard -
Andrew de Quincey