Hi Alexander, Sounds reasonable. I am OK with usage of addChildWindow() in this case.
Thanks, Dmitry > On 25 Sep 2017, at 13:05, Alexander Zvegintsev > <alexander.zvegint...@oracle.com> wrote: > > Hi Dmitry, > > From my understanding JavaFX stage can't be easily integrated in JDK to > support orderWindow() approach, > > addChildWindow() is a native(and the simplest) way to maintain one window > above other one, should be called only once. > > IIUC the main concert of JDK-8080729 that child windows jumping to parent's > display upon focus receiving, this is not an issue with current fix, > > because addChildWindow() will be called only upon dialog creation in case of > JavaFX-Swing interop. > > Jump may happen if user want to create a child swing dialog on display other > than JavaFX stage's one, > > but such rare scenario can be easily workarounded on a user side by calling > setLocation() right after setVisible() call. > > So I would prefer to use addChildWindow() to make this fix as simple as > possible. > > > Thanks, > Alexander. > > On 23/09/2017 21:21, Dmitry Markov wrote: >> Hi Alexander, >> >> In CPlatformWindow class you call CWrapper.NSWindow.addChildWindow() to >> place a window above JavaFX stage. The usage of addChilWindow() or/and >> removeChildWindow() may cause ‘jumping window issue’ in multi-monitor >> environment, see JDK-8080729 for more details. >> >> To avoid possible problems in multi monitor set-up I suggest that you should >> replace addChildWindow() with orderWindow() or use some another approach to >> locate the window above the stage. >> >> Thanks, >> Dmitry >>> On 22 Sep 2017, at 06:56, Alexander Zvegintsev >>> <alexander.zvegint...@oracle.com> wrote: >>> >>> Hi Phil, >>> >>> Please review the updated fix with reflection incorporated >>> http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/01/ >>> >>> New issue created JDK-8187803 >>> <https://bugs.openjdk.java.net/browse/JDK-8187803> as JDK counterpart of >>> this issue. >>> >>> Thanks, >>> Alexander. >>> >>> On 21/09/2017 22:25, Phil Race wrote: >>>> Some procedural comments : >>>> Since 90% of this is in AWT code, I'd have thought awt-dev should be >>>> included here. >>>> I've added that list. >>>> >>>> And apart from needing separate bug ids, I don't see why the bug below is >>>> confidential. >>>> >>>> >>>> I agree with what Kevin pointed out off-line that as in the dialog case, >>>> the FX side >>>> of the code can use reflection and simply be a harmless non-functional >>>> no-op >>>> if the SwingAccessor does not provide the new method. >>>> >>>> BTW >>>> 264 inline HWND GetOverridenHWnd() { return m_overridenHwnd; } >>>> should be "dd" not "d". >>>> >>>> -phil. >>>> >>>> On 09/21/2017 03:38 AM, Alexander Zvegintsev wrote: >>>>> Hello, >>>>> >>>>> please review the fix >>>>> >>>>> http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/00/ >>>>> >>>>> for the issue >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8185634 >>>>> >
