Community
Participate
Working Groups
In the AWT, you can post key and mouse events directly to widgets. This will actually make the OS/peer widget behave as if the user had initiated the event. For example, one could cause a down arrow key press to occur in a list widget, and therefore cause the selection to change, as follows: java.awt.List myList = new java.awt.List(); java.awt.event.KeyEvent keyEvent = new java.awt.event.KeyEvent( myList, java.awt.event.KeyEvent.KEY_PRESSED, 0, 0, java.awt.event.KeyEvent.VK_DOWN, java.awt.event.KeyEvent.CHAR_UNDEFINED); myList.dispatchEvent(keyEvent); I would like equivalent capability in SWT. I know there is a private method called postEvent(), but I don't believe it actually causes a change in the OS widget. This is basically so I can implement the dispatchEvent() functionality in AWT. We have had several customer requests for this of late.
Notified Thomas Franzky (tfranzky@qnx.com) at QSSL of the problem.
SWT does not currently support this. Nor would it be easy to implement. We will discuss it, but can make no guarantees. SN to talk to McQ about it.
Pat Mueller mentioned that he thinks it would be extremely difficult (or perhaps impossible) to support this on Photon. Unfortunately, that is the most important platform from our perspective, since it's the target platform for the most vocal customer that is pushing on us for this.
I have asked SN to look at implementing this for the R2.1 timeframe (i.e. not for R2.01) but he has identified several issues which will require significant effort to resolve. In other words, you can not assume yet, that we will even be able to do this for R2.1. SN will update this PR with a description of the issues and continue to provide feedback as to any progress which is made.
Here is some example code that calls dispatchEvent() for virtual keys and regular keys: import java.awt.*; import java.awt.event.*; public class AWTEventExample { public static void main (String [] args) { Frame frame = new Frame (); frame.addWindowListener (new WindowAdapter () { public void windowClosing (WindowEvent event) { System.exit (0); } }); final TextField text = new TextField (); final List list = new List (); list.add ("A"); list.add ("B"); list.add ("C"); list.add ("D"); list.add ("E"); final Button button = new Button ("Key Char"); button.addActionListener (new ActionListener () { public void actionPerformed (ActionEvent event) { char [] chars = new char [] {'D', '\u00FF', '\u30A1'}; for (int i=0; i<chars.length; i++) { KeyEvent keyEvent = new KeyEvent ( list, KeyEvent.KEY_TYPED, 0, 0, KeyEvent.VK_UNDEFINED, chars [i]); list.dispatchEvent(keyEvent); keyEvent.setSource (text); text.dispatchEvent(keyEvent); } } }); final Button button2 = new Button ("Key Code"); button2.addActionListener (new ActionListener () { public void actionPerformed (ActionEvent event) { // int [] chars = new int [] {KeyEvent.VK_D, KeyEvent.VK_DOWN, KeyEvent.VK_TAB}; int [] chars = new int [] {KeyEvent.VK_DOWN}; for (int i=0; i<chars.length; i++) { KeyEvent keyEvent = new KeyEvent ( list, KeyEvent.KEY_PRESSED, 0, 0, chars [i], KeyEvent.CHAR_UNDEFINED); list.dispatchEvent(keyEvent); keyEvent.setSource (text); text.dispatchEvent(keyEvent); } } }); frame.add ("North", text); // frame.add ("Center", list); frame.add ("West", button); frame.add ("East", button2); frame.add ("Center", list); frame.pack (); frame.setVisible (true); } }
The code seems to work on Windows JDK 1.4 (although we did not stress it, for example there could be special code to insert characters for the text widget), but fails 100% on Linux JDK 1.4. It appears that even though the API is there, it does not work.
Who's JDK are you running on linux? If the IBM VM, is this a known bug which they plan to fix? Or is it that implementations are allowed to not implement this functionality...?
Note on the code. It appears they've finally allowed folks to change the source on events in 1.4, as setSource() on the event is gen'ing a compile error on 1.3. How many years did that take to happen? Wow. Code was easy to fix. Just created another event instead of wacking the source on first one.
I tried this code under jview (ms vm) on Win2K, and the list traversal works, but the text entry doesn't. The evidence begins piling up ...
Sure, this doesn't work everywhere for the JDK. But the bottom line is, the API exists and it works in some environments, and customers expect us to support it as many places as possible. Perhaps the customers aren't looking for it to run everywhere. I personally would be happy with the API existing, even if it were a no-op on some platforms. Photon is clearly our most important platform for this support.
On Linux, it was the Sun JDK 1.4.0. The code doesn't work on the IBM JDK 1.3.0 either.
Is this the same as 15025?
Sort of... once this feature request is implemented, then bug 15025 can be completed. In other words, doing the work for bug 15025 would involve adding support for posting key and mouse events to the OS (as bug 21083 describes), *plus* implementing a Robot-like class for an interface to scripting.
steve_northover@ca.ibm.com 2004-02-19 12:43 >> Is [21083] the same as 15025? David_Whiteman@us.ibm.com 2004-02-19 12:50 > Sort of... Not. abbotforswt https://w3.opensource.ibm.com/projects/abbotforswt/ already has a working SWTized Robot; its remaining defect involves difficulty finding non-Control Widget's https://bugs.eclipse.org/bugs/show_bug.cgi?id=38436 e.g. for driving cascading menus. (IIRC non-Control Widget's can usually be found by walking the hierarchy, but that always harms performance, esp when driving busy environments like a runtime workbench.) > In other words, doing the work for bug 15025 would involve adding > support for posting key and mouse events to the OS (as bug 21083 > describes) abbotforswt's Robot already does post key and mouse events, using a java.awt.Robot. We have working, JUnit-driven demos and test cases. HTH, Tom Roche, Rational Developer Model2 Tooling, abbotforswt admin
Tom, it sounds like you used java.awt.Robot to get around the lack of low level event posting support in SWT. This original bug report was a request to add it to SWT itself, for those folks who don't have or want AWT on the deployment platform.
David Whiteman 2004-02-19 13:37 ------- > Tom, it sounds like you used java.awt.Robot to get around the lack > of low level event posting support in SWT. This original bug report > was a request to add it to SWT itself, for those folks who don't > have or want AWT on the deployment platform. People tend to assume that java.awt.Robot is part of the big AWT/Swing bloat. In fact, j.a.R is just a way to put events into the native queue, and is required for J2SE compliance. It's part of every J2SE-compliant JRE, and, IIRC, at least one J2ME-compliant one (J9). So ... what runtimes are "those folks" planning to use?
Uh, J9. :-) There are platforms for which J9 is available that J2SE is not. I'm talking embedded/micro/small devices. java.awt.Robot is not part of Personal Profile, which is the AWT spec blessed by Sun for J2ME, so that's not an option even for Sun VMs on those devices (unless you want to copy all of J2SE down there).
And to bring this back to your situation, Tom, you can then realize that Abbot for SWT can't run on any J2ME platforms, since java.awt.Robot isn't available there. Of course, I'm coming at this from a different perspective than the person on the mailing list. That person was wanting to post key/mouse events using SWT only; I don't know if perhaps Abbot would work for them. But I do know that SWT is available on some smaller platforms, such as PocketPC, and so Abbot wouldn't be the answer there. In my situation, I work on the team that develops AWT for J9, and we use SWT for our peer layer. Since our AWT code is written in-house and runs on platforms that don't have Sun's AWT, we can't just call java.awt.Robot to do what we need to; we either need to rely on SWT functionality, or write our own natives for each platform we support (and we like the former, since SWT is the expert at writing platform natives).
Tom Roche 2004-02-19 13:49 ------- >> j.a.R is just a way to put events into the native queue, and is >> required for J2SE compliance. It's part of every J2SE-compliant >> JRE, and, IIRC, at least one J2ME-compliant one (J9). So ... what >> runtimes are "those folks" planning to use? David Whiteman 2004-02-19 14:27 ------- > Since our AWT code is written in-house and runs on platforms that > don't have Sun's AWT, we can't just call java.awt.Robot to do what > we need to; we either need to rely on SWT functionality, or write > our own natives for each platform we support (and we like the > former, since SWT is the expert at writing platform natives). OK. Note that, when the all-SWT robot arrives, abbotforswt looks forward to using it, presuming it is as capable as j.a.R is now (and has been for several years--since 1.3). But since https://bugs.eclipse.org/bugs/show_bug.cgi?id=15025 > Opened: 2002-05-01 14:39 we're not holding our breath ;-)
Note. bug 15025 (Display.post API to emit system key and mouse events) has been marked as fixed.
*** This bug has been marked as a duplicate of 15025 ***
