Andrew de Quincey adq_dvb@lidskialf.net writes:
I wrote a program in windows which had owner drawn menu items. Whenever I received the WM_DRAWITEM message:
- 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.
On Saturday 06 December 2003 19:46, Alexandre Julliard wrote:
Andrew de Quincey adq_dvb@lidskialf.net writes:
I wrote a program in windows which had owner drawn menu items. Whenever I received the WM_DRAWITEM message:
- 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.
On Thursday 11 December 2003 19:48, Andrew de Quincey wrote:
On Saturday 06 December 2003 19:46, Alexandre Julliard wrote:
Andrew de Quincey adq_dvb@lidskialf.net writes:
I wrote a program in windows which had owner drawn menu items. Whenever I received the WM_DRAWITEM message:
- 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.
Do you think such a thing should be implemented in wineserver or in the user32 DLL? To me, it would go in wineserver 'cos it has all the information available in one place... plus (to me) its kind of a hard constraint that should be implemented in the wineserver logic.
Andrew de Quincey adq_dvb@lidskialf.net writes:
Do you think such a thing should be implemented in wineserver or in the user32 DLL? To me, it would go in wineserver 'cos it has all the information available in one place... plus (to me) its kind of a hard constraint that should be implemented in the wineserver logic.
Most likely yes, it should go in the server. But first need to know what the exact behavior is supposed to be in all cases.
On Friday 12 December 2003 06:03, Alexandre Julliard wrote:
Andrew de Quincey adq_dvb@lidskialf.net writes:
Do you think such a thing should be implemented in wineserver or in the user32 DLL? To me, it would go in wineserver 'cos it has all the information available in one place... plus (to me) its kind of a hard constraint that should be implemented in the wineserver logic.
Most likely yes, it should go in the server. But first need to know what the exact behavior is supposed to be in all cases.
Can you give me some more ideas as to what you would like me to check? I'm not really a UI person....
Andrew de Quincey adq_dvb@lidskialf.net writes:
Most likely yes, it should go in the server. But first need to know what the exact behavior is supposed to be in all cases.
Can you give me some more ideas as to what you would like me to check? I'm not really a UI person....
Well, things like how the full GUI thread info looks like before and after, whether SetCapture returns an error, if so which error code, what ReleaseCapture does, etc. Basically try all the combinations you can think of.
-
Alexandre Julliard -
Andrew de Quincey