I've reproduced the problem in an example, see issue160: http://code.google.com/p/piccolo2d/issues/detail?id=160
Chris On Feb 1, 2:32 pm, Allain Lalonde <[email protected]> wrote: > Reason for adding the component listener in PSwing's constructor was that > during the creation of unit tests for it, a bizarre situation became > obviously possible. > > Invisible PSwing node and visible JComponent or Visible PSwing and invisible > JComponent. > > Rather than try to parse out the behaviour in those gray areas, I figured > the best bet would be to make hiding/showing one, hide/show the other. > > I figured that some optimizations could be done at the JComponent level if > it were aware that it were invisible (like unloading an image from memory, > etc). > > If it's causing more problems than it's fixing I'm 100% for removing it. > > Try commenting out the ComponentListener registration in the constructor and > see if the problem goes away. > > Thoughts? > > On 1 February 2010 16:24, [email protected] <[email protected]>wrote: > > > I can't seem to reproduce this in a simple example. But in one of our > > applications, I see an endless series of calls to the > > ComponentListener that is added in PSwing's constructor. The calls > > alternate between componentShown and componentHidden. And there is > > nothing in the application code that appears to be triggering this, it > > keeps feeding back through PSwing.setVisible. > > > So rather than continue to chase my tail on this, I'd like to discuss > > the motivation for adding this ComponentListener. What purpose is it > > serving? It seems unnecessary. And undesirable - should client code > > be able to call setVisible on a Component? And both this > > ComponentListener and the override of PSwing.setVisibile seem a little > > dangerous, given how the entire Swing approach works by parenting > > JComponents to PSwingCanvas.ChildWrapper. > > > Also note that an additional ComponentListener is added in > > PSwing.initializeComponent, could this be creating problems, depending > > on the call order? It seems like there is component initialization > > going on in the constructor that should really be in > > initializeComponent. > > > Thoughts anyone?... > > > Chris > > > On Jan 28, 3:46 pm, "[email protected]" <[email protected]> > > wrote: > > > Thanks for being so responsive Allain! > > > > Unfortunately this change did not correct the problem. And it's > > > actually unnecessary, since JComponent.setVisible is already a no-op > > > if the visibility isn't changing. > > > > To clarify... I'm not seeing a stack overflow, but a continuous > > > toggling between visible and invisible. And I'm still trying to > > > reproduce the problem in a simple example. > > > > Chris > > > > On Jan 28, 8:05 am, [email protected] wrote:> Revision: 962 > > > > Author: allain.lalonde > > > > Date: Thu Jan 28 07:04:37 2010 > > > > Log: Made PSwing.setVisible lazily call its component's setVisible > > method > > > > depending on its current visibility. This should stop the stack > > overflow > > > > being experienced by Chris Malley. Since I have been unable to > > reproduce > > > > it, I can't test it. > >http://code.google.com/p/piccolo2d/source/detail?r=962 > > > > [snip] > > > -- > > Piccolo2D Developers Group: > >http://groups.google.com/group/piccolo2d-dev?hl=en -- Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
