Popups from applet

[Ike]

Is there a way to ensure that the following statement, which opens a URL in
a separate browser window, appear on top of the invoking one (i.e. that the
Z order of the web browswer instance being invoked by this line is closer to
the user than the web browswer instance that holds the applet from where
this line is invoked) ?

Applet.getAppletContext().showDocument(new java.net.URL(...),"_blank");

I am invoking this statement when a JToggleButton is "released," i.e. when
it's .selected state goes to false (I dont know if that has something to do
with it).

It seems this particular sequence of events causes the newly-created
browswer window to appear beneath the one that invoked it. Thanks, Ike

 

[Andrew Thompson]

Is there a way to ensure ..

No. ..We are talking applets/browsers/the internet?

The short and unerring answer to that question when
asked in relation to the above three is 'No'.

Applet.getAppletContext().showDocument(new java.net.URL(...),"_blank");

LOL! Especially 'showDocument'!

You cannot rely on that working at all, let alone getting
some particular z order! Here is a tester that I made
last year that investigates the UA's ability to use
the showDocument method at all.
<http://www.physci.org/codes/showdoc/>
(search the group for the discussion of that page)

With pop-up blockers, IE SP2 and such, you cannot rely
on 'showDoc' at all.

 

[Ike]

Pretty nice and extensive utility on that page Andrew, thanks. Incidentally,
you wouldn;t be aware of some sort of workaround would you? -Ike

 

[Andrew Thompson]

Please refrain from top-posting Ike. I find it difficult enough
to undersrtand the flow of some of these threads, without having
to read things topsy-turvy.

Pretty nice and extensive utility on that page Andrew, thanks.

No worries.

..Incidentally,
you wouldn;t be aware of some sort of workaround would you?

It depends what you mean.

Do your clients trust you enough to accept signed code to get
the effect you are after? Signed code opens all sorts of
possibilities not available to an untrusted applet.

 

[Andrew Thompson]

you wouldn;t be aware of some sort of workaround would you?

As an aside. My comments re reliability apply mainly to
the window appearing at all.

Once it appears, you might play with this idea to get it topmost..
- put an applet in the target page (do you control the
target pages as well?)
- attach a dialog/frame to that applet in the new page..
- Make the dialog visible.
- call toFront/call for focus
- set the dialog/frame invisible.

Something like that might do the trick.

You might even find that attempting to focus
the applet itself will bring the target page toFront(),
but I particularly noticed it with dialogs.

HTH

 

[Ike]

I'm NOT. It's -you-.....you're in teh Southern Hemisphere, remember? It only
appears that way to you!

 

[Ike]

Thanks Andrew. Yes, I control the target pages. Additionally, I AM running
this from a signed applet.

I THINK...perhaps the best solution is to open a dialog from the applet, and
display the pages therein, through a simple JEditorPane. In reading your
suggestions, it seems to me this is a far better way to handle both ensuring
that it will show, as well as it showing in the proper Z-Order I
desire. -Ike