Okay, will write a test case later today or tomorrow.
When trying to fix the issue I had, I noticed that in the function where it currently handles the logic for the menu key, it only received messages WM_MOUSEACTIVATE on pressing and WM_CAPTURECHANGED on release (in the tested application), but no mouse down or up messages, which caused the mouse down not to set the iMenuSysKey to 0 if the mouse button was pressed after holding alt (and additionally it also needs to not select the menu either when hitting alt while the mouse button is already down). (Also, when trying this manually on linux, gnome desktop wm mouse-button-modifier should be changed from Alt to something else, because it intercepts the alt-mouse combos before wine sees them it seems.)
So, since the function is not receiving all the messages here, which I assume are not all forwarded to the default handler by 3ds Max, would it be better to hook into the messages or mouse status at an earlier point in the code (to handle the first case where the mouse is pressed after alt)? And is there a saner way that can be used here to check if the mouse is down (when alt is pressed after mouse down)?
On Fri, Aug 10, 2012 at 8:14 AM, Dmitry Timoshkov dmitry@baikal.ru wrote:
Jan Boon jan.boon@kaetemi.be wrote:
Fix for bug #31434.
- this kind of change requires a test case, some of the changes look wrong
- formatting is broken due to not standard tab size
- patch introduces compile-time warnings, that's not accepatable
-- Dmitry.