Re: JavaFX SWT and Swing-Interopt

[Michael Paus]

I did the test on a Mac.

MacOS High Sierra
OpenJDK12ea4
OpenJFX11ea20 (SDK)

I just ran the code and repeated the steps given by Tom.
* Bring up the DropDown-List
* Bring up the custom color dialog
* Click somewhere in the JFrame

Michael

Am 31.07.18 um 14:19 schrieb Kevin Rushforth:

I ran the test program on Windows 7 using JDK-11+24 plus my local build of openjfx 11, and I can't reproduce the problem. I suspect that Prasanta is correct in that this was fixed for FX/Swing interop by JDK-8185634 (on the FX side) and JDK-8187803 (on the AWT side). I don't know why you and Tom are still seeing this bug. What platform are you testing on?

Note that this won't help SWT interop, though. A similar fix might be needed there (once we understand why the Swing interop test program isn't working for some of you).

-- Kevin

On 7/31/2018 4:45 AM, Michael Paus wrote:

Hi Tom
I gave it a try with the latest OpenJDK12ea and OpenJFX11ea and I still
see the same baviour which you described.
Michael

Am 31.07.18 um 13:08 schrieb Tom Schindl:

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