If, rather than embedding Swing components, you are integrating with Swing by opening Swing dialogs, see the {@link AwtEnvironment} class.
This is an abstract that is normally used by extending it and implementing the {@link #createSwingComponent()} method. For example,
embeddedComposite = new EmbeddedSwingComposite(parent, SWT.NONE) { protected JComponent createSwingComponent() { scrollPane = new JScrollPane(); table = new JTable(); scrollPane.setViewportView(table); return scrollPane; } }; embeddedComposite.populate();
The Swing component is created inside a standard Swing containment hierarchy, rooted in a {@link javax.swing.RootPaneContainer}. The root pane container is placed inside an AWT frame, as returned by {@link org.eclipse.swt.awt.SWT_AWT#new_Frame(Composite)}
Note: When you mix components from Swing/AWT and SWT toolkits, there will be two UI event threads, one for AWT, one for SWT. Most SWT APIs require that you call them from the SWT thread. Swing has similar restrictions though it does not enforce them as much as SWT.
Applications need to be aware of the current thread, and, where necessary, schedule tasks to run on another thread. This has always been required in the pure Swing or SWT environments, but when mixing Swing and SWT, more of this scheduling will be necessary.
To schedule work on the AWT event thread, you can use:
(or similar methods in {@link java.awt.EventQueue})
To schedule work on the SWT event thread, use:
|
|
|
|
|
|
|
|
|
|