Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion Ensuring popup is on top

Received: by 10.58.189.35 with SMTP id gf3mr7025359vec.11.1352816553617;
        Tue, 13 Nov 2012 06:22:33 -0800 (PST)
X-BeenThere: google-web-toolkit@googlegroups.com
Received: by 10.52.240.239 with SMTP id wd15ls9077278vdc.5.gmail; Tue, 13 Nov
 2012 06:21:46 -0800 (PST)
Received: by 10.52.91.109 with SMTP id cd13mr4377283vdb.15.1352816506408;
        Tue, 13 Nov 2012 06:21:46 -0800 (PST)
Date: Tue, 13 Nov 2012 06:21:45 -0800 (PST)
From: David <levy...@gmail.com>
To: google-web-toolkit@googlegroups.com
Message-Id: <9b16d463-a7d3-4f47-9bbc-ed05295de525@googlegroups.com>
In-Reply-To: <120fa895-aabf-4419-b8d8-0327935aac54@googlegroups.com>
References: <120fa895-aabf-4419-b8d8-0327935aac54@googlegroups.com>
Subject: Re: Ensuring popup is on top
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_1635_14014442.1352816505903"

------=_Part_1635_14014442.1352816505903
Content-Type: multipart/alternative; 
	boundary="----=_Part_1636_22183564.1352816505903"

------=_Part_1636_22183564.1352816505903
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

I would think that z-index is the better solution.  Your mechanism for 
opening the popup ( rather than the popup itself) should be the one making 
the determination as to which z-index to use.   
Beyond a "system error" type of message, I personally don't think it's good 
UX to have popups throwing popups... but a requirement is a requirement.


On Tuesday, November 13, 2012 8:05:04 AM UTC-5, Thomas Lefort wrote:
>
> I have a use case where I do need to show one dialog on top of the other. 
> The problem is that those dialogs are reused across the application and if 
> the one that should be on top for the use case happens to have been open 
> (in another use case) before the one that should be below, it is not 
> visible (covered by the other one) because (I believe) it was inserted in 
> the DOM before.
>
> Is there an obvious way of doing this? Currently, the two strategies I can 
> think of to make sure the show method could always ensure that a dialog is 
> on top of the others are the following:
> - zindex, scanning the list of open popups and check for the higfhest 
> zindex and setting the zindex of the one I am showing to zindex + 1
> - detach/reattach the popup to the DOM.
>
> I gave a quick try to the later one using the following code, which seems 
> to work:
>     @Override
>     public void show() {
>         Widget parent = getParent();
>         if(parent instanceof Panel) {
>             ((Panel) parent).remove(this);
>             ((Panel) parent).add(this);
>         }
>         // blabla do the rest
>     }
>
> Any idea if this detach/reattach strategy can have any side effect?
>
>
>
------=_Part_1636_22183564.1352816505903
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<div>I would think that z-index is the better solution. &nbsp;Your mechanis=
m for opening the popup ( rather than the popup itself) should be the one m=
aking the determination as to which z-index to use. &nbsp;&nbsp;</div><div>=
Beyond a "system error" type of message, I&nbsp;personally don't think it's=
 good UX to have popups throwing popups... but a requirement is a requireme=
nt.</div><br><br>On Tuesday, November 13, 2012 8:05:04 AM UTC-5, Thomas Lef=
ort wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I have a use case wh=
ere I do need to show one dialog on top of the other. The problem is that t=
hose dialogs are reused across the application and if the one that should b=
e on top for the use case happens to have been open (in another use case) b=
efore the one that should be below, it is not visible (covered by the other=
 one) because (I believe) it was inserted in the DOM before.<br><br>Is ther=
e an obvious way of doing this? Currently, the two strategies I can think o=
f to make sure the show method could always ensure that a dialog is on top =
of the others are the following:<br>- zindex, scanning the list of open pop=
ups and check for the higfhest zindex and setting the zindex of the one I a=
m showing to zindex + 1<br>- detach/reattach the popup to the DOM.<br><br>I=
 gave a quick try to the later one using the following code, which seems to=
 work:<br>&nbsp;&nbsp;&nbsp; @Override<br>&nbsp;&nbsp;&nbsp; public void sh=
ow() {<br>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Widget parent =3D getParent=
();<br>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; if(parent instanceof Panel) {<=
br>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ((Panel) parent=
).remove(this);<br>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=
 ((Panel) parent).add(this);<br>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }<br>=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // blabla do the rest<br>&nbsp;&=
nbsp;&nbsp; }<br><br>Any idea if this detach/reattach strategy can have any=
 side effect?<br><br><br></blockquote>
------=_Part_1636_22183564.1352816505903--

------=_Part_1635_14014442.1352816505903--