menu: Fix for menu tracking problem version 2

Andrew de Quincey adq_dvb at lidskialf.net
Sat Dec 6 11:35:30 CST 2003


This is an improved fix for menu tracking problems in IDA.

My first solution, which was to use GetCursorPos() was rejected because it 
didn't use the position of the mouse cursor at the time the menu message was 
received, among other reasons.

Mike Jackson suggested another possible solution using ClientToScreen(). I 
investigated this as well. Unfortunately, it doesn't work either. The problem 
is, for most menus, the coordinates are already in screen coordinates.. so 
calling ClientToScreen() again throws everything off.

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). 

This patch attempts to replicate this functionality. It resets the captured 
window immediately after issuing the WM_DRAWITEM message, in case the 
application has changed it. Note this code only occurs on WM_OWNERDRAW menu 
items, as this should be the only situation where this problem can occur.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wine-menuposition-2.patch
Type: text/x-diff
Size: 823 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-patches/attachments/20031206/4ce6e765/wine-menuposition-2.bin


More information about the wine-patches mailing list