I stumbled upon this very interesting old topic today, when I tried to manipulate the display property of the container's element. I'm gonna demonstrate here, that this issue has few hard to deal with pitfalls.
-- So, the first stumbling block I ran into, was a vain attempt to change the display property. This call in fact doesn't do anything. I started to dig inside the code and found these lines within com.google.gwt.layout.client.LayoutImpl::layout(Layer layer):
and it actually works fine.
On Thursday, June 10, 2010 at 3:54:21 PM UTC+3, Stefan Bachert wrote:
myLayoutPanel.getWidgetContainerElement(myWidget).getStyle().setDisplay(Display.NONE);if (layer.visible) {
style.clearDisplay();
} else {
style.setDisplay(Display.NONE);
}Obviously field visible is set to true for all children's layers of LayoutPanel. Now, the public inner class com.google.gwt.layout.client.Layout$Layer has in fact a setter for flag visible:
/**
* Sets the layer's visibility.
*
* @param visible
*/
public void setVisible(boolean visible) {
this.visible = visible;
}The problem is though, that LayoutPanel doesn't give you a layer for its widgets, since the accessor method is private:
private Layout.Layer getLayer(Widget child) {
assert child.getParent() == this : "The requested widget is not a child of this panel";
return (Layout.Layer) child.getLayoutData();
}However, any Widget object has a public accessor for its own layout as:
/**
* Gets the panel-defined layout data associated with this widget.
*
* @return the widget's layout data
* @see #setLayoutData
*/
public Object getLayoutData() {
return layoutData;
}Now, whenever I want to change the display property of any widget within a LayoutPanel I can simply write:
Layout.Layer layer = (Layout.Layer) myWidgetInsideLayoutPanel.getLayoutData();
layer.setVisible(false);and it actually works fine.
The question is though, how safe are these calls? We get an Object and do an unsafe cast, assuming that it is in fact Layout.Layer. However my concern is, that I assume the lib gwt code to have such straight casts simply due to the fact, that it is an implementation detail, which is of cause a subject of potential future changes.
We might assume that as a workaround one can change the visibility property of the container's widget instead. But again, there's no guarantee, that this parameter won't be added to Layout$Layer and managed by LayoutImpl just like the display property. All in all, I feel that my hands are tied.
On Thursday, June 10, 2010 at 3:54:21 PM UTC+3, Stefan Bachert wrote:
Hi Chris,
it is not really clear to me.
Did you switched of the added child, or the layer (div) containing the
added child.
The first is not suffient and will leave the layer (div).
I think, the correct method to get the layer div of any child widgets
is
getWidgetContainerElement.
Call this and set the visibiltity
Stefan Bachert
http://gwtworld.de
On Jun 9, 11:28 pm, Chris <christopher.burr...@gmail.com> wrote:
> Hi there
>
> I'm trying to hide a layer in my LayoutPanel. The idea is to have a
> layer act a bit like a popup, but it's not really a popup, and it
> makes it easier if it is a layer.
>
> I'm trying to hide it, so I toggle the layer child (a simplePanel)'s
> visibility property on/off, which seems to work fine, but it leaves a
> div element (from the layer I suppose), which means I can't click
> through to the elements behind it... When I look at the DOM, I get a
> <div> with all the properties from my layer, and then the <div> inside
> that is the SimplePanel I'm using.
>
> Any ideas? I guess i could just ask for the widget's parent? But that
> seems hacky. Am I doing something wrong?
>
> Chris
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment