-
Bug
-
Resolution: Fixed
-
P4
-
1.3.0
-
beta
-
x86
-
windows_98
Name: mc57594 Date: 12/09/99
java version "1.3beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3beta-O)
Java(TM) HotSpot Client VM (build 1.3beta-O, mixed mode)
BoxView.java declares xAllocValid and yAllocValid as private variables. These
set whether or not a view needs to be layed out again on a certain axis.
If one derives a class from BoxView, it's easy enough to invalidate the view
along a certain axis: just call layoutChanged(axis). But if the class wishes to
do its own layout, it cannot declare that the axis has been revalidated,
because there are no way to set xAllocValid and yAllocValid to true from the
descendant class.
For example, let's say I create a MyLayoutView which extends BoxView. I
override layout() so that every time an axis gets invalidated (whether by
calling layoutChanged() or some other methed), my layout() function always gets
called from inside setSize(). So far, so good. But if I decide to do my own
layout and never call super.layout(), how can I set xAllocValid and xAllocValid
to true so that another call to setSize() (even with an identical width and
height) do not call my layout() function again?
What's needed here is a BoxView.setLayoutValidated(int axis) or something
similar, so that I can specify when an axis no longer needs to be layed out.
BoxView.java:
public void layoutChanged(int axis) {
if (axis == X_AXIS) {
xAllocValid = false;
} else {
yAllocValid = false;
}
}
The only way one can set these to true is to call BoxView.layout():
protected void layout(int width, int height) {
checkRequests();
[cut]
xAllocValid = true;
yAllocValid = true;
If one is doing custom layout in a child class of BoxView, the idea is *not* to
call BoxView.layout(). Therein lies the problem.
(Review ID: 98742)
======================================================================
Name: krT82822 Date: 12/10/99
(see also 4199079)
java version "1.3beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3beta-O)
Java(TM) HotSpot Client VM (build 1.3beta-O, mixed mode)
Extending BoxView to supplement its layout behavior (rather than write layout
behavior from scratch) seems to be a logical and common need. The current
implementation of BoxView makes this virtually impossible.
1. To create custom layout functions, it is natural to override BoxView.layout
() and do the custom layout there. However, MyView.layout() cannot call
BoxView.layout() because doing so would invalidate the custom layout. However,
there is no way to notify BoxView that the custom layout is complete, because
xAllocValid and yAllocValid are not accessible unless the derived class is put
in the same package (javax.swing.text) -- hardly desired or, I assume,
recommended.
2. To solve 1., *every* piece of code in BoxView that references xAllocValid or
yAllocValid must be duplicated in MyView, referencing instead a local version
of myXAllocValid and myYAllocValid. This requires that, among others,
BoxView.setSize() be overridden. MyView.setSize() obviously then needs to set
the size, but BoxView.width and BoxView.height are similarly unaccessible! Each
of these variables must also be duplicated in MyView.
The chain goes on and on, until one finds that one is not extending BoxView,
but in effect rewriting BoxView. The next choice would be to simply derive
MyView from View instead of BoxView, because having BoxView is redundant now,
but this is not possible, because MyView is really extending BoxView through
FlowView for needed flowing functionality.
The solution is for Swing to simply provide a handful of protected accessor
functions, namely setXAllocValid(), setYAllocValid(), setWidth(), setHeight(),
and a few others.
=========================================
Although Bug Report Internal ID #98839 reported that BoxView could still be
extended and that the derived class MyView could still provide custom layout
functionality, the situation is in reality even worse: even if all variables
are duplicated in MyView, several necessary functions which access these
variables are declared final and cannot be overridden for correct functionality.
Specifially, BoxView.getWidth() and BoxView.getHeight() are declared final and
cannot be overridden.
In summary, the chain of bleak events looks like this:
1. MyView derives from FlowView (and thereby BoxView) and needs custom layout
functions.
2. Since the custom layout must change xAllocValid and yAllocValid, these
variables and all code which references them must be duplicated in MyView.
3. Some of these references are in setSize(), which to actually set the size
must duplicate the width and height variables.
4. getWidth() and getHeight() cannot be overridden to return the correct size,
because they are declared final in BoxView.
P.S. Please excuse that previous reports on this issue had incorrect responses
for "Symptoms".
(Review ID: 98839)
======================================================================
java version "1.3beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3beta-O)
Java(TM) HotSpot Client VM (build 1.3beta-O, mixed mode)
BoxView.java declares xAllocValid and yAllocValid as private variables. These
set whether or not a view needs to be layed out again on a certain axis.
If one derives a class from BoxView, it's easy enough to invalidate the view
along a certain axis: just call layoutChanged(axis). But if the class wishes to
do its own layout, it cannot declare that the axis has been revalidated,
because there are no way to set xAllocValid and yAllocValid to true from the
descendant class.
For example, let's say I create a MyLayoutView which extends BoxView. I
override layout() so that every time an axis gets invalidated (whether by
calling layoutChanged() or some other methed), my layout() function always gets
called from inside setSize(). So far, so good. But if I decide to do my own
layout and never call super.layout(), how can I set xAllocValid and xAllocValid
to true so that another call to setSize() (even with an identical width and
height) do not call my layout() function again?
What's needed here is a BoxView.setLayoutValidated(int axis) or something
similar, so that I can specify when an axis no longer needs to be layed out.
BoxView.java:
public void layoutChanged(int axis) {
if (axis == X_AXIS) {
xAllocValid = false;
} else {
yAllocValid = false;
}
}
The only way one can set these to true is to call BoxView.layout():
protected void layout(int width, int height) {
checkRequests();
[cut]
xAllocValid = true;
yAllocValid = true;
If one is doing custom layout in a child class of BoxView, the idea is *not* to
call BoxView.layout(). Therein lies the problem.
(Review ID: 98742)
======================================================================
Name: krT82822 Date: 12/10/99
(see also 4199079)
java version "1.3beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3beta-O)
Java(TM) HotSpot Client VM (build 1.3beta-O, mixed mode)
Extending BoxView to supplement its layout behavior (rather than write layout
behavior from scratch) seems to be a logical and common need. The current
implementation of BoxView makes this virtually impossible.
1. To create custom layout functions, it is natural to override BoxView.layout
() and do the custom layout there. However, MyView.layout() cannot call
BoxView.layout() because doing so would invalidate the custom layout. However,
there is no way to notify BoxView that the custom layout is complete, because
xAllocValid and yAllocValid are not accessible unless the derived class is put
in the same package (javax.swing.text) -- hardly desired or, I assume,
recommended.
2. To solve 1., *every* piece of code in BoxView that references xAllocValid or
yAllocValid must be duplicated in MyView, referencing instead a local version
of myXAllocValid and myYAllocValid. This requires that, among others,
BoxView.setSize() be overridden. MyView.setSize() obviously then needs to set
the size, but BoxView.width and BoxView.height are similarly unaccessible! Each
of these variables must also be duplicated in MyView.
The chain goes on and on, until one finds that one is not extending BoxView,
but in effect rewriting BoxView. The next choice would be to simply derive
MyView from View instead of BoxView, because having BoxView is redundant now,
but this is not possible, because MyView is really extending BoxView through
FlowView for needed flowing functionality.
The solution is for Swing to simply provide a handful of protected accessor
functions, namely setXAllocValid(), setYAllocValid(), setWidth(), setHeight(),
and a few others.
=========================================
Although Bug Report Internal ID #98839 reported that BoxView could still be
extended and that the derived class MyView could still provide custom layout
functionality, the situation is in reality even worse: even if all variables
are duplicated in MyView, several necessary functions which access these
variables are declared final and cannot be overridden for correct functionality.
Specifially, BoxView.getWidth() and BoxView.getHeight() are declared final and
cannot be overridden.
In summary, the chain of bleak events looks like this:
1. MyView derives from FlowView (and thereby BoxView) and needs custom layout
functions.
2. Since the custom layout must change xAllocValid and yAllocValid, these
variables and all code which references them must be duplicated in MyView.
3. Some of these references are in setSize(), which to actually set the size
must duplicate the width and height variables.
4. getWidth() and getHeight() cannot be overridden to return the correct size,
because they are declared final in BoxView.
P.S. Please excuse that previous reports on this issue had incorrect responses
for "Symptoms".
(Review ID: 98839)
======================================================================