GXT's Grid.reconfigure() messes up header alignment

As we added a new feature to our application that needeed the ability to either hide/show a specific column in a GXT grid a bug was found. The column header did not align with rows below when a column was hidden/shown programmatically. Not surprisingly, it was the grid.reconfigure(...) call that caused the bug.

Grid.reconfigure() signature:

void reconfigure(ListStore<M> store, ColumnModel cm)

We're using MVP and Gin on our client side code and our presenter has a start method that looks like this:

void start(final AcceptsOneWidget panel, final EventBus eventBus) {
    //Figure out which columns to show/hide
            ...

    display.setColumnVisibility(...);
    panel.setWidget(getDisplay().asWidget());
}

Our display instances are kept singleton by Gin to avoid having to recreate them every time place is visisted. The bug only appeared when the grid already had been rendered. So it seems that grid.reconfigure(...) is dependent on that widget is attached to the DOM (GXT probably makes DOM dependent size calculations) or that widget.layout() hasn't been executed at all. The reconfigure method does not state whether or not this is the case but it seems to me that it is.

So how do you avoid this situation?

Well, either you get to be sure to always wait (by listeners or otherwise) on that the Grid is rendered or you do so at a higher level.
I solved it in the latter way. In the start(...) method in the presenter class i make sure that the Display is attached to the DOM before any other calls are made that can modify Grid columns.
After my change, this is how the start() method in a Presenter looks like:

public void start(final AcceptsOneWidget panel, final EventBus eventBus) {
    //Figure out which columns to show/hide
    ...

    panel.setWidget(getDisplay().asWidget());       
    display.setColumnVisibility(...);
}

To summarize, I swapped order of the two calls in the start method in Presenter class.