If width or height is zero, the rest of bounds are reset.

[GoogleCodeExporter]

What steps will reproduce the problem?

1. Here is some code to reproduce the issue:

        PNode testNode3 = new PNode();
        testNode3.setBounds(10, 10, 10, 0);
        System.out.println("Bounds for plain PNode = " + 
testNode3.getFullBoundsReference());

What is the expected output? What do you see instead?

I would expect that the bounds would be reported as 10, 10, 10, 0, but 
instead they are reported as being empty.

What version of the product are you using? On what operating system?

We are using version 1.2.1, but we have inspected the source code and the 
issue still appears to exist in trunk, r922.  OS is Windows XP.

Please provide any additional information below.

The reason that this is an issue for us is that in some cases we are 
laying out graphs with a number of PNodes whose positions depend on each 
other.  Setting the bounds to have only a width or height is necessary in 
some cases where the node (such as a textual label) has no value in some 
contexts, yet we still want to do a layout based on its position.  
However, the x and y values of the bounds are reset if the width or height 
are 0, so such a layout fails.  It is possible to work around this by 
detecting an empty bounds and using another PNode for the layout 
reference, but it makes the code much more complex.

We have no idea if other portions of the Piccolo library depend on the 
current behavior of resetting the bounds when length or height are 0.

Regards,
John Blanco
PhET Project
University of Colorado

Original issue reported on code.google.com by jxb...@gmail.com on 14 Jan 2010 at 7:27

[GoogleCodeExporter]

Thank you for reporting this.

Original comment by allain.lalonde on 14 Jan 2010 at 7:44

• Changed state: Accepted
• Added labels: Type-Defect, Priority-Medium, Effort-Low, OpSys-All, Toolkit-Piccolo2D.Java

[GoogleCodeExporter]

Fixed in r923 as an optimization PBounds.add was not doing work when passed 
PBounds was 
"empty".

Original comment by allain.lalonde on 14 Jan 2010 at 8:04

[GoogleCodeExporter]

Original comment by allain.lalonde on 14 Jan 2010 at 8:05

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by heue...@gmail.com on 18 Jan 2010 at 6:20

• Changed state: Verified

[GoogleCodeExporter]

This Issue will be resolved in 2.0. No binary incompatible changes are allowed 
until 
2.0.

Original comment by allain.lalonde on 9 Feb 2010 at 3:58

• Changed state: Accepted
• Added labels: Milestone-2.0

[GoogleCodeExporter]

Technically, this wouldn't be a binary-incompatible API change, since no APIs 
are
changed.  It is a behavior change though, and whether or not we should do that 
in a
.x release can be discussed.

Original comment by heue...@gmail.com on 9 Feb 2010 at 4:46

[GoogleCodeExporter]

No update on this issue in some time, would it be ok for me to apply this to 
release-1.3-branch for Milestone-1.3.2?

Original comment by heue...@gmail.com on 1 Nov 2011 at 7:18

[GoogleCodeExporter]

See allain's comment in r970, at which he reverted r923.

Original comment by atdi...@gmail.com on 1 Nov 2011 at 10:17

[GoogleCodeExporter]

See allain's comment in r970, at which he reverted r923. Does this mean that he 
had realized some contract change that shouldn't go into a point release?

Original comment by atdi...@gmail.com on 1 Nov 2011 at 10:18

[GoogleCodeExporter]

I wouldn't say that it is a contract change, since the PBounds javadoc doesn't 
make any comment on this situation, other than to say that isEmpty() doesn't 
necessarily mean that the bounds are empty.

Original comment by heue...@gmail.com on 2 Nov 2011 at 3:40

[GoogleCodeExporter]

I agree it doesn't sound like a contract change. His comment seemed to suggest 
some clients were broken by the change:

"Reverting r923 since it was a breaking change. It will need to be redone in 
2.0.
Seems that some apps were making use of this behaviour."

Original comment by atdi...@gmail.com on 4 Nov 2011 at 4:17

[GoogleCodeExporter]

Original comment by heue...@gmail.com on 26 Nov 2013 at 9:11

• Added labels: Milestone-2.1
• Removed labels: Milestone-2.0