Wrong width in Dialog.calculateLayout by having a scrollbar
Closed this issue · 2 comments
GoogleCodeExporter commented
Hi,
during the development of a full(width)sized component I was wondering
about the occasionally clipping of the right side of this component.
The reason is:
1.In Dialog.calculateLayout the param 'width' reports 230px.
2.This width is used to calculate the dimensions of the frame/border etc.
3.And now in Dialog.paint there is a call to Dialog.getWidth which reports
a width minus the scrollbar size.
The width is now 224 and the murder is out.
Okay, I hope I can make a fix during the weekend.
(And don't look to close at the screenshots.It's still a construction side...)
BR, Uli
Original issue reported on code.google.com by z...@gmx.com on 15 Feb 2008 at 4:33
Attachments:
GoogleCodeExporter commented
Hi,
after reviewing the code of Dialog and having a beer in a Pub the following
conclusion was drawn:
There isn't any need to change the implementation of Dialog.
From a pure logical point of view a calculation of the height of the screen
must take
place first.
Afterwards we can make a decision whether a scrollbar is necessary or not.
If there will be a scrollbar the available width of the screen shrinks for
'UIManager.getTheme().getVerticalScrollbarWidth()' and the reported
'componentWidth'
for 'Component.paintComponent' is a different one.
To solve this inconsistence we could call 'Dialog.calculateLayout' for the
second
time to report the true width to all components
OR
the component itself handles this fact.
The 'NewComponent' class has a field(if necessary) called
'widthByPreferredSize'
which contains the width reported by 'NewComponent.getPreferredSize'.
Then, in the 'NewComponent.paintComponent', there is a simple instruction 'int
widthCorr = widthByPreferredSize - width' which is used to adjust the layout of
the
component.
BR, Uli
Original comment by z...@gmx.com on 16 Feb 2008 at 5:10
GoogleCodeExporter commented
I struggled with this during the design. Turns out the LCDUI does what I
ultimately
did with J4ME. It will stay as is, but I agree it is a "gotcha" in custom
component
design.
The first option you gave -- calling 'Dialog.calculateLayout' a second time --
is bad
for performance reasons. Other than perhaps removing the "gotcha" it serves no
benefit. That's why I don't do it.
Similar to what you suggested there another alternative used in some UI
frameworks.
Adding a sizeChanged() method that is called by the framework. However this
suffers
from the same problem as calling calculateLayout() again.
Original comment by deanbro...@gmail.com on 8 Mar 2008 at 1:46
- Changed state: WontFix