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

Bug 344822

Summary: [Text][TextSizeDetermination] calling pack() does not remove scrollbars on multi line texts.
Product: [RT] RAP Reporter: Frank Appel <fr.appel>
Component: RWTAssignee: Project Inbox <rap-inbox>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3    
Version: 1.4   
Target Milestone: 1.5 M3   
Hardware: PC   
OS: Windows 7   
Whiteboard:
Attachments:
Description Flags
project to reproduce problem
none
project to reproduce problem
none
Screenshot using Browser (IE 9) integrated in IDE none

Description Frank Appel CLA 2011-05-05 06:20:12 EDT 
Created attachment 194811 [details]
project to reproduce problem

While working on https://bugs.eclipse.org/bugs/show_bug.cgi?id=314280 I encountered a problem with the Text widget that I could not solve:

If a multi line text is added to a composite that has no layout and if the size of this text is calculated using pack(), there might be some trouble with the visibility of the scrollbars in case the textsize determination kicks in. I've modified the attachement of #314280 to demonstrate the problem:

1) download the attached project zip and import it to your RAP workspace
2) include the project to the bundles of the RAP Workbench launch configuration
3) launch the workbench and change the URL to use "demots" as entry-point
4) click "open new editor"

What you see is that the textsize determination takes place. The text is resized to the correct size after the content of the text was properly measured. Unfortunately the scrollbars still stay visible although they are not needed anymore. The latter problem vanishes once you open a second editor and switch between the two editor tabs.

Unfortunately I wasn't able to reproduce the problem in a simpler setup with the controls demo :( So the interesting part is in the DemoActionBarAdvisor of the demo project...
Comment 1 Ivan Furnadjiev CLA 2011-09-21 06:17:51 EDT 
Frank, I think that your snippet is not so correct. You have a multi text widget with a parent ScrolledComposite (OS400JTerminal#getComposite), but you never set the content (call ScrolledComposite#setContent) on this ScrolledComposite. Thas't why the Text widget is not visible for me. Adding ScrolledComposite#setContent( testText) at the end of run method makes the Text widget visible.  As ScrolledComposite maintain the bounds of its content, I don't understand the usage of pack() method here. If I change OS400JTerminal#getComposite to return a Composite, not ScrolledComposite, everything is working fine.
Comment 2 Frank Appel CLA 2011-09-29 05:17:04 EDT 
Created attachment 204272 [details]
project to reproduce problem

Changed the project to use Composite instead of scrolled composite as described by Ivan (the demo code was not written by me and it seemed to work at the time that I filed the bug). Anyway the problem persists using composite, but occurs only, if you use a browser within eclipse IDE (see screenshot attachment). Therefore I consider this a lower priority problem...
Comment 3 Frank Appel CLA 2011-09-29 05:19:05 EDT 
Created attachment 204273 [details]
Screenshot using Browser (IE 9) integrated in IDE
Comment 4 Frank Appel CLA 2011-09-29 05:20:38 EDT 
(In reply to comment #2)
> Created attachment 204272 [details]
> project to reproduce problem
> 
> Changed the project to use Composite instead of scrolled composite as described
> by Ivan (the demo code was not written by me and it seemed to work at the time
> that I filed the bug). Anyway the problem persists using composite, but occurs
> only, if you use a browser within eclipse IDE (see screenshot attachment).
> Therefore I consider this a lower priority problem...

Note that I did the latest tests against CVS HEAD.
Comment 5 Frank Appel CLA 2011-09-29 05:29:37 EDT 
Note that this problem may be related to https://bugs.eclipse.org/bugs/show_bug.cgi?id=359380
Comment 6 Ivan Furnadjiev CLA 2011-12-12 05:18:05 EST 
By switching IE to standard rendering (bug 270397) layout in IE9 x64 is not broken anymore and I can't reproduce this issue anymore.