You must not use *LayoutPanel for this purpose. Why not native HTML?
====MyApp.ui.xml====
<!DOCTYPE ui:UiBinder SYSTEM "http://dl.google.com/gwt/DTD/xhtml.ent";>
<ui:UiBinder xmlns:ui="urn:ui:com.google.gwt.uibinder"
xmlns:g='urn:import:com.google.gwt.user.client.ui'>
<ui:style>
.top {
height: 120px;
}
</ui:style>
<HTMLPanel>
<div class="{style.top}">
<g:Button ui:field="button">Click me</g:Button>
</div>
<g:FlowPanel ui:field="content" />
</HTMLPanel>
</ui:UiBinder>
========
====MyApp.java====
public class MyApp extends Composite {
... // UiBinder stuff
public MyApp() {
initWidget(binder.createAndBind(this));
}
@UiHandler("button")
void onButtonClick(ClickEvent event) {
content.add(new Label("Hello world");
}
}
========
Not tested...
Olivier
On 28 mai, 10:39, googelybear <[email protected]> wrote:
> @Stefan: I know the term sucks, but it was the best I could come up
> with ;-) As you concluded my main goal is to have browser scrollbar
> scrolling and not the "inner scrolling" (lots of individual scrollbars
> inside the containers itself, an example for this is google wave).
>
> So in your words "(...) you have to allow the parents to grow with its
> child. " That's exactly the behavior of the old panels. I'm not
> really clear on how we could emulate this on the new panels (all my
> attempts so far failed).
>
> To make a simple example: I have a DockLayoutPanel and somewhere a
> button. There is a FlowPanel in the center. Clicking on that button
> adds a label to the center panel. Repeatedly clicking that button
> fills the center panel and at some point additional labels are not
> displayed anymore (simulates the dynamic content). This is as you
> wrote because of the overflow:hidden/auto which is set on the
> DockPanel - in the LayoutPanels in general - (and is IMPOSSIBLE to
> override by the programmer - at least I didn't succeed). If I add a
> scrollPanel to the center as parent of the FlowPanel I get said "inner
> scrolling" But what I would like to have is that the DockLayoutPanel
> itself grows (vertically) which forces the browser to display
> scrollbars.
>
> I uploaded the (very simple) demo project here (Just import in eclipse
> and run):http://drop.io/gwt_dock_panel
>
> It would be really great if you could share how to achieve the
> behavior described above.
>
> thanks,
> Dennis
>
> On May 27, 6:55 pm, Stefan Bachert <[email protected]> wrote:
>
> > Hi Dennis,
>
> > I still think what "traditionalbehaviour" should be. (? not following
> > the standards?)
>
> > However, you don't want scrollbars at your LayoutPanel.
>
> > The reason why any widget gets a scrollbar is because it is larger
> > than its parent and the style overflow is set to auto or scroll.
> > When the "wrong" widget get a scrollbar you have to change the size of
> > the panel (div) hierarchy.
> > Or you have to allow the parents to grow with its child.
>
> > When you do not succeed you need to show us your code or at least the
> > hierarchy ofpanels.
>
> > Stefan Bacherthttp://gwtworld.de
>
> > On 26 Mai, 10:33, googelybear <[email protected]> wrote:
>
> > > Hi,
>
> > > I am developing a webapp that should "behave" like atraditionalweb
> > > page, meaning that when the content grows in height the browser should
> > > display a vertical scroll bar. Unfortunately I was foolish and jumped
> > > right in on the new, shinylayoutpanels. As I found out later these
> > > are not suitable for me, as they create a more "application-like" look
> > > and feel with scrollbars displayed in the individual gwtpanels
> > > instead of the browser (try resizing e.g. google wave -> When the
> > > available area is too small scrollbars will appear inside all the
> > >panels, the browser will never display any scrollbars) and also they
> > > are working with lots of fixed sizes (in my case the content is
> > > dynamic).
> > > I tried toachievethetraditionalbehaviorwith my LayoutPanels but
> > > failed. I couldn't get the browser to display scrollbars, only inner-
> > > panel scrolling, and stuffing a layoutpanel inside a scrollpanel is
> > > not the desirable approach (stuffinglayoutpanelsinside non-layout
> > >panelsusually ended badly for me..).
> > > So my conclusion is to revert to the "old school"panels. But I am
> > > afraid that support of these will be dropped soon. What do you think?
> > > Are there better alternatives? Anyone fought with a similar problem?
>
> > > thanks for any suggestions,
> > > Dennis
>
>
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
