Andrew de Quincey adq_dvb@lidskialf.net writes:
The problem is that MSG.lParam is NOT necessarily in screen coordinates (even though the comment I have removed says they are). As I can't trust the MSG.pt either, this means using GetCursorPos() to determine the mouse position in screen coordinates.
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:
Andrew de Quincey adq_dvb@lidskialf.net writes:
The problem is that MSG.lParam is NOT necessarily in screen coordinates (even though the comment I have removed says they are). As I can't trust the MSG.pt either, this means using GetCursorPos() to determine the mouse position in screen coordinates.
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.
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:
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.
Probably the app is messing with the mouse capture.
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?
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:
Andrew de Quincey adq_dvb@lidskialf.net writes:
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.
Probably the app is messing with the mouse capture.
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?
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?
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.
Ah of course! I didn't think of that. Cool, thanks for the explanation.
Andrew de Quincey adq_dvb@lidskialf.net writes:
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?
That depends on what Windows does. This will probably require writing a test program to find out.
-
Alexandre Julliard -
Andrew de Quincey