Miglayout + hidemode 3 = unwanted autoscroll when showing controls

Question

I'm using 'hidemode 3' in MigLayout so that hidden components aren't visible at all (and don't have any impact on layout).

I'm using this so that I can show inline errors underneath textboxes, which show only if there is an error

Whenever I show these inline error boxes (they're text areas so I just call setVisible(true)) the scroll pane the form is embedded within automatically scrolls down to whatever is being set to visible (so I call setVisible(true) on something, it causes a layout change and the scroll pane auto-scrolls downward to where ever the component is)

Now, this isn't the problem - I think I get why the above part happens (presuambly the panel changing size to accomodate the new layout screws up the scale of the scroll bar, so it appears to scroll downward)

What I can't understand is how to work around it - for example I've tried doing this:

// validateModel will cause the setVisible() calls to occur 
if (!syncControl_.validateModel())
{
    // Here I try and counteract the layout change by going back 
    // to the top 
    variableScrollPane_.getViewport().setViewPosition(new Point(0,0));
}

But it doesn't work - or rather, it does work for a moment: The scroll occurs, but the apparent 'auto scroll' then happens a few milliseconds afterwards. It seems whatever redoes the layout either gets called at regular intervals, or setVisible actually fires some kind of event

I've tried calling validate(), invalidate() repaint() etc. prior to the scroll change to no avail.

So I suppose my question is: When I use hidemode 3 and call setVisible() what method is it that does the 'reacting'? Is it during validation / doLayout() etc. or is there something completely separate happening?

Thanks

Answer 1

Just accidentally answered my own question:

SwingUtilities.invokeLater(new Runnable() {
      public void run() {
           variableScrollPane_.getVerticalScrollBar().setValue(0);                
      }            
}); 

Turns out MigLayout doesn't factor into this at all (and it seems the above is a well-known mechanism for resetting the scrollbar in many situations)