On Thu, 16 Sep 2004 19:54:57 +0900, you wrote:
Hello,
Hi Dmitry,
This patch is causing a regression in Agent (still existing in current CVS).
If I use <alt>+W to access the Windows menu the program reacts as if I pressed just the 'W'. This is also an accelator key causing the current thread to be 'Watched'. Same thing with <ALT>+H, it should bring up the help menu. Now it causes the headers to display, normally behind the 'H' key. <ALT>-E works normal, probably because the 'E' is not accelerated.
this patch makes accelerator keys in my test MDI app (compiled with MSVC) work under Wine. The problem is that Wine correctly generates WM_SYSKEY* and WM_SYSCHAR messages when there is no focus window, but WM_SYSCHAR is not considered by TranslateAcceleratorW as a valid input.
Uhh, "The problem is that Wine correctly generates ...". Do you mean this is a hack?
BTW. Your other patch "Make message flow for MDI ..." fixes the problem with maximized/restored MDI windows in Agent, thanks.
Rein.
"Rein Klazes" rklazes@xs4all.nl wrote:
If I use <alt>+W to access the Windows menu the program reacts as if I pressed just the 'W'. This is also an accelator key causing the current thread to be 'Watched'. Same thing with <ALT>+H, it should bring up the help menu. Now it causes the headers to display, normally behind the 'H' key. <ALT>-E works normal, probably because the 'E' is not accelerated.
Perhaps a way used by TranslateAcceleratorW to detect Alt/Ctrl/Shift state is the source of the problem (it uses GetKeyState instead of the state passed in lParam). It seems that somehow it leads to a wrong match between an actual modifiers state and the key state in the accelerator table.
this patch makes accelerator keys in my test MDI app (compiled with MSVC) work under Wine. The problem is that Wine correctly generates WM_SYSKEY* and WM_SYSCHAR messages when there is no focus window, but WM_SYSCHAR is not considered by TranslateAcceleratorW as a valid input.
Uhh, "The problem is that Wine correctly generates ...". Do you mean this is a hack?
No, this is a correct behaviour, I sent a test case which confirms that.
BTW. Your other patch "Make message flow for MDI ..." fixes the problem with maximized/restored MDI windows in Agent, thanks.
Great, my work was targetting a similar problem in my app.
On Wed, 22 Sep 2004 20:20:31 +0900, you wrote:
"Rein Klazes" rklazes@xs4all.nl wrote:
If I use <alt>+W to access the Windows menu the program reacts as if I pressed just the 'W'. This is also an accelator key causing the current thread to be 'Watched'. Same thing with <ALT>+H, it should bring up the help menu. Now it causes the headers to display, normally behind the 'H' key. <ALT>-E works normal, probably because the 'E' is not accelerated.
Perhaps a way used by TranslateAcceleratorW to detect Alt/Ctrl/Shift state is the source of the problem (it uses GetKeyState instead of the state passed in lParam). It seems that somehow it leads to a wrong match between an actual modifiers state and the key state in the accelerator table.
I don't know very much about this, but I don't see any A/C/S key state checks in this path. Here is the part of the log that causes the problem (<ALT>+W pressed and a 'W' key press is detected ):
|0009:Ret user32.GetMessageA() retval=00000001 ret=005f55e9 |0009:Call user32.TranslateAcceleratorA(0002002a,000011af,00907268) ret=00628f2a |0009:Call kernel32.LockResource16(000011af) ret=407af748 |0009:Ret kernel32.LockResource16() retval=4040feb8 ret=407af748 |trace:accel:TranslateAcceleratorW TranslateAccelerators hAccel=0x11af, hWnd=0x2002a,msg->hwnd=0x10064, msg->message=0106, wParam=00000077, lParam=20110001 |trace:accel:translate_accelerator found accel for WM_CHAR: ('w') |trace:accel:translate_accelerator , sending WM_COMMAND, wParam=127d4 |0009:Call kernel32.GlobalGetAtomNameW(0000c02d,4070fa8c,0000003c) ret=40750c10 |0009:Ret kernel32.GlobalGetAtomNameW() retval=00000016 ret=40750c10 |0009:Call kernel32.lstrcpynW(4070fb04,403eb460 L"vmware.guest.windowsXP",00000010) ret=407770e6 |0009:Ret kernel32.lstrcpynW() retval=4070fb04 ret=407770e6 |trace:message:SPY_EnterMessage (0x2002a) L"vmware.guest.wi" message [0111] WM_COMMAND sent from self wp=000127d4 lp=00000000
After finding an accelerator for WM_CHAR (in this case SYSCHAR) the code in translate_accelerator() jumps straight to the handling of this. Again I'm not familiar with these parts, do you think key state checks should be added here?
Rein.
"Rein Klazes" rklazes@xs4all.nl wrote:
After finding an accelerator for WM_CHAR (in this case SYSCHAR) the code in translate_accelerator() jumps straight to the handling of this. Again I'm not familiar with these parts, do you think key state checks should be added here?
Since now I have a test case for accelerators I'll try to fix it to pass under Wine, right now it fails miserably.
On Thu, 23 Sep 2004 23:38:16 +0900, you wrote:
"Rein Klazes" rklazes@xs4all.nl wrote:
After finding an accelerator for WM_CHAR (in this case SYSCHAR) the code in translate_accelerator() jumps straight to the handling of this. Again I'm not familiar with these parts, do you think key state checks should be added here?
Since now I have a test case for accelerators I'll try to fix it to pass under Wine, right now it fails miserably.
Great. Attached patch is what I think Windows is doing. It fixes the problem with Agent, and hopefully also fixes your problem about no window with keyboard focus.
Rein.
"Rein Klazes" rklazes@xs4all.nl wrote:
Great. Attached patch is what I think Windows is doing. It fixes the problem with Agent, and hopefully also fixes your problem about no window with keyboard focus.
No, I don't think that your patch is correct. My tests show that WM_SYSCHAR is really handled by TranslateAccelerator. And I believe that TranslateAccelerator should not mess with focus/active windows at all, it already has all the required information in the passed MSG structure.
On Fri, 24 Sep 2004 08:34:12 +0900, you wrote:
"Rein Klazes" rklazes@xs4all.nl wrote:
Great. Attached patch is what I think Windows is doing. It fixes the problem with Agent, and hopefully also fixes your problem about no window with keyboard focus.
No, I don't think that your patch is correct. My tests show that WM_SYSCHAR is really handled by TranslateAccelerator. And I believe that TranslateAccelerator should not mess with focus/active windows at all, it already has all the required information in the passed MSG structure.
It does handle WM_SYSCHAR, and it gets the information from the passed MSG structure. I imagined this information is there just for this purpose.
But you are doing the tests and I have not. If the tests indicate that bit29 of lParam has no influence then my patch is wrong.
Rein.
"Rein Klazes" rklazes@xs4all.nl wrote:
It does handle WM_SYSCHAR, and it gets the information from the passed MSG structure. I imagined this information is there just for this purpose.
But you are doing the tests and I have not. If the tests indicate that bit29 of lParam has no influence then my patch is wrong.
I just sent a patch to wine-patches which adds a bunch of tests for accelerators and makes it pass under Wine. Could you please try it and report whether it works for you?
On Fri, 24 Sep 2004 20:59:51 +0900, you wrote:
"Rein Klazes" rklazes@xs4all.nl wrote:
It does handle WM_SYSCHAR, and it gets the information from the passed MSG structure. I imagined this information is there just for this purpose.
But you are doing the tests and I have not. If the tests indicate that bit29 of lParam has no influence then my patch is wrong.
I just sent a patch to wine-patches which adds a bunch of tests for accelerators and makes it pass under Wine. Could you please try it and report whether it works for you?
Yup, as far as I can tell everything works as it should.
Thank you,
Rein.
-
Dmitry Timoshkov -
Rein Klazes