Hi Mikhail,
Ok, thank you for the clarification.
Still, let's make another attempt to avoid the "instanceof". In LWWindowPeer we have a good public
method - getPeerType() - which should return PeerType.EMBEDDED_FRAME for EF. Can it be used in the
code spot?
Regards,
Anton.
On 06.10.2014 11:08, mikhail cherkasov wrote:
Hi Anton,
it's window problem, toFront doesn't work for windows when embedded frame in
browser is active.
Mac ignores toFront, because it recognizes browser is active application and
doesn't
allow to java process activate its window.
So the problem occurs only when we call toFront on Windows and embedded frame
is active, hence
fix should be done in Window's toFront method.
Thanks,
Mikhail.
On 10/3/2014 5:48 PM, Anton V. Tarasov wrote:
Hi Mikhail,
Can we get rid of that "instance of"? I think it makes sense to create a new LWEmbeddedFramePeer
class with toFront overriden. Then we can do all the verifications gracefully and call
platformWindow.toFrontIgnoringOtherApps() (new method). I would also rename
LWCToolkit.activateApplication to match its native API call.
What do you think?
Regards,
Anton.
On 16.09.2014 15:39, mikhail cherkasov wrote:
Hello all,
please review the fix
http://cr.openjdk.java.net/~mcherkas/8038919/webrev.01/
bug: https://bugs.openjdk.java.net/browse/JDK-8038919
The problem appears if we trying to call toFront when embedded window is active
in browser, this
call is ignored, because for macosx the browser process is active and it ignores
[nsWindow orderFront:nsWindow] call to java process windows.
To fix this issue I use [NSApp activateIgnoringOtherApps:YES]; before [nsWindow
orderFront:nsWindow]
if an embedded frame is active window.
Thanks,
Mikhail.