Community
Participate
Working Groups
Created attachment 206684 [details] snippet to demonstrate the problem A key event with the character field set to a lower-case letter results in a lower-case letter even if the Shift key is currently pressed. I would expect the event with the lower-case letter to be so modified during the post process, that an upper-case letter is produced. I've attached a snippet that demonstrates the problem. On Linux GTK the expected upper-case 'A' event is printed, but on Mac OS X 10.6.8 an 'a' event is printed instead. This is a big problem for the Jubula project, as it prevents simulating typing upper-case letters as well as symbols that require use of the Shift key.
On further testing, I've found that physically holding down the Shift key while running the snippet produces the desired upper-case letter. So maybe the problem is that Shift key events from Display.post() do not actually change the Shift key state (i.e. Shift is not added to the stateMask of other key events).
Has there been any progress on this bug? The inability to simulate upper-case character entry with Jubula for Eclipse RCP applications on Mac OS X is a big problem for Jubula users. Is there perhaps some way to work around the problem, if it won't be solved in the near future?
I'm investigating this bug...
Created attachment 209029 [details] patch We are posting the events to the kCGSessionEventTap, but our event source uses the kCGEventSourceStateHIDSystemState event table. The patch posts the events to kCGHIDEventTap. Also, key events are not being sent for characters with shift modifier, for eg: performKeyCharEvent(display, SWT.KeyDown, 'A') doesn't send any event. The patch fixes this case too. Silenio, can you please review the patch?
Hi Lakshmi, Currently Display.post() doesn't honor SWT.MOD1 key state too. Should it be fixed with your patch?
(In reply to comment #5) > Hi Lakshmi, > > Currently Display.post() doesn't honor SWT.MOD1 key state too. > Should it be fixed with your patch? Hi, yes, the patch fixes Display.post() for all the modifier keys.
I see that there is not yet a target milestone for this bug. What are the chances of the bug being fixed for Indigo SR2?
Lakshmi - I tried the patch out on 10.6 and it didn't seem to work either with the snippet Zeb provided or with Snippet 146. Were you testing on Lion?
(In reply to comment #8) > Lakshmi - I tried the patch out on 10.6 and it didn't seem to work either with > the snippet Zeb provided or with Snippet 146. Were you testing on Lion? Hi Bogdan, I'm using Lion. But, I've tested the patch using Snippet146 & test snippet on both Lion and 10.6.8 and the fix is working on both. Can you please try again?
I tried the patch again with 10.6.8 on an Intel Core 2 Duo vs my Intel Core Duo. The patch worked better on the Intel Core 2 Duo, but running Snippet 146 showed that it still isn't working 100%. If you modify the string used in Snippet 146 to "LOvE ThE MetHOD" and run with the patch, you will see that some letters show up as capitals that are not supposed to and vice versa. This can be made better by a adding Thread.sleep() after each display.post but it would be good to see if we can come up with a fix that would work without having to add extra sleep calls to the client code. Since we're not sure if this is the final shape for this patch, I'm going to retarget this for the 3.8/4.2 release.
Created attachment 209612 [details] patch-2 Modifying and running the snippet as given above several times, I'm able to reproduce the problem. And adding sleep in the client code before the post does fix this problem. I did a web search and this looks like a problem in cocoa. (found a thread on the same problem -->http://stackoverflow.com/questions/2008126/cgeventpost-possible-bug-when-simulating-keyboard-events that suggests that it is problem in cocoa.) In Display.post() we are already calling Thread.sleep(1) before CGEventPost(). But, this doesn't seem to have any effect. So, I moved the sleep() above so that it is called before CGEventCreate*(). This makes calling a series of post() with modifier keys much more reliable, but I still do get a few modifier keys that are out of order. Silenio, can you please review the patch and suggest how to fix this?
Created attachment 209613 [details] patch-2 modified patch
Created attachment 210218 [details] patch with Thread.sleep() after post Hi Lakshmi, did you try putting Thread.sleep(1) after the call to CGEventPost(). It seems to work at least as well as your current patch and there is less duplicate of code. I have not been able to make it fail with either patch.
Created attachment 210330 [details] modified testcase Hi Silenio, Attached the testcase(modified snippet from comment #0) used for testing. I have tried the above patch but the modifier keys *sometimes* appeared out of order, same as with my patch. However, adding sleep call after display.post() in the client code fixes this problem. I agree that the above patch is better as it avoids code duplication. Should we go ahead and commit the patch?
(In reply to comment #14) > Created attachment 210330 [details] > modified testcase > > Hi Silenio, > > Attached the testcase(modified snippet from comment #0) used for testing. > > I have tried the above patch but the modifier keys *sometimes* appeared out of > order, same as with my patch. However, adding sleep call after display.post() > in the client code fixes this problem. I cannot reproduce the problem on Lion. > > I agree that the above patch is better as it avoids code duplication. Should we > go ahead and commit the patch? Yes, commit it. The behaviour is certainly better with the patch.
Thanks Silenio & Bogdan! Fixed in 3.8 stream > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=442b778a907836e56f477706a2d1ac6bfa6d0970
*** Bug 346296 has been marked as a duplicate of this bug. ***
This bug is not fixed. It does seem that the underlying problem is with Quartz event services, as I'm able to reproduce the problem relatively easily with a small amount of C code calling into Apple's framework. This is causing a problem with some tests we have in a project using Display.post; as an example if we want to simulate a user entering an email address "user@example.com", the shift key up event seems to be delayed at times, resulting in "user@EXAMPLE>COM" or something similar. Adding more sleep time alleviates the problem to an extent, but really only reduces the frequency of the problem occurring; it does not eliminate it.
