Community
Participate
Working Groups
In TextSizeDeterminationHandler#afterPhase, Line: 140, a layout is triggered, with larger and then with the original bounds; if text was used, whose exact measures were not known. Problem: This temporary layout with the larger bounds can interfere with custom layout logic. Currently, there is no means to detect, whether we are in this temporary layout phase, or in a real layout; to deactivate the custom layout logic appropriately.
Proposed workaround: mark this temporary layout with an attribute in the session. @@ -135,11 +135,13 @@ final class TextSizeDeterminationHandler = ( IShellAdapter )shell.getAdapter( IShellAdapter.class ); Rectangle bounds1000 = new Rectangle( bufferedBounds.x, bufferedBounds.y, bufferedBounds.width + 1000, bufferedBounds.height + 1000 ); + ContextProvider.getSession().setAttribute( "TextSizeDeterminationHandler.bounds1000", Boolean.TRUE ); shellAdapter.setBounds( bounds1000 ); + ContextProvider.getSession().removeAttribute( "TextSizeDeterminationHandler.bounds1000"); WidgetTreeVisitor.accept( shell, clearLayout ); shellAdapter.setBounds( bufferedBounds ); WidgetTreeVisitor.accept( shell, restoreSCOrigins ); } }
Istvan, could you please elaborate a little bit on how the larger bounds can interfere with custom layout logic? In my opinion a custom layout should be able to deal correctly with resize events as this is part of the layout contract. If it does not, this is rather a problem of the custom layout than of the RWT core functionality. So if I am not missing a point completely, I suggest to close this issue as invalid.
(In reply to comment #2) Frank, I am sorry that I did not update this ticket - I understand your argumentation; custom layout logic should handle (any) layout events correctly. So I too suggest to close this issue as invalid. I could in fact fix our custom layout logic, so that the temporary layouts do not cause a problem any more.
Done as proposed in the comments above :-)
Why is the such big constant (1000) used for sizes determination?
(In reply to comment #5) > Why is the such big constant (1000) used for sizes determination? What's wrong with that? The value has to be large to ensure changes are propagated to all nested controls. But let's not pollute the bugzilla discussions on implementation details. If you have ideas for improvement, let's discuss them on the newsgroup or open a new enhancement request.
