Am Mittwoch, den 22.02.2006, 09:08 +0100 schrieb Robert Schuster: > Hi, > as mentioned in PR 26157[0] I observed that the JDK's JTextArea adjusts its > size > automatically when the characters leave the allocation area of the component. > Our JTextArea did not have this functionality until now. > > It took me a while to find out where to place the code that could do the > neccessary checks which should prevent unneeded revalidate() calls. > > While implementing this I found and fixed two problems in PlainView: > > 1) The switch statement in getPreferredSpan always fell into the Y_AXIS case. > > 2) In changeUpdate() the maxLineLength value could never shrink when > characters > are removed on one line only. I added a check whether the characters are > removed > from the current longest line and update the maxLineLength value if that is > the > case.
Great!
<<
switch (axis)
{
case X_AXIS:
- span = determineMaxLineLength();
+ return determineMaxLineLength();
case Y_AXIS:
default:
- span = metrics.getHeight() * el.getElementCount();
- break;
+ return metrics.getHeight() * el.getElementCount();
}
- return span;
>>
I'd rather have inserted a break in the X_AXIS case. Having only 1 exit
point in methods makes the code easier to understand and more
importantly, data flow analysis tools sometimes don't play nice with
more exit points.
- private class RootView extends View
+ class RootView extends View
why was that necessary? I have got the habit of marking things private
when not needed otherwise (like when the compiler would have to create a
synthetic accessor method). This has the advantage that tools like
eclipse can detect if private members are actually used in a class,
which doesn't work with default access.
+ /** Extends the RootView of BasicTextUI with the ability to adjust
the size
+ * of the component after text was inserted, removed or changed.
+ */
+ class TextAreaRootView extends BasicTextUI.RootView
+ {
Ah, now I see. Can't this be solved differently? The RootView should
really not do anything except providing the real root view with a know
parent. I suspect that the functionality really belongs into PlainView
and/or WrappedPlainView. Views can do something like revalidate() by
calling preferenceChanged(this, true, true) where the latter two
parameters should be adjusted accordingly (see API docs in View). This
propagates through the parent views and in RootView triggers a
revalidate(). So when there is a change detected which causes a change
in the view's size preferences, call preferenceChange() with the
appropriate parameters and you will get your view resized accordingly.
/Roman
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
