Community
Participate
Working Groups
We observed that the Display.readAndDispatch is not able to read down/up key event from OS.PeekMessage(msg, 0, 0, 0, OS.PM_REMOVE) while the display thread is extremely busy. At this point, this issue is reproducible in windows XP SP2 machine only, but we are not sure whether the same issue will happen in other platforms. We made a test problem to simulate the issue, TestMissingKeyMain is a simple shell has 1 text field in focus by default, 19 Threads are running in parallel in order to generate a huge number of display runnables simultaneously. Press F1 + "123" instantly, ideally a dialog should be opened along with "123" displayed in a text field. If you cannot see the missing keystroke issue, please close the dialog and repeat the same steps (F1+"123") several times.
Created attachment 138690 [details] Main Class
Created attachment 138691 [details] Input Dialog
I swear we fixed this ...
Steve, this might be a dup of bug 256469.
We tested both 3.4.2 and 3.5 RC3 again, the missing key issue is still reproducible in my Test Program.
Our Microsoft Expert have done an investigation today by using SPY++, we observed that WM_KEYDOWN and WM_KEYUP were posted to the SWT test program successfully however the "OS.PeekMessage(...)" didn't receive it and finally missing keystroke happened. Please look at the image i attached. Missing key down/up events are highlighted in red color.
Created attachment 138773 [details] SPY++
I cannot reproduce this with the latest code no matter how fast I am typing the keys. This really looks like bug#256469, since I was able to reproduce it after I removed the fix for that bug.
Well I cannot reproduce this on 3.2 either. So maybe there is something else going on. What is our machine speed and OS version?
I believe you are asking our testing environment. My development PC is using Xeon Dual Core 2GHz CPU 2G Ram run in windows XP SP2.
(In reply to comment #10) > I believe you are asking our testing environment. My development PC is using > Xeon Dual Core 2GHz CPU 2G Ram run in windows XP SP2. > This is very similar to mine. So it is probably unrelated to the problem. I am just looking for reasons why you can reproduce it in 3.5 and I cannot.
Finally we found that this is caused by the Input Language setting in Control panel, I dont see the missing KeyStroke anymore after i removed the Chinese TW Input setting and remain US Keybroad only.
In addition we have to turn off the advanced text services in "Text Services and Input Language" -> "Advanced"
Works for me on Windows XP SP3. I have English(default), Chinese tawain, Japanese, Korean,etc. I have 'turn off the advanced text services' not checked. I have tested with HEAD and 3.2 Not sure how to proceed (since we can't reproduce it here). It seems to be a problem with your configuration (for example, IME is consuming the keys before SWT sees it).
We noticed you used SPY++ to see all keyboard messages for all 'Windows in the System'. Can you repeat the test but only for the application window (and windows of same thread) ?
Created attachment 139013 [details] SPY++ Missing Key
Created attachment 139014 [details] Spy++ without missing key after removed TW input language
These 2 new SPY++ results shown that all key events were captured and sent to SWT successfully, one thing we observed in the "missing key" result is that WM_CHAR cannot be posted to SWT and finally missing key happened. I wonder removing IME just hide the problem and not the root cause of it.
The missing WM_CHAR is the key for the problem. In a normal situation, when the NUMPAD1 is pressed, SWT sends the event to the app from WM_CHAR, not from WM_KEYDOWN. The native text widget also responds to WM_CHAR to insert the character. Andy, would you be able to load the SWT code and add some debug printfs? WM_CHAR messages is generated when TranslateMessage() is called for WM_KEYDOWN messages. Hack Display.readAndDispatch() and print when PeekMessage() returns a WM_KEYDOWN msg and see if we are calling TranslateMessage() for that message. I can see two possible cases: PeekMessage() does not return a WM_KEYDOWN or somehow Display.filterMessage() returns true. The first case indicates the IME stole the keys from SWT, the second indicates something wrong in SWT.
I did this before and found that no down key event can be detected in the readAndDispatch method's OS.PeekMessage(..).
Sorry, I see you mentioned this now. What could be happening as well is that the OS fails to post the WM_KEYDOWN message because the SWT event queue is full. All those threads are flooding the queue with WM_NULL messages. Could you comment the code from Display.wakeThread() and see if you can reproduce the problem?
I did this too and also we eliminated all outstanding async runnable object in order to make sure the issue is not caused by executing runnable instances. Unfortunately all these cannot resolve this problem.
(In reply to comment #22) > I did this too and also we eliminated all outstanding async runnable object in > order to make sure the issue is not caused by executing runnable instances. > Unfortunately all these cannot resolve this problem. > How did you eliminated the async runnables (exact change)? If I understand correctly the other threads are not doing anything other then eating cpu in that case.
I defined an empty Synchronizer and set it into the display object. Suppose it will not execute any runnable
So the threads are doing nothing, just spinning a while loop (eating CPU). The only other thought I have is to write a similar C app and see if the problem can be reproduced like that. I suspect it will have the same problem, since this test case is not doing much. If that is the case there isn't much SWT can do to solve it.
In our previous discussion, you mentioned there is a chance that SWT event queue is full which causes the OS fail to deliver the keydown event. Also we provided a strong evidence of SPY++ to prove that those key messages from window XP were sent to SWT successfully. Am i right? could you please advise how we can address the problem? whether you can provide us a debug dll to figure out the root cause and capture those incomming message in detail to a log file. Given that we can understand how/what to go further.
(In reply to comment #26) > In our previous discussion, you mentioned there is a chance that SWT event > queue is full which causes the OS fail to deliver the keydown event. We no longer believe this is the case, you removed the code that floods the queue and the problem still happened (see comment 22). > Also we provided a strong evidence of SPY++ to prove that those key messages > from window XP were sent to SWT successfully. Am i right? Not quite, it shows that the WM_KEYDOWN were sent, but not the WM_CHAR. SWT (and the native text control) expects the WM_CHAR. We need to know why WM_CHAR are not getting to SWT. We suspect the TW Input Method has a bug (note, IMEs has higher priority on the handling of all key events). Changing severity to major since we can't reproduce the problem on your machines (and this a very uncommon scenario). The WM_CHAR are generate when TranslateMessage of KEY_DOWN is called. Please, Try this version of readDispatch and paste here the output: public boolean readAndDispatch () { checkDevice (); drawMenuBars (); runPopups (); if (OS.PeekMessage (msg, 0, 0, 0, OS.PM_REMOVE)) { if (OS.WM_KEYFIRST <= msg.message && msg.message <= OS.WM_KEYLAST) { System.out.println("[1] Message received " + msg.message); } if (!filterMessage (msg)) { boolean result = OS.TranslateMessage (msg); OS.DispatchMessage (msg); if (OS.WM_KEYFIRST <= msg.message && msg.message <= OS.WM_KEYLAST) { System.out.println("[2] Message received " + msg.message + " result " + result); } } runDeferredEvents (); return true; } return runMessages && runAsyncMessages (false); }
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
