Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 329881

Summary:	[TextSizeDetermination] Mark temporary layout when performed with the larger bounds
Product:	[RT] RAP	Reporter:	Istvan Ballok <Istvan.Ballok>
Component:	RWT	Assignee:	Project Inbox <rap-inbox>
Status:	RESOLVED INVALID	QA Contact:
Severity:	normal
Priority:	P3	CC:	cole, fr.appel, rsternberg, ruediger.herrmann, swimmer_86
Version:	1.4
Target Milestone:	---
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description Istvan Ballok

2010-11-10 05:33:02 EST

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.

Comment 1 Istvan Ballok

2010-11-10 05:37:16 EST

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 );
           }
         }

Comment 2 Frank Appel

2011-05-05 04:05:26 EDT

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.

Comment 3 Istvan Ballok

2011-05-05 12:07:04 EDT

(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.

Comment 4 Frank Appel

2011-05-06 00:57:26 EDT

Done as proposed in the comments above :-)

Comment 5 Yury

2011-07-04 01:27:22 EDT

Why is the such big constant (1000) used for sizes determination?

Comment 6 Ralf Sternberg

2011-07-04 10:00:32 EDT

(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.