...there are no EA-Builds of Java8 available anymore (Looks like Oracle does
not want people to test fixes for upcoming 8-update anymore)
EA builds of JDK 8u192 were supposed to be published last week, but
there was a glitch. I hope it will be fixed soon.
Having said that, I see that the issue Prasanta mentioned was fixed in
JDK 8u172, but I don't know whether your issue is the same. What
platform(s) do you see this bug on?
-- Kevin
On 7/31/2018 4:08 AM, Tom Schindl wrote:
Hi,
I give it a try but from the bug description and discussion I would have
assumed it deals with the opposite problems (Opening a Swing-Dialog from
an JavaFX-Application who uses Swing-Node).
I also studied the code to see if how you make a JavaFX-Stage having a
different owner but I could only find changes to AWT deal with this.
Anyways I'll try to get it the latest master running. The issue states
that it is fixed in 8u182 but only 8u181 is available and there are no
EA-Builds of Java8 available anymore (Looks like Oracle does not want
people to test fixes for upcoming 8-update anymore)
Tom
On 31.07.18 11:21, Prasanta Sadhukhan wrote:
Hi Tom,
I am not able to see the problem in latest workspace. I believe this
issue is already fixed by JDK-8185634.
Regards
Prasanta
On 7/31/2018 1:16 PM, Tom Schindl wrote:
Hi,
In one of our customers application we have major problems when
embedding JavaFX into SWT (but from my tests the situation is equal for
Swing).
In the end all windows (most commonly popup-windows) are affected
because they don't have a parent-window assigned and so they can be
hidden by the window embedding them - if the window opened is Modal like
eg the one from ColorPicker the JavaFX UI is also blocked.
To see what I mean just use this snippet below and do the following:
* Bring up the DropDown-List
* Bring up the custom color dialog
* Click somewhere in the JFrame
You notice the following:
* JavaFX Window is moved behind Swing-Window
* JavaFX UI is blocked
package test;
import javax.swing.JFrame;
import javafx.application.Platform;
import javafx.embed.swing.JFXPanel;
import javafx.geometry.Pos;
import javafx.scene.Scene;
import javafx.scene.control.ColorPicker;
import javafx.scene.layout.BorderPane;
public class TestSwingInterop extends JFrame {
public TestSwingInterop() {
setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
final JFXPanel fxPanel = new JFXPanel();
add(fxPanel);
Platform.runLater(new Runnable() {
@Override
public void run() {
initFX(fxPanel);
}
});
}
private static void initFX(JFXPanel fxPanel) {
// This method is invoked on JavaFX thread
Scene scene = createScene();
fxPanel.setScene(scene);
}
private static Scene createScene() {
ColorPicker picker = new ColorPicker();
BorderPane.setAlignment(picker, Pos.TOP_LEFT);
BorderPane p = new BorderPane(picker);
return new Scene(p);
}
public static void main(String[] args) {
TestSwingInterop s = new TestSwingInterop();
s.setBounds(100, 100, 1000, 800);
s.setVisible(true);
}
}
I've tested this on Java8 and Java9 but didn't had a chance to run it on
the latest master.
The problem is that the newly created JavaFX windows don't have the
Native-Window as their parent but the EmbeddedStage (who is not bound to
a native-window handle). It looks like EmbeddedStage has already been
prepared (see getRawHandle() : long) to support something like that in
future but com.sun.glass.ui.Window and its subclasses have never been
extend to create a window based on a pure long-pointer.
The only exception and the reason I guess the strategy would work was
used for Applets.
Before diving deeper into this I wanted to get a feedback from people
who know things better: Does the strategy of passing along the window
pointer (eg from SWT, don't know about Swing yet) to Glass and using it
as the parent pointer sound like a proper idea?
Tom
