Btw... Commenting out the ComponentListener added in the PSwing
constructor does make the problem go away.
On Feb 1, 4:07 pm, "cmal...@pixelzoom.com" <cmal...@pixelzoom.com>
> I've reproduced the problem in an example, see
> On Feb 1, 2:32 pm, Allain Lalonde <allain.lalo...@gmail.com> 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, cmal...@pixelzoom.com
> > <cmal...@pixelzoom.com>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, "cmal...@pixelzoom.com" <cmal...@pixelzoom.com>
> > > 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, piccol...@googlecode.com 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