Problem with CustomLayout.removeComponent(location)

Good afternoon !

I seem to have a problem with CustomLayout.removeComponent(location).

I have a quite generic CustomLayout , having locations like “MainContent”, “Header”, “Footer”, etc.
When I add component to any of those location, everything is ok.

But I have some cases where I want to remove one of those component, and add another one to another location; for example, something like:


CustomLayout layout = new CustomLayout(layoutName);
layout.addComponent(mainComponent, "main");
layout.addComponent(header, "header");
Button button = new Button("Click me");
button.addListener(new Button.ClickListener() {
   public void buttonClick(Button.ClickEvent event) {
       layout.addComponent(anotherComponent, "main");
       layout.removeComponent("header");
   }
});

In that case, the “main” component is replaced by the new one; but the header is not removed. Well, it is. If I refresh the page manually (say, by hitting F5) the header is removed.
I’ve tried to ask for a layout.requestRepaint(), and for anything with “paint” or “repaint” on it - but to no effect.

I don’t know if it is a bug, or something that I’m doing wrong…
I currently use a workaround - instead of removing a component in a given location, I set a new component to that location (an empty label).

Any hindsight ?

I’m using the version 5.2.1 of the toolkit. I have the same behavior with version 5.1.2, and I have not tested with any other versions :slight_smile:

Thank you very much !

Quentin Astegiano.

This surely sounds like a bug. Created http://dev.itmill.com/ticket/1775

What is really strange is that I have other cases, where I mostly do the same thing, and removeComponent(location) work perfectly… :frowning:

And I can’t find the differences :frowning:

Quentin.

Hi Quentin!

I fixed this rather nasty defect this morning. The client side side custom layout didn’t properly detach the old component if an already populated slot (or “location”) was emptied. It worked fine if it was replaced (the most usual use case).

Thanks for helping us to find this!

Our package maintainer promised to make a new “nightly” build when he arrives to office. So with a good luck your issues are vanished in a few hours with a new build. If you are in a hurry, “svn up” and build it yourself.

cheers,
matti

Thank you very much :slight_smile:

I’m in no hurry, I have no nearby deadline, I’ll wait for the next version.

Quentin.

There,
http://itmill.com/download/nightly/itmill-toolkit-5.2.1_trunk_20080605.jar
.

The automated tests gave a lot of errors though (
http://itmill.com/download/nightly/Default.html
), I hope these are not regressions. The problems could also be some timing problems as well.

Example result from DateField widget test:


Assert FAILED! 'INPUT( v:22.2.1998 c:i-textfield)' does not equal required value 'INPUT( v:22.3.1998 c:i-textfield)'

Heh, how about seeding your random generator in advance?